A network ACL is a stateless subnet-level filtering control in AWS that allows or denies traffic based on configured rules. Because it evaluates inbound and outbound traffic independently, it is useful for coarse network boundaries, but it requires careful rule design to avoid unintended exposure or gaps in segmentation.
What a network ACL does in AWS
A network ACL is a subnet boundary control that evaluates traffic at the network layer and applies allow or deny rules independently in each direction. That makes it a coarse but important guardrail for controlling which packets can cross a subnet boundary.
Because it is stateless, the return path is not automatically permitted, so both inbound and outbound rules must be designed deliberately. In practice, that design choice is what makes the control useful for broad segmentation, but also easy to misconfigure when teams assume one rule will cover both directions.
How network ACLs differ from security groups
Network ACLs operate at the subnet level, while security groups are attached to resources and are stateful. The distinction matters because the ACL is better suited to coarse boundary enforcement, whereas the resource-level control is better suited to precise workload access policy.
In AWS architectures, the two controls are often layered rather than treated as substitutes. A subnet ACL can provide a backstop around a zone, while the instance or service policy handles the finer-grained decisions.
Why rule order and stateless design matter
Network ACLs are evaluated using numbered rules, so order affects which rule is matched first. A later allow rule will not help if an earlier deny rule already applies, and the reverse is also true when an overly broad allow is placed too early.
The stateless design also means each direction must be considered independently. If ingress is permitted but egress is incomplete, communication can fail in ways that look intermittent or hard to trace, especially when applications expect reply traffic, callbacks, or multi-hop flows.
Common design and operational patterns
Teams typically use network ACLs to define subnet boundaries, block obviously unwanted traffic, or create a coarse network segmentation layer around sensitive environments. They are often most valuable where a simple, explicit subnet filter is easier to reason about than a long list of per-resource exceptions.
They are less suitable as the only control for application access decisions, because they do not understand users, applications, or sessions. Their strength is broad traffic filtering, not identity-aware authorization or deep service policy.
Risk and Threat Considerations
Network ACLs can create exposure when rule sets are incomplete, overly permissive, or inconsistent across inbound and outbound paths. A single missed return rule or broad allow can weaken segmentation and create unintended reachability across subnets.
Failure mechanism: Stateless evaluation means each direction must be explicitly allowed, so a partial rule set can break expected traffic flows or leave a subnet open in one direction while appearing protected in another.
Impact: Misconfigured ACLs can cause application outages, accidental exposure of internal services, or gaps that make lateral movement and network-based abuse easier if an attacker reaches the subnet.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Network ACLs implement boundary filtering between subnet segments. |
| AC-4 — Information Flow Enforcement | ACL rule sets govern permitted traffic flows between network segments. | |
| Recommendation — Use SC-7 to enforce explicit subnet boundary filtering and segment trust zones. Apply AC-4 to restrict which traffic flows may enter or leave protected subnets. | ||
| NIST CSF 2.0 | PR.AA-05 — Network segmentation | Subnet ACLs support segmentation by separating network boundaries and traffic paths. |
| Recommendation — Use PR.AA-05 to segment networks and reduce lateral movement paths. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | ACLs are a foundational network defense control that should be reviewed alongside segmentation. |
| Recommendation — Use CIS-13 to harden boundary filtering and validate network path restrictions. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | Network ACLs are a concrete network security control under Annex A technology controls. |
| Recommendation — Apply A.8.20 to define and maintain secure network filtering boundaries. | ||
Practitioner Guidance
What to watch for: Use network ACLs as a deliberate boundary control, not as a substitute for workload-level policy. The most common mistake is assuming they provide stateful behavior, or assuming a single rule change is harmless because the control sits “at the network edge.”
Practitioner takeaway: Treat every ACL change as a bidirectional segmentation decision, because the control only works as intended when both path directions and rule order are designed together.
Related resources from NHI Mgmt Group
- How should teams verify ACL changes in an identity-based network before they rely on them in production?
- What are the signs that a network ACL is misconfigured for remote administration access?
- What happens when SSH is exposed through a broad network ACL instead of a restricted management path?
- Why has identity replaced the network perimeter as the primary security boundary?
