Security Groups
When we create a VPC, AWS automatically creates a default security group and default NACL for us.
Security group controls traffic to or from an EC2 instance according to a set of inbound and outbound rules. This means it represents instance-level security.
Security groups function at the instance level of a VPC, each security group can be applied to one or more instances, even across subnets. And each instance is required to be associated with one or more security groups.
Network Access Control Lists (NACLs)
Network ACLs are tied to the subnet. i.e. 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.
NACLs function at the subnet level of a VPC, each NACL can be applied to one or more subnets, but each subnet is required to be associated with one—and only one—NACL.
State
Security groups are stateful: This means any changes applied to an incoming rule will be automatically applied to the outgoing rule. e.g. If you allow an incoming port 80, the outgoing port 80 will be automatically opened.
Network ACLs are stateless: This means any changes applied to an incoming rule will not be applied to the outgoing rule. e.g. If you allow an incoming port 80, you would also need to apply the rule for outgoing traffic.
Security group support allow rules only (by default all rules are denied). e.g. You cannot deny a certain IP address from establishing a connection.
Network ACL support allow and deny rules. By deny rules, you could explicitly deny a certain IP address to establish a connection example: Block IP address 123.201.57.39 from establishing a connection to an EC2 Instance.
Difference between security groups and NACLs
We can certainly protect your VPC with security groups alone, but to practice defense in depth, the best solution is to use both resource types as virtual firewalls. If you configure their rules properly, they make a very effective combination for filtering traffic to and from your instances.
When traffic enters your network, it is filtered by NACLs before it is filtered by security groups.
This means that traffic allowed by a NACL can then be allowed or denied by a security group, and traffic stopped by a NACL never makes it any further.
Use custom rules with NACLs and use security groups to handle inter-VPC connectivity.
For example, if you configure NACLs with granular rules for controlling inbound and outbound traffic, the NACLs can take the brunt of the work for filtering traffic. You can configure a NACL to allow inbound HTTP and HTTPS traffic from any IP address, deny all other inbound traffic, and allow all outbound traffic. As another example, you can allow inbound FTP access (port 21) from one IP address—yours—and allow outbound access on any port to the same IP address.
Meanwhile, we can configure the security group to allow traffic into and out of a different security group which enables instances within different subnets to talk to each other or we can configure a security group to allow inbound traffic from itself, this enables communication between resources.
Eliminate particular class of traffic with NACLs and use fine-grained rules with security groups.
In this scenario, you can configure a NACL to deny all traffic from a wide range of IP addresses to a certain protocol and port and allow the rest to continue to the security group, which may be configured to evaluate incoming and outgoing traffic on a more granular level. The NACL takes a coarse-grained approach to controlling traffic, leaving the security group to filter the rest by closely examining incoming connections in detail.
NACLs V/S Security groups
| Security Groups | NACLs |
|---|---|
| Operate at instance level | Operate at subnet Level |
| Allow or deny traffic that NACL allows in | Allow or deny traffic before it switches a security group | Rules are processed as a group | Rules are processed one at a time. | Deny all traffic coming in by default and can be configured later | Allow all traffic in and out by default and can be configured later | Stateful- Response traffic is automatically allowed | Stateless-response traffic depends on outbound and inbound rules | Associated with instance | Are automatically associated with all instances in a subnet |
