AWS Network ACLs vs Security Groups: Scope, State, and Multi-AZ Design

Yes, one AWS Network ACL (NACL) can be associated with multiple subnets, including subnets in different Availability Zones, as long as those subnets belong to the same VPC. A subnet itself cannot span Availability Zones: every subnet belongs entirely to one Availability Zone.

Security Groups work at a different level. They are associated with resources through their network interfaces, not with subnets. The same Security Group can be attached to resources in multiple subnets and Availability Zones within a VPC, and one network interface can have multiple Security Groups.

This is Part 64 of the AWS Cloud Practitioner Study Notes. For the broader VPC firewall topic, see AWS Security Groups and Network ACLs.

The short answer

One NACL  → many subnets in the same VPC
One subnet → one NACL at a time

One Security Group → many resource network interfaces
One network interface → multiple Security Groups

A useful architecture picture is:

Region
└── VPC
    ├── Availability Zone A
    │   └── Subnet A ── NACL-Shared ── EC2 ENI ── SG-Web
    └── Availability Zone B
        └── Subnet B ── NACL-Shared ── EC2 ENI ── SG-Web

NACL-Shared is associated with both subnets. SG-Web is attached to the appropriate EC2 network interfaces in both subnets. The subnet-to-NACL relationship and the ENI-to-Security-Group relationship are separate.

How Network ACL associations work

A Network ACL is an optional layer of traffic control at the subnet boundary. Every subnet is associated with one NACL at a time. If you do not explicitly associate a subnet with a custom NACL, AWS associates it with the VPC’s default NACL.

The association rules are:

Relationship	Allowed?
One NACL associated with many subnets	Yes
Those subnets located in different AZs	Yes, within the same VPC
One subnet associated with multiple NACLs simultaneously	No
One subnet spanning multiple AZs	No
One NACL shared by subnets in different VPCs	No

NACLs have separate inbound and outbound rules. They are stateless, so a response is not automatically allowed just because the original request was allowed. If a connection needs to work in both directions, the relevant inbound and outbound rules must permit both directions.

NACL rules can explicitly allow or deny traffic. Rules are evaluated from the lowest rule number to the highest, and the first matching rule is applied. This ordering is different from Security Groups, which do not use rule numbers in the same way.

How Security Group associations work

A Security Group acts as a virtual firewall for associated resources. For EC2, the association is made to the instance’s network interface. Other AWS services may expose the same concept through a resource’s network interface or service-specific attachment.

Security Group rules are:

• Stateful: return traffic is automatically allowed for an allowed connection.
• Allow-only: Security Groups do not have explicit deny rules.
• Aggregated: when multiple Security Groups are attached to an interface, their allow rules are combined.
• Reusable: the same Security Group can be attached to many compatible resources across subnets and Availability Zones.

For example, SG-Web could be attached to web servers in a public subnet in AZ-A and another public subnet in AZ-B. A single EC2 instance can also have SG-Web and SG-Monitoring attached at the same time.

The important correction is that a Security Group does not “span subnets” in the same association sense as a NACL. It is not associated with a subnet at all. It is reused by attaching it to the network interfaces of resources located in those subnets.

How both controls affect traffic

When a client connects to an instance, both layers can matter:

Client traffic
      ↓
Subnet boundary: NACL inbound rule
      ↓
Resource network interface: Security Group inbound rule
      ↓
EC2 instance

The response must also satisfy the applicable controls. The Security Group tracks connection state, so response traffic for an allowed connection is automatically permitted. The NACL does not track state, so its outbound rules must allow the response traffic as well.

This means that a permissive Security Group cannot override a NACL deny. Conversely, a permissive NACL cannot override a Security Group that has no matching allow rule. Both controls must allow the traffic.

Multi-AZ example

Suppose a company has web servers in two Availability Zones:

VPC: 10.0.0.0/16
│
├── AZ-A
│   └── Public Subnet A ── NACL-Web
│       └── Web EC2 ── SG-Web
│
└── AZ-B
    └── Public Subnet B ── NACL-Web
        └── Web EC2 ── SG-Web

This design is valid. NACL-Web is associated with both subnets, and SG-Web is attached to both web servers’ network interfaces.

If the NACL allows HTTPS inbound but does not allow the required return traffic outbound, connections can fail even when SG-Web is configured correctly. If the NACL allows the traffic but SG-Web does not allow HTTPS inbound, the instances still cannot receive the connection.

Sharing a NACL is convenient when several subnets need identical subnet-level rules. However, changing that NACL changes the effective boundary rules for every associated subnet, so teams should use shared associations deliberately.

Exam comparison

Feature	Security Group	Network ACL
Main scope	Resource or network interface	Subnet
Association	Attached to compatible resources	Associated with a subnet
One control reused by many targets	Yes, many resources	Yes, many subnets
Multiple controls on one target	Multiple Security Groups per interface	One NACL per subnet at a time
Stateful?	Yes	No
Explicit deny rules?	No	Yes
Inbound and outbound rules	Yes	Yes
Rule evaluation	Matching allows are combined	Lowest-numbered matching rule wins
Applies across AZs?	Yes, by reusing it on resource ENIs	Yes, by associating it with subnets in each AZ

Common mistakes

“A subnet can span multiple AZs”

It cannot. Create separate subnets for separate Availability Zones. You can then associate those subnets with the same NACL if they are in the same VPC.

“A NACL attaches directly to an EC2 instance”

It does not. A NACL applies to the subnet. The Security Group is the resource-level control commonly associated with an EC2 instance’s network interface.

“Security Groups can deny a specific IP”

Security Groups are allow-only. To explicitly deny traffic at the subnet boundary, use a NACL rule or another appropriate network control.

“Allowing inbound traffic in a NACL allows the response automatically”

NACLs are stateless. Add the required outbound rule for the response path. Security Groups are stateful, so their return-traffic behaviour is different.

Memory trick

NACL = Neighborhood gate
       Controls the whole subnet
       Allows and denies
       Stateless

SG   = Server guard
       Controls the resource ENI
       Allows only
       Stateful

The exam-ready answer is: a NACL can be associated with many subnets across multiple Availability Zones in the same VPC, but each subnet has only one NACL at a time. A Security Group is attached to resource network interfaces, can be reused across subnets and AZs, and multiple Security Groups can be attached to one interface.

Sources

• AWS: Control subnet traffic with network access control lists
• AWS: Control traffic to your AWS resources using security groups
• AWS: Subnets for your VPC