Security Groups vs Network ACLs in an AWS VPC
Compare stateful resource-level security groups with stateless subnet-level network ACLs for AWS VPC traffic control.
Open editable diagramArchitecture diagram
Edit this exact diagram
Open on the canvasSecurity groups vs network ACLs architecture diagram comparing stateless subnet rules with stateful resource-level allow rules around EC2. The image links to a fully editable BuildPlane starter.
Overview
Security groups are stateful allow-rule sets attached to resources and network interfaces. Network ACLs are stateless ordered allow and deny rules attached to subnets. Traffic must pass both layers and the route table, so they are normally complementary controls rather than alternatives. Security groups are the primary least-privilege boundary; network ACLs are coarse subnet guardrails and defense in depth.
Components
- Shared decision context: Connections evaluated at the subnet boundary and again at the protected resource.
- Network ACL: Ordered allow and deny rules evaluated separately for inbound and outbound subnet traffic. Every resource in the subnet is subject to the same network ACL.
- Security Group: Stateful allow rules attached to instances, interfaces, load balancers, and databases. Return traffic is automatically allowed for connections admitted by the security group.
Comparison Flow
- Inbound & Outbound Traffic can enter the Network ACL path and continue to Protected Subnet.
- Inbound & Outbound Traffic can instead enter the Security Group path and continue to Protected Resource.
- Choose the path whose operating model and constraints match the workload, then delete the unused branch in the editable diagram.
Customize First
- Document ephemeral return-port rules before tightening a network ACL.
- Prefer security-group references for application-to-database access.
- Use network ACL deny rules only where the operational benefit exceeds the debugging cost.
Side-by-side decision
Network ACL vs Security Group
Use security groups as the primary stateful least-privilege control on resources. Use NACLs for coarse stateless subnet guardrails or explicit deny requirements, with careful return-port rules.
| Decision factor | Network ACL | Security Group |
|---|---|---|
| Scope | Subnet boundary | Resource or network interface |
| State | Stateless | Stateful |
| Rules | Ordered allow and deny | Allow rules only; all rules evaluated |
| Return traffic | Must be explicitly allowed | Automatically allowed for an accepted connection |
| Identity | CIDR, protocol, and port | CIDR or security-group references, protocol, and port |
| Best role | Coarse subnet guardrail and defense in depth | Primary workload least privilege |
Related AWS guides
Understand the decisions behind this diagram
Use these practical explanations to compare services, failure boundaries, and operating tradeoffs before adapting the architecture.
Design rationale
Decisions that shape this architecture
Security-group references follow workloads
Allowing the application security group to reach the database security group expresses the relationship without fixing addresses. New instances and tasks inherit the policy when they receive the group, which is safer than maintaining dynamic private CIDRs manually.
Stateless means return rules are part of every design
A NACL evaluates inbound and outbound traffic independently. If clients connect to a service port, response traffic uses ephemeral ports and must be allowed in the reverse direction. Missing that rule is a classic intermittent connectivity failure.
Explicit deny is powerful and coarse
NACLs can deny an address range before traffic reaches resources, which can be useful during incident containment. The same subnet-level blast radius makes poorly tested denies disruptive, so rules, numbering, and rollback must be controlled.
Before production
Operational checks
Document source, destination, protocol, port, and return path for every allowed flow.
Prefer security-group references over broad private CIDRs when possible.
Test NACL ephemeral-port behavior and rule ordering in both directions.
Use VPC Flow Logs and reachability analysis to investigate denied paths.
Scope and tradeoffs
What this diagram does not solve
Neither replaces routing or application authorization
A permitted packet still needs a valid route, listener, target, and application identity check. Network controls do not decide whether a signed-in user may read an invoice.
Default resources can hide intent
Default security groups and default NACLs may be permissive enough that the architecture looks controlled while policy remains implicit. Create named rules around real trust relationships.
Common questions
Frequently asked questions
Are security groups stateful?
Yes. Response traffic for an accepted connection is automatically allowed even when there is no matching rule in the reverse direction.
Can a security group deny traffic?
Security groups contain allow rules only. Traffic without an allow is denied. Use a network ACL or another inspection control when an explicit deny rule is required.
Do I need both security groups and NACLs?
Every subnet has a NACL and supported resources use security groups. Keep security groups as the precise primary control; customize NACLs when a coarse subnet guardrail provides concrete defense-in-depth value.
Keep exploring
Related AWS architectures
NAT Gateway vs VPC Endpoint
Use VPC endpoints for high-value or high-volume supported services when private routing, endpoint policy, and reduced NAT processing create value. Keep NAT Gateway for package repositories, public APIs, and destinations without endpoint support. Most production VPCs use both: gateway endpoints for S3 and DynamoDB, interface endpoints for selected services, and zonally aligned NAT gateways for the remaining internet egress.
Explore the architecture
AWS Transit Gateway vs VPC Peering
Choose VPC peering for a small, stable number of direct VPC relationships where pairwise routes remain easy to understand. Choose Transit Gateway when many VPCs, accounts, hybrid networks, segmentation domains, or centralized inspection paths need one governed routing hub. Count future connections and traffic paths before cost, because a full peering mesh grows quadratically and becomes the expensive option operationally even when service charges are lower.
Explore the architecture
Public and Private Subnets in an AWS VPC
This VPC pattern makes exposure decisions explicit and auditable. The load balancer and NAT gateway are the only resources in the public path; application compute accepts traffic solely from the load balancer security group; the database accepts connections solely from the application security group and has no route to or from the internet. Because every layer is enforced by a route table and a security group reference rather than by convention, you can answer "what is reachable from the internet?" by reading the diagram. Everything else in a production build, such as a second Availability Zone, VPC endpoints, and flow logs, attaches to this skeleton without changing it.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.