Network ACL

What is a Network ACL?

A Network ACL (Access Control List) is a set of numbered rules that controls inbound and outbound traffic at the subnet level in a virtual private cloud (VPC). Each rule specifies whether to allow or deny traffic based on protocol, port range, and source or destination IP addresses. Network ACLs act as a stateless firewall—they evaluate each packet independently without remembering previous connections.

Network ACLs are one of two key security layers in cloud networking. Unlike security groups, which operate at the instance level and are stateful, Network ACLs work at the subnet level and require explicit rules for both inbound and outbound traffic to work together.

Why Network ACLs Exist

Network ACLs were created to provide an additional layer of security at the subnet boundary. They solve several critical problems:

• Explicit traffic denial: Security groups only allow rules; Network ACLs can explicitly deny traffic, useful for blacklisting specific sources or ports before allowing broader traffic
• Subnet-wide protection: Apply a single set of rules to all instances in a subnet without configuring each instance individually
• Stateless evaluation: Enable precise control over traffic flow in both directions, important for protocols that don't maintain persistent connections
• Defense in depth: Combine with security groups to create multiple security boundaries that each attack or misconfiguration must pass through

What Do Network ACLs Actually Do?

• Evaluate inbound traffic: Check every incoming packet against numbered rules in order, starting with the lowest rule number
• Evaluate outbound traffic: Check every outgoing packet against outbound rules in the same sequential order
• Allow or deny by rule: When a packet matches a rule, apply that rule immediately and stop evaluating remaining rules
• Apply to all instances: Protect all resources in the subnet simultaneously, regardless of their individual security group settings
• Block without learning: Stateless processing means the ACL doesn't remember that you allowed an inbound request—you must explicitly allow the response traffic outbound

When Would I Use a Network ACL?

You should configure Network ACLs when:

• You need to deny specific traffic: Your security policy requires explicitly blocking certain IP addresses, ports, or protocols at the subnet boundary
• You need defense in depth: You want multiple security layers so that a misconfigured security group won't expose your entire subnet
• You have strict stateless protocols: You're using protocols like UDP or SNMP that don't maintain persistent connections and benefit from explicit bidirectional rules
• You need subnet-wide rules: You want to apply uniform traffic controls to all instances in a subnet without managing individual instance configurations
• You're implementing network segmentation: You're dividing your cloud infrastructure into security zones with different traffic policies

When Would I NOT Use a Network ACL?

You might skip Network ACL configuration or use minimal rules when:

• Security groups are sufficient: For most applications, security groups alone provide adequate protection since they're stateful and easier to manage
• You need flexibility and stateful behavior: If you want traffic responses to flow automatically without explicit return rules, security groups are simpler
• You have simple traffic patterns: If all instances in a subnet need identical access rules, security groups at the instance level may be easier to audit
• You need to reference other security groups: Network ACLs only accept CIDR blocks as sources/destinations, not other security groups, limiting flexibility in dynamic environments
• You're prototyping or testing: During development, security groups provide faster iteration since you can add rules as needed

Real-World Example

Company A runs a multi-tier web application in AWS. They have three subnets: a public subnet for load balancers, a private subnet for application servers, and a database subnet for their database cluster.

The company creates a Network ACL on the database subnet with these rules:

• Inbound rule 100: Allow TCP port 3306 from the application subnet's CIDR (10.0.2.0/24)
• Inbound rule 110: Deny all traffic from 10.0.3.0/24 (a deprecated development subnet that previously had a security breach)
• Inbound rule 120: Deny all other traffic
• Outbound rule 100: Allow all traffic back to the application subnet

Additionally, database instances have security groups allowing port 3306 only from the application tier. This dual-layer approach means an attacker who compromises the application subnet still can't access the database because the Network ACL explicitly denies traffic from the quarantined subnet. A misconfigured security group also can't accidentally expose the database because the Network ACL provides a second checkpoint.

FAQ

Q: If Network ACLs are stateless, how do I let traffic responses come back?

A: You must create explicit outbound rules for responses. If an inbound rule allows TCP port 80 from any source, create an outbound rule allowing TCP port 1024-65535 to any destination to permit response traffic on high-numbered ephemeral ports.

Q: Can I use a Network ACL instead of security groups?

A: Network ACLs and security groups serve different purposes. Network ACLs protect subnets; security groups protect instances. You typically use both together—Network ACLs for subnet-level policy and security groups for instance-level control.

Q: What happens if a packet doesn't match any Network ACL rule?

A: It's denied. Network ACLs follow an implicit deny-all policy at the end. Unlike security groups which default to allowing all outbound traffic, Network ACLs require explicit allow rules for every traffic pattern you want to permit.

Q: Can I apply multiple Network ACLs to one subnet?

A: No, each subnet has exactly one associated Network ACL. You can create multiple ACLs and switch them, but a subnet can't have multiple active ACLs simultaneously.

Q: How do Network ACL rule numbers affect performance?

A: Rules are evaluated sequentially from lowest to highest number. Placing frequently matched rules at lower numbers (such as rule 100 before rule 200) ensures they're evaluated first, reducing evaluation time.

Summary

• Network ACLs are subnet-level firewalls that control inbound and outbound traffic using numbered, ordered rules
• They're stateless: Each packet is evaluated independently, requiring explicit rules for both request and response traffic
• They can deny traffic explicitly, unlike security groups which only allow—useful for blacklisting sources or blocking specific protocols
• They combine with security groups to create defense-in-depth security where multiple layers must be breached to access resources
• Rule order matters: Network ACLs evaluate rules sequentially by number, so rule 100 is checked before rule 200

Related Terms

Security Groups — Instance-level firewalls that are stateful and automatically allow responses to permitted inbound traffic, such as allowing outbound HTTP responses to inbound web requests.

VPC — Virtual Private Cloud, the isolated network environment in which you create subnets, instances, and apply Network ACLs.

Subnet — A segment of your VPC with its own CIDR block; all instances in a subnet share the same Network ACL.

Firewall — Security system that monitors and controls network traffic, such as a network appliance or software-based firewall protecting your instances.

Stateless vs. Stateful — Stateless systems evaluate each request independently without memory of previous traffic; stateful systems remember prior connections and adapt responses accordingly.