Network ACLs or NACLs are one of the additional layers of security AWS provides to safeguard your resources in the AWS Cloud. It acts as a firewall for controlling traffic in and out.

Image Source: docs.aws.amazon.com/vpc/latest/userguide/VP..

When You create a new VPC, it comes with a default NACL which allows all ingress/egress(or inbound/outbound) traffic but when you create a custom NACL it denies all the inbound and outbound traffic by default.

If you don't explicitly associate a subnet with a network ACL, the subnet is automatically associated with the default network ACL.

Features of NACLs

1. You can apply NACL at the Subnet level. (A subnet can be associated with only one NACL, you can attach multiple subnets to the same NACL though).
2. You can specify in the rules that if you want to ALLOW or DENY the traffic that matches the particular rule.
3. These are stateless. It means if you allow inbound traffic on port 3000 in NACL, it won't allow the outbound or returning traffic by default (for requests made on port 3000), you have to allow the port(if you know already what port will be used for returning traffic) or port range in the Outbound Rules of NACL (for example, for web HTTP requests, it uses ephemeral ports i.e. 1024–65535).
4. When you are creating rules for an NACL you have to provide that entry a number (max is 32766), the reason for this is, AWS evaluates the rules in order, starting with the lowest numbered rule, to determine whether traffic is allowed in or out.
5. AWS recommends that we should create rules in increments (for example, increments of 10 or 100) so that we can insert new rules later on.
6. NACL rules are applied on the traffic which is inbound or outbound but not for the traffic within resources of the subnet.

How NACLs looks in AWS Console

Difference b/w Security Groups and NACLs

Practical Example

1. Suppose you set up a Web Server on an EC2 that is serving req at port 80.
2. Assume you associated an SG that allows all traffic.
3. Now, you created a custom NACL, as you have just read above that a new NACL denies all traffic. And attached this NACL to the subnet where our EC2 is.
4. Now, You tested the EC2 Public IP with port 80 using curl to check the response but it got timed out. (REASON - NACL is at the subnet level and denying all traffic)
5. Okay, So Now you added a port 80 allow rule in the inbound rules in NACL to allow traffic on port 80.
6. Back to Terminal, Tried curl again but wait what, why it is still not working? REASON/EXPLANATION -> So this is how it behaves, aka stateless behavior. Your web server listens at port 80, that is true but when sending the response it uses some random port (also called short-lived aka ephemeral ports)
7. Now In the NACL Outbound rules, allow traffic for ephemeral ports (1024–65535).
8. Now if you try curl you will be able to see the response in your terminal because now NACL allows the outbound traffic as well. 🎊🎉

Where NACLs are perfect and SGs are not?

There can be a few use cases where your requirement can not be fulfilled by Security Groups and you have to use NACLs. For example - Suppose you want to block traffic from specific IPs, as SG doesn't have the feature of explicitly DENY you have to use NACLs only.

and Remember! NACL is the first line of defense, SGs is the second!

References

1. docs.aws.amazon.com/vpc/latest/userguide/vp..
2. digitalcloud.training/certification-trainin..
3. stackoverflow.com/a/53625507
4. qr.ae/pGS8f1

Thanks for reading! have a nice day!

Wanna buy me a Coffee ☕ ?