Network Access control lists are applicable at the
subnet level, so any instance in the subnet with an associated NACL will follow
rules of NACL. That's not the case with security groups, security groups has to
be assigned explicitly to the instance.
By default your default vpc, will have a default
Network Access Control List which would allow all traffic , both inbound and
outbound. If you want to restrict access at subnet level it's a good practice
to create a custom NACL and edit it with the rules of your choice and while
editing you could also edit subnet associations , where you associate a subnet
with this custom NACL, now any instance in this subnet will start following
NACL rules
NACLs are stateless unlike security groups. Security
groups are statefull ,if you add an inbound rule say for port 80, it is
automatically allowed out, meaning outbound rule for that particular port need
not be explicitly added. But in NACLs you need to provide explicit inbound and
outbound rules
In security groups you cannot deny traffic from a
particular instance, by default everything is denied. You can set rules only to
allow. Where as in NACLs you can set rules both to deny and allow. There by
denying and allowing only the instances of your choice. You
get to take more granular decisions.
Security groups evaluate all the rules in them before
allowing a traffic . NACLs do it in the number order, from top to bottom like,
if your rule #0 says allow all HTTP traffic and your rule #100 says don't allow
HTTP traffic from ip address 10.0.2.156 , it's not gonna work, because rule #0
has already allowed traffic. So it's good practice to have your deny rules
first in NACL and followed by allow rules. AWS best practice is to number your
rules in increment of 100s in NACL.
No comments:
Post a Comment