Network Access Control List (NACL)
The stateless subnet-level firewall in a VPC — numbered rules, explicit deny, and return-traffic gotchas that surprise everyone exactly once.
Last reviewed: July 25, 2026
What is a NACL?
A Network Access Control List filters traffic at the subnet boundary — every packet entering or leaving the subnet is evaluated against numbered rules processed in order until one matches (allow or deny), ending at an implicit deny-all. Two properties invert the security group model: NACLs support explicit deny rules, and they are stateless — return traffic is not automatically allowed.
Statelessness: the gotcha that defines NACL work
Allowing inbound 443 does nothing for the response, which leaves on an ephemeral port (1024–65535). Every functional custom NACL therefore pairs its inbound service rules with outbound ephemeral-port allowances, and vice versa for outbound-initiated traffic. Forgetting this produces the signature NACL incident: connections that half-work — SYNs arrive, responses die — which looks like an application bug until someone remembers the subnet has a custom NACL. The default NACL allows everything precisely because AWS knows most teams shouldn’t touch this.
When NACLs actually earn their place
Security groups are the primary control; NACLs add value in specific shapes: explicit deny of known-bad CIDRs (blocking an attacking range at the subnet edge — something allow-only SGs can’t express), coarse subnet isolation as defense in depth (data subnets that deny all inbound except from app-tier ranges, protecting even against a fat-fingered SG), and compliance frameworks that demand subnet-level controls on paper.
What people get wrong
- Reaching for NACLs first — most requirements are SG-shaped; NACL complexity should be earned by an explicit-deny or subnet-boundary need.
- Rule-number archaeology: sequential processing means an early broad allow silently shadows later denies; leave numbering gaps and audit order.
- Blocking ephemeral ports in one direction and creating asymmetric half-open mysteries.
Primary source: AWS VPC documentation — network ACLs
NACLs vs. Security Groups
Network ACLs are often confused with security groups, but the two operate at different scopes and with different default behaviors: a NACL applies at the subnet level, affecting every resource within that subnet, and is stateless, meaning inbound and outbound rules must each be explicitly defined since the NACL doesn’t automatically allow a response to traffic it permitted in the other direction. Security groups, by contrast, apply at the individual resource (instance) level and are stateful, automatically allowing return traffic for any connection that was permitted outbound or inbound. This makes NACLs better suited to broad, subnet-wide restrictions (like explicitly blocking a known malicious IP range across an entire subnet) while security groups handle the more granular, per-resource access control that forms the bulk of day-to-day network security configuration in most cloud architectures.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.