Network ACLs

A network ACL is a stateless packet filter at the subnet boundary. It is the second layer of network security in a VPC, alongside security groups, and the only one that can express a deny.

Association

Network ACLs attach to subnets, not to instances.
Every subnet must have exactly one network ACL. If you do not associate one, the VPC’s default ACL applies.
One network ACL can be associated with many subnets.
A network ACL belongs to a VPC and cannot be used in another, even in the same Region.
Because subnets live in Availability Zones, a network ACL indirectly affects traffic at the zone level — but it is not associated with a zone, a VPN or a Region.

Network ACLs have no IP address of their own.

Rules

Each rule has a number, a protocol, a port range, a source or destination CIDR, and allow or deny.
Rules are evaluated in ascending number order, and the first match wins. A permissive rule at number 100 is applied before a restrictive one at number 200, whatever the intent.
Numbering rules in gaps — 100, 200, 300 — leaves room to insert one later without renumbering.
There is an implicit deny at the end of every rule list, expressed as rule *.
Inbound and outbound rules are separate lists.

Statelessness

A network ACL evaluates every packet independently. It does not track connections.

An inbound rule allowing TCP 443 permits requests to arrive. The response leaves the subnet from port 443 to the client’s ephemeral port, and needs a matching outbound rule. Because the client chooses that port and the range varies by operating system, the outbound rule usually has to allow 1024–65535.

The same applies in reverse: an outbound rule allowing instances to reach the internet on 443 needs an inbound rule for the responses on the ephemeral range.

This is the single largest difference from security groups, which are stateful and handle return traffic automatically. It is also the commonest cause of a connection that establishes and then hangs.

The default network ACL

Creating a VPC creates a default network ACL that allows all inbound and outbound traffic. It is associated with every subnet until you associate a custom one.

A network ACL you create yourself starts with the opposite posture: it denies everything until you add rules. Associating a newly created, empty ACL with a live subnet stops all traffic to it.

Where a network ACL earns its place

Security groups carry most of the policy: they are stateful, they can reference other security groups, and they follow the workload. A network ACL is worth configuring for:

Blocking a specific address range. Security groups have no deny rule; a network ACL is the only place to express one.
A coarse subnet boundary. A database subnet whose ACL permits traffic only from the application subnet range is a backstop against a security group being opened up by mistake.
Compliance requirements for defence in depth at more than one layer.

Keep the rules few and coarse. A network ACL with dozens of narrow rules is hard to reason about in first-match order, and duplicates work the security groups are already doing.