AWS Security Groups vs NACLs

- aws networking

This post is part of my note taking while studying for the AWS Certified Advanced Networking - Specialty certification.

Security Groups

Security Groups (SGs) are a virtual firewall that controls inbound and outbound traffic to an instance. When you launch a VPC, you can assign up to 5 security groups to that instance. It is important to note that the SG actually gets applied to the default ENI, not the instance itself. Up to 5 security groups can be specified for additional ENIs as well. You can have up to 500 SGs per VPC.

In Security Groups, you can only specify allow rules and there is an implicity deny at teh end. You can specify rules for both inbound and outbound traffic but it’s important to note that SGs are stateful which means they keep track of sessions and automatically allow return traffic. The default rules for an SG when created is allow all outbound, deny all inbound.

Security Groups reference a source, protocol, and port and has rules in the inbound and outbound direction. The source can be CIDR ranges or a logical AWS networking object, including a security group. This allows security groups to reference other security groups and permit traffic from or to a security group. They can also references themselves.

Security Group Inception

deeper

Security Groups are able to reference themselves for policies. A great use case of this is running a Windows domain in the EC2 cloud. As you can see here, many ports are needed for intra-domain communication between servers. You could create a security group that allows all this traffic, allow it from the security group, and assign all the Windows servers in your VPC to that SG. Then, they could communicate with one another over those ports.

Network Access Control Lists

Network ACLs (NACLs) are a stateless security layer for your VPC. SGs are almost always more flexible and useful, but there are some cases when it makes sense to use NACLs. They are often used to provide an additional layer of security. They can be used, unlike SGs, to explicity deny traffic (SGs have permit rules only). Although SGs can be used with Software VPN solutions, sometimes NACLs can be advantageous coupled with Software VPNs. They can also enforce security policy, such as “No NetBIOS shall be allowed here” and can be used as a segregation point between SecOps and DevOps.

The best practice with NACLs is to keep them simple. Avoid ephemeral port ranges, gives rules numbers with room to grow, and tightly control who has acess.