i know stateful/stateless nature of network acl , security group; , know network acl associated subnet(s) whereas security group associated instance(s).
the above 2 noticeable difference should encode our security policy in.
however, there use cases can see 1 better other?
for example, right now, thinking of lock-down bastion host's network security. can encode security group sg_a {only allow 22 set of know ip ranges ingress traffic} , associate sg_a bastion instance. can encode network acl net_acl_b {only allow 22 set of know ip ranges ingress traffic} , associate net_acl_b subnet bastion instance located.
i can encode network acl net_acl_b {only allow 22 set of know ip ranges ingress traffic} , associate net_acl_b subnet bastion instance located.
not quite.
the default network acl already allows traffic in , out. explicitly allowing specific traffic there doesn't change anything, since allowed out of box.
security groups, conversely, allow nothing inbound default.
you'd still have allow bastion host access in security group, because both entities have allow traffic want pass. neither 1 overrides rules of other "allow" -- have agree.
network acls, being stateless, have allow response traffic, while security groups, being stateful, don't.
rule 1: use security groups access control. there never reason open security group wide open , turn around , use , network acl sole firewall layer.
rule 2 option a: use network acls implement restrictions not possible security groups, such blocking traffic small subnet carved out of larger subnet allowed.
rule 2 option b: use network acls duplicate logic of rules in security groups, physically-first, logically-second layer of defense against unintentionally-permissive security group misconfiguration.
