Network ACLs vs Security Groups

AWS provides two distinct firewall mechanisms within a VPC. Security Groups operate at the instance level (technically at the ENI level) and are stateful. Network Access Control Lists (NACLs) operate at the subnet level and are stateless. Both are evaluated for any traffic entering or leaving a subnet and its associated instances. Using both in concert provides defence-in-depth: NACLs as a first line at the subnet boundary, security groups as the per-instance firewall. The SAA-C03 exam frequently compares these two mechanisms.

A Network ACL (NACL) is a numbered list of rules applied to all traffic crossing the boundary of a subnet. NACLs are stateless—each packet is evaluated independently. If you allow inbound TCP port 80, you must explicitly allow outbound return traffic (ephemeral ports 1024-65535) for the response to leave the subnet. Rules are evaluated in numerical order (lowest number first); the first matching rule applies and no further rules are checked. Each VPC comes with a default NACL that allows all inbound and outbound traffic.

NACL rules are evaluated in ascending rule number order (1 to 32766), and evaluation stops as soon as a rule matches—a lower-numbered Allow rule can be overridden by an even-lower-numbered Deny for the same traffic. AWS recommends numbering rules in increments of 10 or 100 to leave room for inserting rules later. Every NACL ends with a default rule (* DENY) that denies all traffic not matched by any explicit rule. This catch-all cannot be edited or deleted.

Because NACLs are stateless, you must account for both directions of every connection. When a client on the internet connects to your EC2 instance on port 443, the instance sends the response back to the client's ephemeral port (a random high port, typically 1024-65535 on Linux, 49152-65535 on Windows). Your NACL's outbound rules must explicitly allow this range. A common NACL configuration mistake is creating an Allow rule for inbound port 443 but forgetting to allow outbound ephemeral ports—causing connections to establish but responses to be silently dropped.

As a reminder: security groups are attached to instances (or ENIs), allow only explicit Allow rules (no Deny), are stateful (responses to allowed inbound traffic are automatically allowed outbound without a rule), and evaluate all attached rules together using OR logic. You can reference other security group IDs as sources/destinations, which is more maintainable than IP ranges. Security groups are the primary mechanism for instance-level access control, and NACLs add an additional subnet-level layer.

Critical comparison for the exam:

• Level: NACL = subnet; SG = instance (ENI)
• State: NACL = stateless; SG = stateful
• Rules: NACL = Allow AND Deny; SG = Allow only (implicit deny)
• Evaluation: NACL = in order (first match wins); SG = all rules evaluated (any Allow wins)
• Scope: NACL applies to all instances in the subnet; SG applies only to associated instances
• Inbound/Outbound: NACL needs explicit rules both ways; SG is stateful (only inbound rules needed for responses)

Use NACLs for: Blocking specific IPs (security groups cannot deny—only allow; NACLs can add explicit Deny rules to block known malicious IPs or scrapers). Subnet-wide rules (apply the same rule to all instances in a subnet without touching individual security groups). Additional defence layer (if a security group misconfiguration accidentally opens access, a NACL Deny rule at the subnet boundary can still block the traffic). In practice, most teams manage access primarily through security groups and use NACLs only for explicit IP blocking.

The default NACL (created with every VPC) allows all inbound and outbound traffic—it has rules 100 Allow All Inbound and 100 Allow All Outbound. Subnets not explicitly associated with a custom NACL use the default NACL. If you create a custom NACL, it starts with only the default Deny-All rule (rule *), blocking all traffic until you add explicit Allow rules. This means attaching a new custom NACL to a subnet will immediately block all traffic—make sure to add Allow rules before associating it with production subnets.

For inbound traffic to an EC2 instance: traffic first passes through the NACL at the subnet boundary (evaluated in rule order). If the NACL allows the traffic, it then reaches the security group on the instance—the security group must also allow it. Both must permit the traffic for it to reach the instance. For outbound traffic: security group is evaluated first (stateful—allow if it was a response to allowed inbound), then NACL (stateless—must have an explicit outbound Allow). Understanding this order clarifies why stateless NACL return-traffic rules are needed even with stateful security groups.

NACLs are a common source of hard-to-debug network issues because of their stateless nature. Symptoms: connections establish but data stops flowing (missing ephemeral port outbound rule); one-directional traffic (forgot inbound or outbound rule); specific IPs can't connect (a lower-numbered Deny rule is matching before the Allow rule). Debug method: use VPC Flow Logs to see whether packets are ACCEPT or REJECT at the NACL level. The flow log will show the rejected packets and their source/destination, helping pinpoint the missing rule.

The recommended pattern for multi-tier VPC security: NACLs on public subnets allow only ports 80, 443, and required ephemeral ports from the internet; deny all else. Public subnet security groups on ALB allow 80/443 from 0.0.0.0/0. Private app security groups allow only from the ALB security group ID. Private data security groups allow only from the app security group ID. This defence-in-depth ensures that even if one layer is misconfigured, another layer provides protection—a principle called least access at every layer.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: NACLs are stateless subnet-level firewalls that support both Allow and Deny rules evaluated in numbered order, security groups are stateful instance-level firewalls with Allow-only rules where all rules are evaluated together, and use NACLs for explicit IP blocking and subnet-wide rules, and security groups for fine-grained instance access control. This completes the VPC Basics module—next up we dive into RDS and Relational Databases on AWS.