CloudNetworking.io
AWS Networking • Network ACL Fundamentals

AWS Network ACLs explained in simple terms

Network ACLs, often called NACLs, are subnet-level traffic filters in AWS. They help you control which traffic is allowed into and out of an entire subnet.

This guide explains Network ACLs in a practical way, including what they do, why they matter, how they work, and how they differ from Security Groups.

What A Network ACL is a subnet-level firewall in AWS.
Why It adds another layer of traffic filtering for subnet security.
When You use it when subnet-level traffic control is needed.
Where It is applied to subnets inside a VPC.
Who Cloud, DevOps, platform, and security teams work with it.
How By using ordered allow and deny rules for inbound and outbound traffic.

What is a Network ACL in AWS?

A Network ACL is a firewall that works at the subnet level. Instead of protecting one specific server or load balancer, it protects the entire subnet by applying traffic rules to everything inside that subnet.

It controls both inbound and outbound traffic by evaluating numbered rules. Each rule either allows or denies traffic based on protocol, port, and source or destination.

Real-life example

Think of Security Groups as security guards standing at the door of each room, while a Network ACL is like the security checkpoint at the entrance of the whole building floor. Everyone entering that floor must pass that checkpoint first.

Why are Network ACLs important?

Network ACLs matter because they provide an extra security layer at the subnet boundary. Even if a resource-level rule allows traffic, a restrictive NACL can still block it.

This can be useful when you want:

  • Subnet-wide control over traffic patterns
  • An extra protection layer for sensitive environments
  • Explicit deny rules, which Security Groups do not support
  • Broader security policy control at network segment level
Network ACLs are often used as an additional layer, not as a replacement for Security Groups.

When do you use a Network ACL?

You use Network ACLs when you want to control subnet-level traffic more explicitly. They are especially useful in environments where security teams want another checkpoint beyond resource-level Security Groups.

Common use cases include:

  • Restricting entire subnet traffic patterns
  • Creating extra defense for public-facing subnet segments
  • Applying deny-based filtering at subnet level
  • Standardizing security rules across all resources inside a subnet

Where does a Network ACL fit in AWS architecture?

A Network ACL is associated with a subnet. That means every resource inside that subnet is affected by the ACL rules.

In a simple AWS network design:

  1. The VPC defines the overall network boundary
  2. Subnets divide the VPC into smaller segments
  3. Route tables define where traffic goes
  4. Network ACLs control subnet-level traffic
  5. Security Groups control resource-level traffic

So NACLs sit between network design and the resources that live in the subnet.

Who should understand Network ACLs?

Network ACLs matter to:

  • Cloud engineers designing network segmentation
  • DevOps engineers troubleshooting blocked traffic
  • Security teams applying network-layer control standards
  • Platform engineers building reusable subnet security patterns

How do Network ACLs work?

Network ACLs use numbered rules processed in ascending order. The first matching rule decides whether the traffic is allowed or denied.

They are stateless, which is one of their most important characteristics. That means if you allow inbound traffic, you must also allow the return outbound traffic explicitly.

A Network ACL includes:

  • Inbound rules
  • Outbound rules
  • Rule numbers
  • Allow or deny action
  • Protocol, port, and CIDR matching
Stateless means request traffic and response traffic are treated separately. Both directions must be considered.

Security Groups vs Network ACLs

This is one of the most searched AWS networking topics, and it is important to understand clearly.

  • Security Groups work at resource level
  • Network ACLs work at subnet level
  • Security Groups are stateful
  • Network ACLs are stateless
  • Security Groups support allow rules only
  • Network ACLs support both allow and deny rules

Simple example

Suppose a Security Group allows port 443 to an EC2 instance, but the subnet NACL blocks that traffic. The connection will still fail because both layers must allow it.

Common real-world use case

Imagine a public subnet hosting a load balancer. The Security Group on the load balancer allows inbound HTTPS traffic from the internet. At the same time, the subnet NACL may also be configured to allow the required ports and deny unwanted traffic patterns.

In another example, a security team may use NACLs to restrict specific ranges from an entire subnet instead of configuring many individual resource rules.

Monitoring and logs

Network ACLs do not produce their own dedicated logs. To understand traffic behavior, you typically use VPC Flow Logs and related observability tools.

  • VPC Flow Logs: best source for network traffic visibility at VPC or subnet level
  • CloudWatch Logs: common destination for Flow Logs analysis
  • Reachability Analyzer: useful for understanding network path issues
If traffic is blocked and you suspect NACL behavior, VPC Flow Logs are usually the first place to investigate.

Common mistakes

  • Allowing inbound traffic but forgetting the return outbound rule
  • Blocking ephemeral ports required for return traffic
  • Assuming NACLs behave like Security Groups
  • Using overly complex rule numbering without documentation
  • Forgetting that rule order matters

Best practices

  • Keep NACL rules simple and intentional
  • Use Security Groups as the main resource-level protection
  • Use NACLs as an additional subnet-wide control layer
  • Document rule purpose and ordering
  • Test carefully when changing subnet traffic policies

Summary

AWS Network ACLs are subnet-level traffic filters that add another security layer to your VPC design. They are especially useful when you need ordered allow and deny logic at subnet level. Once you understand how NACLs differ from Security Groups, AWS traffic control becomes much easier to reason about.

Learn more from AWS official documentation

For deeper technical details, refer to AWS Network ACLs documentation .