How Network ACLs Filter Subnets

A network ACL (NACL) is a firewall that operates at the subnet boundary. Every packet entering or leaving a subnet is evaluated against the NACL associated with that subnet, regardless of which instance sent or received it. It is the second layer of network defense alongside security groups.

NACL rules are numbered and evaluated in ascending order. AWS checks rule 100 before 200, and the first matching rule wins, stopping evaluation. This ordering is the opposite of security groups, where all rules combine with no priority. Leave gaps (100, 200, 300) so you can insert rules later.

Unlike security groups, NACLs support both allow and deny rules. This lets you block a specific malicious IP or CIDR range outright, something a security group cannot do. A common pattern is denying a known bad source at a low rule number before broader allow rules.

Each NACL has independent inbound and outbound rule sets, each with its own numbering. Because NACLs are stateless, you must explicitly handle both directions of every conversation, including the return traffic.

The default NACL created with a VPC allows all inbound and all outbound traffic, so it is effectively transparent. Any custom NACL you create starts by denying all traffic in both directions until you add allow rules. Subnets without an explicit association use the default NACL.

A subnet can be associated with exactly one NACL at a time, though one NACL can guard many subnets. This is the reverse of security groups, where a resource can have many. NACLs apply broadly to everything in the subnet, making them a coarse control.

Every NACL ends with an implicit * rule that denies anything not matched by a numbered rule. You cannot edit or remove it. If a packet falls through all your numbered rules, the asterisk denies it, so forgetting a needed allow rule silently breaks traffic.

Because NACLs are stateless, return traffic uses ephemeral ports (typically 1024–65535 for Linux, 49152–65535 for Windows). You must add outbound or inbound allow rules covering this range, or responses get dropped. This is the classic NACL gotcha the exam loves to test.

NACLs shine when you must block an IP range across a whole subnet quickly during an incident. A deny rule at a low number stops that source from reaching any instance. Security groups cannot do this because they only allow, making NACLs valuable for rapid containment.

Treat NACLs as a blunt, subnet-wide instrument and security groups as the fine, per-resource tool. Most architectures rely primarily on security groups and use NACLs sparingly for explicit deny scenarios, keeping the default permissive unless a specific block is needed.

NACL decisions, like SG decisions, are observed through VPC Flow Logs, which show the final accept or reject for each flow. Flow Logs do not say which control made the decision, so understanding rule order helps you reason about why a packet was rejected.

Test your understanding of NACL evaluation.

Network ACLs are stateless, ordered firewalls at the subnet boundary supporting both allow and deny. Rules are numbered and the first match wins, ending with an uneditable deny-all asterisk. Custom NACLs deny everything until you add rules. Because they are stateless you must allow ephemeral ports for return traffic. Use them for coarse, fast subnet-wide blocks of bad IPs.