AWS Network ACL (NACL): What It Is and When to Use It

Definition

A Network ACL (NACL) is a stateless, subnet-level firewall in an Amazon VPC. Unlike Security Groups — which are stateful and apply at the ENI level — NACLs sit at the subnet boundary and evaluate every packet flowing into or out of the subnet. They support both allow and deny rules, numbered from 1 to 32766, and are evaluated in ascending numerical order with first-match-wins semantics. An implicit DENY ALL catch-all (rule number *) closes the list.

NACLs are the secondary firewall layer in AWS's defense-in-depth networking model. Security Groups handle the day-to-day allowlist; NACLs provide a broad deny mechanism at the subnet boundary — ideal for blocking known-bad CIDRs before they even reach an instance's SG.

How It Works

Each VPC has a default NACL that allows all inbound and all outbound traffic on every subnet. When you create a subnet, AWS automatically associates it with this default NACL unless you specify another. You can create custom NACLs, which start with deny all inbound and deny all outbound — you must add allow rules explicitly (and configure both directions, because NACLs are stateless).

For each direction (inbound, outbound), a NACL has an ordered list of rules. Each rule specifies:

Rule number — 1 to 32766. Lower numbers are evaluated first.
Type / Protocol — TCP, UDP, ICMP, or custom protocol number.
Port range — e.g., 443, or 1024–65535 for ephemeral return ports.
Source (inbound) or Destination (outbound) — CIDR only (no SG IDs).
Allow / Deny.

When a packet hits a subnet boundary, AWS evaluates rules from lowest number upward. The first rule that matches determines the outcome (allow or deny) — no further rules are evaluated. If no rule matches, the implicit * rule denies the packet.

Stateless — the big gotcha

Because NACLs are stateless, you must explicitly allow traffic in both directions. For a client making an HTTPS request, the subnet NACL must allow:

Inbound 443/tcp from the client CIDR (the request).
Outbound 1024–65535/tcp to the client CIDR (the TCP reply, which uses an ephemeral source port on the client).

If either direction is missing, the connection fails. Security Groups handle this automatically; NACLs do not.

Key Features and Limits

Scope: one NACL can be associated with multiple subnets, but each subnet has exactly one NACL at a time.
Rules: 20 inbound + 20 outbound by default (soft, raisable to 40 each, max 40 total per direction at a hard limit).
Rule numbers: 1–32766 (plus *). Convention: number by 100s (100, 200, 300...) to leave room for future inserts.
Evaluation: lowest number wins (first-match).
Stateless: both directions must be configured.
Rule types: Allow and Deny (unlike Security Groups).
Source/Destination: CIDR only — no Security Group IDs, no prefix lists, no DNS.
Default NACL: allows everything inbound and outbound; associated with all subnets unless overridden.
Custom NACL: denies everything by default; you must add allow rules.
Ephemeral port range: Linux (1024–65535), Windows (49152–65535), NAT Gateway (1024–65535), ELB (1024–65535). Always open the widest range for simplicity.
Changes apply immediately to in-flight connections.

Common Use Cases

Blocklist known-bad CIDRs — deny rules at the subnet edge (e.g., flagged IPs from threat intel feeds) prevent traffic from even reaching Security Groups.
Regulatory segmentation — enforce "no outbound except to approved CIDRs" at the subnet level for PCI/HIPAA workloads.
DDoS hardening layer — broad deny rules for suspicious source countries or CIDRs as part of a WAF + Shield + NACL stack.
Accidental-exposure defense — an extra safety net if an SG is misconfigured (e.g., SG accidentally opens 22 to 0.0.0.0/0 — a NACL can block it).
Isolated subnet enforcement — ensure database subnets never communicate outside the VPC's private CIDR.
Compliance audit controls — NACLs are easier to audit centrally than many fine-grained SGs for "no egress to internet" invariants.

Pricing Model

NACLs are free. There is no charge for rules, no charge for evaluations, no charge for NACL creation or association. Like Security Groups, you pay only for underlying resources and data transfer. Because NACLs are free and evaluated in the hypervisor, they impose no performance penalty at typical rule counts.

Pros and Cons

Pros

Supports deny rules — essential for blocklists and CIDR blocks.
Subnet-level enforcement — one change protects every instance in the subnet.
Useful as a broad defense-in-depth layer in addition to SGs.
Free and zero-latency.
Rule numbers make priority explicit and predictable.

Cons

Stateless — you must manually allow return traffic (ephemeral ports), which is error-prone.
CIDR only — cannot reference Security Groups or prefix lists, so dynamic targets (like scaling app tiers) are hard to model.
First-match-wins — a rule with the wrong number can silently override the correct rule.
20-rule default limit is tight; raising it has diminishing returns as rules multiply.
Harder to reason about than SGs — most teams rely on SGs as the primary control and use NACLs sparingly.

Comparison with Alternatives

| Feature | Network ACL (NACL) | Security Group (SG) | AWS Network Firewall | AWS WAF | | --- | --- | --- | --- | --- | | Scope | Subnet | ENI (instance) | VPC (firewall endpoints) | ALB / CloudFront / API Gateway | | State | Stateless | Stateful | Stateful (Suricata) | Stateful | | Rule types | Allow + Deny | Allow only | Allow / Deny / Alert / Suricata | Allow / Block / Count / CAPTCHA | | References | CIDR only | SG IDs, prefix lists, CIDRs | Rule groups, Suricata rules | IP sets, rate, managed rules | | Rule eval | First-match by number | All rules evaluated | Ordered stateful | Priority-ordered | | Price | Free | Free | Paid (per endpoint + per GB) | Paid (per request + WebACL) |

Typical layered design: NACL (broad deny) + SG (allowlist) + Network Firewall (deep inspection) + WAF (Layer 7).

Exam Relevance

Solutions Architect Associate (SAA-C03) — must-know: NACL vs SG, statelessness, ephemeral ports, rule ordering, default vs custom.
SysOps Administrator (SOA-C02) — troubleshooting asymmetric traffic caused by stateless NACLs.
Security Specialty (SCS-C02) — defense-in-depth, blocklist automation via Lambda updating NACL rules, Config compliance.
Advanced Networking Specialty (ANS-C01) — ephemeral port ranges across OS/services, multi-subnet NACL associations, NACL interaction with NAT Gateway and ELB.

Classic exam traps: NACLs are stateless — always remember to open the return ephemeral port range. NACLs support deny rules; SGs do not. NACLs cannot reference Security Groups. The default NACL allows all; custom NACLs deny all until rules are added. Rule order matters — a deny rule at number 90 overrides an allow at number 100.

Frequently Asked Questions

Q: What is the difference between a Network ACL and a Security Group?

A: Security Groups are stateful, ENI-level firewalls that only support allow rules — return traffic is automatic, and you can reference SG IDs as sources. Network ACLs are stateless, subnet-level firewalls that support both allow and deny rules, evaluated in numerical order with first-match-wins; they only reference CIDRs. SGs are the primary access-control tool; NACLs are a secondary broad-deny layer. Stateless means NACLs need explicit outbound rules for return (ephemeral) ports.

Q: Why do I need to allow the ephemeral port range in a NACL?

A: Because NACLs are stateless, the response direction needs its own explicit rule. When a client on the internet makes an HTTPS request to your server, the TCP handshake uses source port = ephemeral (1024–65535 on Linux, 49152–65535 on Windows) and destination port = 443. The server's response goes from source 443 back to the client's ephemeral port. If your NACL's outbound rules don't allow that full ephemeral range to the client CIDR, the handshake fails. Security Groups handle this automatically because they track connection state.

Q: Does a subnet's NACL override its Security Groups?

A: No — both are evaluated independently. A packet entering a subnet must be allowed by the NACL (inbound) and by the destination ENI's Security Group (inbound). A packet leaving must be allowed by the ENI's SG (outbound) and the NACL (outbound). If any layer denies, the packet is dropped. This layered evaluation is why defense-in-depth works: a blocked NACL rule prevents traffic from ever reaching an SG, and vice versa.

This article reflects AWS features as of 2026. AWS services evolve rapidly — always verify against the official Network ACL documentation before making production decisions.