Security groups already filter traffic per workload in a VPC. When is it worth also managing network ACLs, and what does that decision cost you operationally?

## The honest default The answer that most experienced practitioners actually give is: leave network ACLs alone. The default NACL that ships with a VPC allows everything in both directions, and in the majority of well-run AWS estates it stays that way. All segmentation lives in security groups. That is not laziness — it follows from what the two mechanisms are good at. Security groups attach to the workload's network interface, so a rule follows the workload rather than its location. They are stateful, so you write one rule instead of two. They compose without ordering surprises, since every attached group's allows are evaluated as one set. And they can reference **another security group** as a source, which turns a rule from an address statement into an identity statement that survives scaling, instance replacement and re-planning of the address space. ## The two things a NACL can do that a security group cannot **Explicit deny.** A security group has no deny action; absence of an allow is the only denial available. So "block this CIDR range" is inexpressible in a security group without enumerating every permitted range instead. In a NACL, a low-numbered deny short-circuits before the allow rules below it, and it covers every workload in the subnet at once. Blocking an abusive source range, or fencing off a range that must never appear on the wire, is a genuine NACL job — though for public HTTP traffic a web application firewall or the load balancer is usually the better place, and for anything at scale you want a managed source of ranges rather than hand-maintained rules. **A boundary the workload's owner cannot widen.** IAM lets you grant a team `ec2:AuthorizeSecurityGroupIngress` on their own groups while withholding `ec2:CreateNetworkAclEntry` entirely. The subnet then carries a ceiling that the application team can operate freely beneath but cannot raise. In a regulated environment — a subnet that must never egress to the internet, a data subnet that must only ever speak to one CIDR — that separation is worth real money, and an auditor understands it immediately. Note that Service Control Policies at the organization level and VPC endpoint policies solve overlapping problems and are often the better instrument; the NACL's distinguishing feature is that it acts on packets, not on API calls. ## What it costs **Statelessness doubles the rule set and invites outages.** Every permitted flow needs a rule in each direction, and the return rule is written over an ephemeral port range — recommended as `1024-65535`, because Linux, Windows, NAT gateways and load balancer nodes all source from different ranges. Get it wrong and connections hang rather than fail cleanly. The return rule is also so wide that it dilutes the security value people imagine they are buying. **The rule budget is small.** As of 2025 the default quota is 20 rules per network ACL, raisable to 40, and AWS warns that raising it can affect network performance. Twenty rules, halved by the two-directions requirement, is nowhere near enough for application-level segmentation — which is a design signal, not an inconvenience. NACLs were built for a handful of coarse rules. **No identity, only addresses.** NACL rules take CIDR blocks; they cannot reference a security group. Every rule is therefore pinned to the address plan and goes stale when subnets are added, resized or repurposed, and a reviewer cannot tell from the rule what it was meant to protect. **Ordering is a footgun.** First match wins, so a low-numbered deny silently shadows a correct allow below it, and inserting a rule means thinking about numbering. Leave wide gaps. **Failures are silent.** A denied packet is dropped, not rejected, so the symptom is a timeout with no error anywhere, and diagnosis needs flow logs and someone who reasons in terms of stateless evaluation. ## How to decide Ask what the control is actually for. - *Application segmentation — which service may call which* → security groups, referencing each other. Never a NACL. - *Blocking a specific range across a subnet* → a NACL deny, kept to a few rules, or a WAF if it is public HTTP. - *A non-negotiable ceiling a team cannot raise* → a NACL, backed by IAM that withholds the ACL permissions; consider whether an SCP or endpoint policy expresses it better. - *Preventing internet egress from a subnet* → the absence of a route to a NAT gateway or internet gateway is the stronger and simpler control; a NACL deny is at most a belt-and-braces addition. That last point is the mature answer. Much of what people reach for NACLs to accomplish is better achieved by not having the route, not having the endpoint, or not having the permission. Defence in depth is a real principle, but each layer has to be maintained by someone, and a stale layer that nobody understands is a liability at the next incident. ## The organisational angle If you do adopt NACLs, treat them as platform infrastructure: a small standard rule set applied uniformly, versioned in code, changed rarely and by one team. The failure mode to avoid is a per-subnet snowflake that a departing engineer wrote, that nobody dares change, and that everyone silently works around by putting new workloads in a different subnet.