Visual overview
Stateful · resource level
Allow rules · protocol/port/source or destination · response traffic tracked
Stateless · subnet level
Allow + deny rules · numbered evaluation · return path evaluated separately
Network placement, subnet controls, and resource controls must all permit the intended path.
Technical reference
Security groups and NACLs differ by placement, state and rule semantics.
Resource/network-interface level; response traffic for an allowed flow is tracked.
Subnet boundary; inbound and outbound return paths are evaluated independently.
Rules are evaluated in numbered order until a matching rule is found.
Traffic decisions depend on the network tuple, not on application identity alone.
Security groups protect resources with stateful rules
A security group acts as a virtual firewall for associated resources or network interfaces. Rules specify allowed inbound or outbound traffic using dimensions such as protocol, port range and source or destination. Security groups use allow rules rather than explicit deny rules. Their stateful behavior is crucial: when traffic is permitted in one direction, response traffic for that connection is automatically tracked and allowed back even if a separate reverse-direction rule would not independently permit it.
This makes security groups the primary workload-level network authorization control in VPC designs. Rules can reference CIDR ranges and, in supported situations, other security groups. Referencing another security group expresses trust in resources associated with that group rather than hard-coding individual instance IP addresses, which is useful for dynamic application tiers.
Network ACLs protect subnet boundaries and are stateless
A network access control list (network ACL or NACL) is associated with subnets and controls inbound and outbound traffic at that subnet boundary. NACLs support both allow and deny rules. Because they are stateless, permitting an inbound request does not automatically permit the response: the outbound rules must also allow the response traffic, and the reverse is true for outbound-initiated connections.
NACL rules are evaluated in rule-number order from the lowest numbered rule upward until a match is found, after which evaluation stops. This makes rule ordering a technical parameter rather than decoration. Broad allows placed before intended denies can produce surprising results, so rule sets should be kept deliberate and reviewed from the perspective of both traffic directions.
Ports and ephemeral return traffic matter
Statefulness changes how return traffic is handled. With a security group, the connection-tracking behavior covers responses to permitted flows. With a NACL, a client-side ephemeral port used for the response path may need to be allowed explicitly according to the client or operating system behavior. This is a common reason a seemingly correct one-way NACL rule set fails in practice.
Troubleshooting should therefore identify the source, destination, protocol and ports for both directions and then inspect every applicable layer: route tables, source/destination addressing, security groups and NACLs. VPC Flow Logs can provide evidence about accepted or rejected flows, while application logs clarify whether traffic reached the service and failed higher in the stack.
Key takeaways
- 01
Security groups are stateful allow-rule controls associated with supported VPC resources/network interfaces.
- 02
Network ACLs are subnet-level stateless controls that support both allow and deny rules.
- 03
NACL rule numbers affect evaluation order; return paths must be permitted explicitly because NACLs do not track connection state.
- 04
A valid route does not override a security rule, and an allowed security rule does not create a route.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.