Network ACL

What Network ACLs Do in a Cloud Network

A network ACL is a subnet-level packet filter that sits on the boundary of an AWS VPC subnet. It lets you permit or deny traffic with ordered rules, but it evaluates inbound and outbound directions separately, so the policy must be designed with both paths in mind.

That stateless design makes a network ACL useful for coarse segmentation and broad guardrails, especially when you want a simple control at the subnet edge rather than a workload-level policy. It is not a substitute for application-layer authorization or a finely tuned host firewall, because it only sees traffic that matches its own rule set.

How Network ACLs Differ From Security Groups

The most important practical distinction is that network ACLs are stateless, while security groups are stateful. With a network ACL, return traffic is not automatically allowed just because the initial request was allowed, so both ingress and egress rules must be considered explicitly.

That difference matters in AWS designs where segmentation is layered. Security groups are often better for instance- or workload-specific policy, while network ACLs are better for subnet-wide boundaries, default-deny patterns, or an extra control where you want the subnet itself to reject traffic before it reaches any resource inside it.

Because they operate at different levels, the two controls are complementary rather than interchangeable. A security group can allow a workload to talk to another workload, while a network ACL can still block that path at the subnet edge if the subnet policy is stricter.

Rule Design and Traffic Flow

Network ACL rules are evaluated in sequence, so rule order and rule specificity are part of the security model. Broad allow rules placed too early can weaken later denies, and broad denies can inadvertently cut off legitimate return traffic, endpoint connectivity, or administrative access.

In practice, the hardest part is usually not creating a long rule list, but making sure the rule set matches the real traffic pattern of the subnet. That includes ephemeral ports, asymmetric flows, shared services, and any AWS service access that depends on predictable return paths.

A well-designed ACL should reflect the actual network boundary you are trying to enforce. If the subnet hosts a public-facing tier, a private application tier, or shared egress services, the rule set should be reviewed as a boundary policy, not as a mere checklist item.

Operational Uses and Common Failure Modes

Network ACLs are most valuable when they are used deliberately as a coarse control for exposure reduction, blast-radius limitation, or subnet separation. They are also useful as a compensating layer when teams want an explicit subnet rule set that complements route design and security group policy.

Common failure modes include accidental overexposure from permissive rules, broken connectivity from missing return-path rules, and policy drift when subnet roles change but the ACL does not. Another frequent mistake is assuming the ACL will behave like a stateful firewall, which leads to traffic being blocked even though the first packet was allowed.

For AWS environments, the safest mental model is that a network ACL is a simple network boundary control with limited context. It should be kept understandable, tightly scoped, and aligned to the subnet’s purpose, because complexity quickly turns it from a safeguard into a source of outages.

Review, Testing, and Change Control

Any change to a network ACL should be tested against the flows the subnet actually needs, including ingress, egress, and return traffic. That review should be driven by the subnet’s role, the services it contains, and the exposure level the organisation wants at that boundary.

It is also important to review ACLs after architecture changes such as subnet redesigns, new endpoints, or routing changes. A rule set that was correct for one workload pattern can become either too permissive or too restrictive once the network layout evolves.

Operationally, the best way to keep a network ACL useful is to treat it as part of the subnet’s documented security baseline. That makes it easier to spot unintended gaps, detect rule drift, and understand whether a connectivity problem is caused by the ACL or by another layer of the network stack.

Risk and Threat Considerations

Network ACLs can create both exposure risk and availability risk because they are easy to misconfigure and easy to misunderstand. A permissive rule can leave a subnet more exposed than intended, while an incomplete deny or an overly broad block can interrupt legitimate traffic and create service disruption.

Failure mechanism: The control is stateless and rule-order dependent, so a small mistake in directionality, port coverage, or sequence can either open an unintended path or block a needed one.

Impact: The result can be subnet-level exposure, traffic interception opportunities, broken application connectivity, or an outage that is difficult to diagnose because the control only operates at the network boundary.

Practitioner Guidance

What to watch for: Use network ACLs when you need a clear subnet boundary, but keep the rule set intentionally simple and aligned to one security purpose. A complex ACL usually signals that the subnet design or segmentation model needs refinement, not just more rules.

Governance implication: Ownership should be explicit, because ACL drift is common when multiple teams share a VPC. The control works best when the network boundary, the subnet role, and the rule review process are documented together.

Practitioner takeaway: Treat the ACL as a coarse guardrail, then validate real traffic flows separately so you do not mistake a static rule list for end-to-end network security.

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?
• What breaks when an AWS VPC network ACL allows egress from blocked ports?