AWS Security Groups VS NACLs

AWS-SecurityGroups-VS-NACLS

When it comes to the AWS security, security groups and NACLs are critical network elements that you must consider to secure your environment. We will discuss the differences between these two elements and how to use each of them. As always, we try to make things simpler, If you are in a hurry, you can go straight to the table below, we have all the differences there!

What are the differences between AWS Security groups and NACLs?

1. Level of operation:

Security groups:

AWS Security groups (SG) act as a firewall and are associated with EC2 instances (while or after creation) they filter incoming/outcoming traffic to the EC2 instances based on rules that you specify.

for example, below is a security group that is configured to allow HTTP and SSH traffic to the EC2 instance.

SGs

NACLs:

Unlike SGs that act as firewalls of EC2 instances, you can think of NACLs as firewalls of subnets, so any instance in a subnet associated with a NACL will follow rules of that particular NACL first. It’s a recommended practice to use both NACLs and SGs to have a two-layer defense mechanism.

In conclusion, one difference between AWS security groups and NACLs is that SGs operate at the instance level while NACLs operate at the subnet level.

2. Stateful / Stateless:

Security groups:

When you think about the traffic you should think about two directions, inbound traffic and outbound; inbound traffic refers to information coming-to your EC2 instances whereas outbound is traffic coming-out.

The security groups are stateful because if traffic is allowed in one direction, it will automatically be allowed in the other direction without the need to write an additional rule.

NACLS:

The Network Access Control Lists act differently when it comes to inbound/outbound traffic when you specify a rule in one direction you should do the same for the opposite direction. That is if you want your instance to have SSH access you should add both inbound/outbound rules allowing port 22.

Key difference: AWS security groups are stateful whereas NACLs are stateless.

3. Allow / Deny rules:

Security groups:

Unlike NACLs security groups support only Allow rules, they check all rules one by one to decide whether to allow traffic. Bear in mind that by default there are no inbound rules to allow traffic, you have to add them in order to let traffic flow into your instance.

NACLS:

NACLs support both Allow/Deny rules they evaluate rules in number order to decide whether to allow traffic. By default, NACLs allows all inbound/outbound traffic for IPv4.

The following table resumes the differences between AWS Security Groups and AWS NACLs.

AWS Security Groups AWS NACLs
Security groups act like a firewall at the instance level.NACLs act like a firewall at the subnet level. 

Security groups are stateful. This means that responses to allowed inbound traffic are allowed to flow outbound regardless of outbound rules and vice versa.

NACLs are stateless this means that return traffic must be explicitly allowed by rules.

Security groups support Allow rules only.

NACLs support both Allow and deny rules.

With Security Groups AWS checks all rules to decide whether to allow traffic.

With NACLs AWS Evaluates rules in number order to decide whether to allow traffic.

By default, no inbound traffic is allowed until you add inbound rules to the security group.

The default network ACL allows all inbound traffic for IPv4.

By default, new security groups have an outbound rule that allows all outbound traffic.

The default network ACL allows all outbound traffic for IPv4.
You can add up to 50 inbound and 50 outbound rules to each security group
NACLs have a default limit of 20 inbound and 20 outbound rules per list

You can create up to 500 security groups for each VPC

The top end limit to number of network ACLs per VPC is 200
AWSBOY

2 thoughts on “AWS Security Groups VS NACLs

  • Thanks for the excellent cheat sheet. I wanted to make a quick note on Network ACLs. Regarding the use of Port 22 on a NACL (referenced in Step 2 above). If you want to enable SSH access for your instance, you need to configure the NACL so that inbound port 22 is enabled and the outbound TCP High port range for the return traffic (1024-65535) is enabled. The return traffic for SSH does not leave the instance on port 22, it will go outbound via the 1024-65535 and therefore port 22 does not need to be enabled on the NACL for outbound traffic.

Leave a Reply

Your email address will not be published. Required fields are marked *

You cannot copy content of this page