Security groups and network ACLs are often taught as a comparison table: stateful versus stateless, resource-level versus subnet-level, allow-only versus allow-and-deny. Those differences are accurate, but they do not answer the harder design question. An architect needs to know which control should carry the everyday access policy, which one should provide a coarse boundary, and when adding both improves defense rather than creating two places for the same rule to drift.
The distinction matters directly to SAA-C03 because secure architecture depends on choosing controls that fit the trust boundary. In production, it also affects troubleshooting speed. A stateful security group and a stateless subnet ACL can reject the same connection for very different reasons, and an engineer who treats them as interchangeable can open far more traffic than intended while trying to restore service.
A useful decision starts with the object being protected. If the policy is about which application tier may reach a workload, a security group is usually the natural expression. If the policy is about what an entire subnet must never exchange with a particular network range, a network ACL may be a useful additional guardrail. The two controls work best when they have distinct jobs.
Security groups are built around workload relationships
Security groups are attached to network interfaces and supported resources. Their rules allow traffic based on protocol, ports, and sources or destinations, including references to other security groups in many common VPC patterns. That makes them well suited to describing application relationships such as “web tier may reach application tier on this port” without hard-coding every changing instance address.
The stateful model is equally important. When traffic is allowed in one direction, return traffic for that established flow is automatically permitted without requiring a mirror-image rule. This reduces rule count and lets the control stay close to the workload relationship rather than the mechanics of ephemeral return ports. The result is usually a policy that is easier to maintain as instances scale or addresses change.
Network ACLs protect subnet boundaries with ordered rules
A network ACL applies to a subnet, not an individual instance. Every subnet must be associated with an ACL, and custom ACLs can explicitly allow or deny traffic. Rules are evaluated in number order, so a lower-numbered match can determine the outcome before later rules are considered. That ordered behavior makes the control powerful but also easy to make brittle.
The stateless model means return traffic must be allowed explicitly. A design that permits inbound application traffic but forgets the client-side ephemeral port range on the return direction can fail even though the inbound rule looks correct. The mechanics behind stateful and stateless access control are therefore operational concerns, not exam trivia.
Everyday application policy usually belongs in security groups
Application access changes as services scale, move, and adopt managed components. Security groups follow that model more naturally because they can be attached to the participating resources and can often reference another security group as the source. A database tier can allow connections from the application tier without maintaining a list of application instance addresses.
This approach also makes intent visible. A rule that allows a database port from a named application security group describes a relationship between tiers. A subnet ACL containing a large set of CIDRs and port ranges describes packets. Packet rules may be necessary, but they are harder to map back to service ownership. For most workload-to-workload policy, the resource relationship is the more durable abstraction.
Network ACLs earn their place when the subnet needs a coarse guardrail
A network ACL can add value when the requirement is broader than any one workload. An organization might block traffic from a known unwanted range, prevent a subnet from initiating connections to a sensitive network segment, or enforce a coarse boundary that remains in place even if a workload owner changes a security group. The ability to write explicit deny rules is useful in that role.
That does not mean every security group rule needs an ACL equivalent. Duplicating the same policy in two control planes increases the chance that one copy is forgotten during a change. The access-control-list model is strongest when it enforces a separate subnet-level invariant, not when it mirrors the resource policy line by line.
Ephemeral ports make stateless controls easy to misread
A TCP connection uses a well-known destination port for the service, but the client typically uses an ephemeral source port. With a stateful security group, the return flow is tracked automatically. With a network ACL, both directions need rules that account for the actual ports involved. This becomes more complicated when clients, load balancers, NAT devices, and operating systems use different ephemeral ranges.
The safest troubleshooting method is to trace one connection as a five-tuple in both directions. Identify the source and destination addresses, source and destination ports, protocol, subnet boundaries, and each ACL that sees the packet. Then compare that path with the security-group policy. Guessing by adding broad port ranges may restore service, but it hides the design error and can create a much larger exposure.
Layered controls should fail differently, not redundantly
Defense in depth is valuable when controls provide independent protection. A security group can express application-tier relationships while a network ACL limits an entire subnet’s reachability to a high-risk network. Host firewalls, IAM, TLS, and application authentication can then protect different parts of the request path. This is more resilient than writing the same source CIDR and port into every layer.
The broader lesson from firewall control design is that placement, state awareness, and policy scope matter as much as the existence of a filtering rule. A control should have a clear owner and a failure mode the operations team understands. If no one can explain why a rule belongs at the subnet layer rather than the workload layer, the design is probably accumulating policy rather than managing risk.
Change control matters because both layers can create wide blast radius
A security group can be reused by many resources, so a single rule change may affect more workloads than the engineer expects. A network ACL affects every resource in associated subnets and can cause immediate connectivity loss when rule ordering changes. Neither control is automatically “safer” simply because one operates at a broader boundary.
Before changing either layer, identify all associations and test the intended connection plus important negative cases. Infrastructure as code helps because the rule set and association are reviewed together. VPC Flow Logs and reachability analysis can provide evidence after deployment. The goal is to make access predictable enough that an operator can distinguish routing failure, ACL rejection, security-group rejection, and application failure without widening every layer.
The decision framework is scope, state, and ownership
Use security groups when the rule describes who or what may talk to a workload. Use network ACLs when a subnet needs a separate coarse restriction or explicit deny that should remain independent of workload configuration. Avoid duplicating every allow rule across both systems. Document the few ACL invariants that matter, and let security groups carry most resource-level application policy.
Within AWS Certified Solutions Architect – Associate preparation, remembering “stateful versus stateless” is only the starting point. The stronger skill is recognizing how scope, return traffic, rule ordering, scale, and ownership change the choice. When the controls have distinct responsibilities, layered security becomes easier to operate; when they contain the same policy twice, the architecture becomes harder to trust.
Security-group references also reduce dependence on IP address management, but they should not be mistaken for identity in the application-security sense. A referenced group says that traffic comes from an interface associated with that group under supported conditions; it does not authenticate the process or user behind the packet. Application authentication and IAM controls still need to protect the action the network connection makes possible.
Network ACL deny rules can be valuable during containment, but emergency use should be rehearsed. A broad deny inserted at a low rule number can cut off monitoring, management, or recovery traffic along with the attacker. Teams should predefine which subnets and network ranges can be isolated safely and which control paths must remain reachable during an incident. A guardrail that blocks the responders can turn containment into a longer outage.
Scale introduces another difference. Security groups are usually maintained around services and can evolve with Auto Scaling or managed targets, while ACLs are associated with subnets that often contain several resources. If unrelated applications share a subnet, a subnet-level change acquires a larger blast radius. This is one reason subnet design and filtering design cannot be reviewed independently: placement determines how precise the ACL can ever be.
During an outage, start with evidence rather than policy expansion. Confirm the route, then inspect the relevant ACLs in both directions, then the source and destination security groups, then the application listener. VPC Flow Logs can narrow the search, but the team still needs to know which layer could reject the flow. A repeatable sequence prevents the common failure mode where engineers open 0.0.0.0/0 temporarily and never fully reconstruct why the original connection failed.
Cross-account and shared-network designs add another ownership question. A central networking team may own subnets and ACLs while application teams own security groups attached to their resources. That split can be healthy when responsibilities are explicit: the platform team protects shared network invariants, and workload teams define service-to-service access. It becomes dangerous when each team assumes the other layer is providing the primary protection.
Managed AWS services can also expose different networking attachment models, so architects should confirm which controls actually apply to each endpoint. Some services use VPC interfaces and security groups; others are reached through service endpoints or public service addresses with IAM and resource policies carrying more of the security burden. A network filter is only useful when traffic actually crosses the boundary where that filter exists.
