Welcome to part 11 of a multiple part course on passing your AWS Architect, Developer & Sysops Associate exams. The best part…this course is totally free of charge!
In this article we’ll compare and contrast network access control lists (nacl) and security groups. And explain when you might want to choose one over the other.
What is an AWS network access control list (NACL)? NACL’s are a optional security layers that you can use within VPCs to behave like a firewall. Features include the ability to block specific IP addresses from accessing any subnets associated with the NACL.
The article will take just 10 minutes to read and after doing so you’ll have all you need to know to answer any basic question around NACLs & security groups to pass the AWS certifications.
If you are studying for the:
- AWS Associate Architect
- AWS Associate Developer
- AWS Associate SysOps
Or you are using AWS and want to learn more about NACLs then this is the article for you.
Think of network address control lists (nacl for short) as a guard that sits inside your VPC but outside of your subnets. They are an optional layer of security that you can use inside your VPC to behave like a fire wall.
A nacl is composed of a series of rules that allow of restrict network traffic of a particular sort (i.e. http, https, ssh etc..) or IP range. You can create many rules and these rules are evaluated in numerical order based on the smallest number first.
A nacl can be assigned to many subnets, however you can not assign a subnet to many nacls. An example use case for a nacl is if you wanted to restrict access to a public subnet to only a small set of IP addresses.
All VPCs get a nacl by default when you create them. This particular nacl will enable all traffic from all IP addresses by default. However the opposite is true when you create a nacl manually. These will block all traffic by default.
For more information about nacl’s checkout amazons official documentation here:
An AWS security group (GSs) as a firewalls for your VPC’s individual EC2 instances. They do not apply to the entire subnet that they reside in. When you create an instance you’ll have to associate it with a security group. Otherwise the VPCs default security group will be allocated.
In a similar fashion to nacls, security groups are made up of rules. Those rules allow and restrict traffic into the instance based on things like the the traffic protocol (http, https, ssh, etc…) and a specified IP range. You can create many rules and these rules are evaluated in numerical order based on the smallest number first.
All VPC’s by default have a security group. If you want to go into more depth about that a security group can do then checkout amazons documentation here. However this article provides sufficient knowledge of security groups to pass the exams.
The AWS associate certifications often ask questions that compare these two features of VPC’s. This is probably because security groups are similar to nacl’s. However they have some key differences which I’ll highlight in this section.
Security Groups function at the EC2 instance level. Where as NACLs reside at the subnet level. This is the most obvious of differences and is likely to be brought up in the exam.
NACL’s allow for rules to be defined for both inbound and outbound traffic individually. Security groups only allow to define rules that apply to both inbound and outbound. You can’t defined difference behaviours for each.
Security Groups are stateful! This is something that has a good chance of showing up in the exam. Because NACLs are not stateful. This means that return traffic must be allowed. I.e. you need an inbound and an outbound rule.
NACL rules are evaluated in numerical order. Where as Security Group rules are all processed before deciding whether or not to allow traffic into the instance.
Finally, nacl rules apply to all the instances within a subnet. So if traffic is blocked at the nacl level but allowed at the instance level. It will never reach the instance as it was blocked before the security group rules could be applied.
For a more detailed comparison checkout amazon documentation here:
Navigate to the VPC dashboard:
Select Network ACL’s from the security tab:
Click Create new ACL:
Enter a name tag and a VPC to associate the ACL with:
On the dashbaord for the ACL’s you can see your newly created ACL and the subnets it is associated with (currently 0).
From here we can configure rules for the ACL:
Here we can see the inbound rules for this ACL. In this case it will allow all traffic from all IP addresses.
And now we can see the outbound traffic rules which mirror the inbound ones.
Notice that the rules start from 100, this is an AWS best practice for NACL’s.
Ok that’s it, you’ve successfully created a network ACL. Pretty easy right?!
This is a big topic and would warrant an entire blog post to itself.
We’ll focus on a single scenario and discuss the best practices to be applied to it for nacl’s.
Scenario: A VPC with a single subnet within it that has multiple EC2 instances. The instances can send and receive traffic from the internet.
This enables all traffic for inbound http requests. Notice the the Rule # has a value of 100. This is what amazon recommends since you can insert 99 more rules before it if you required in the future.
This next set of rules allows for your home/business network to connect to the instances behind the nacl via ssh and remote desktop (rdp)
Finally ephemeral ports are when other instances on your network wish to communicate with the instances behind this nacl.
As we mentioned earlier, for nacl’s you have to specify both inbound and outbound traffic rules. So let’s take a look at the Outbound rules.
Here we can see that the outbound set of rules is very similar to the inbound, with the exception of the removal of the rules for connecting to other machines over ssh and rpd.
Traffic tables courtesy of AWS.
Amazon have written a really great post addressing several scenarios on how to best use nacls here.
When you create a VPC or use the default VPC that gets created with your AWS account. AWS will automatically create a NACL inside it that all subnets will connect to by default unless you point them to another NACL instead. This default NACL will allow all inbound and outbound traffic.
When you create a nacl, unlike the one that gets created with your VPC. This one will deny all inbound and outbound traffic until you add rules to the contrary.
As we touched on in the What is a NACL section a nacl can be associated with many subnets. However you can’t associate a subnet with many nacls. Once you associate it with one, if it were linked to another previously, then that link would be removed. By default subnets are associated with the default nacl created when the VPC was set up.
Rules for nacls are evaluated in numerical order. Where as security groups evaluate all rules regardless of their order.
Security group rules apply to both inbound and outbound traffic where as nacls can specify rules for both.
NACLs can be used to block specific IP addresses from accessing your subnet.
Are aws security groups stateful? Yes, security group rules are stateful and you don’t need to specify inbound and outbound rules.
What aws stateful vs stateless – a stateless rule applies to nacls where you have to define rules for inbound and outbound traffic. Stateful rules apply to security groups.
Will aws security group allow internal traffic? Yes, simply allow a wide range of ephemeral ports as a security group rule.