AWS Foundations
Security Groups vs NACLs
Compare AWS security groups and network ACLs as stateful resource-level firewalls and stateless subnet-level guardrails.
After this, you will understand
This comparison turns VPC firewall questions into a simple placement decision: resource-level stateful control or subnet-level stateless guardrail.
Security groups protect resources and are stateful; NACLs protect subnets and are stateless.
Learners put every network rule into NACLs and then get confused by return traffic, rule order, and ephemeral ports.
Use security groups as the primary access control and NACLs as coarse defense-in-depth for subnet-level allow or deny rules.
Think before readingWhy does return traffic usually need an explicit NACL rule but not an explicit security group rule?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Security groups
- Network ACLs
- Stateful filtering
- Stateless filtering
- Instance-level and subnet-level controls
- Allow rules and deny rules
- Rule order
- Ephemeral ports
- Defense in depth
- Exam traps around return traffic
1. Plain-English Definition
A security group is a stateful virtual firewall attached to AWS resources such as EC2 instances, load balancers, and network interfaces.
A network ACL, or NACL, is a stateless set of subnet-level rules that controls traffic entering and leaving a subnet.
The short comparison is:
security group = resource-level, stateful, allow rules
NACL = subnet-level, stateless, allow and deny rules, ordered evaluation
Security groups are usually the primary control. NACLs are usually coarse guardrails or defense-in-depth controls. You can build many VPC architectures with security groups alone, but NACLs become useful when you need subnet-level deny rules or broad traffic boundaries.
The most important beginner distinction is state. Security groups remember allowed flows. NACLs do not.
2. Why This Matters In AWS
Many network failures in AWS look mysterious until you know which layer is blocking traffic.
An EC2 instance can have a route to the internet, a public IP address, and a running web server, but still reject HTTP because the security group does not allow inbound port 80.
A subnet can have a route and a permissive security group, but a NACL can still block inbound traffic or return traffic. Because NACLs are stateless, you must think about both directions.
For SAA-C03, security group versus NACL questions are common because the words are similar. Both control traffic. Both live in VPC design. Both can affect EC2 connectivity. But the correct answer depends on scope and behavior:
- protect one app tier: security group
- reference another security group as source: security group
- block a specific IP range at subnet level: NACL
- allow return traffic automatically: security group
- ordered allow and deny rules: NACL
3. The Beginner Mental Model
Think of security groups as guards assigned to individual rooms.
Each room can have its own guard rules:
web instance security group:
allow HTTP from load balancer security group
allow outbound to app dependencies
Think of NACLs as checkpoints at hallway entrances.
The checkpoint applies to every room in that subnet:
subnet NACL:
allow inbound HTTPS from known ranges
deny inbound from blocked CIDR
allow outbound ephemeral response ports
The room guard remembers conversations. If you allow someone to ask a question, the response can leave. The hallway checkpoint does not remember. It checks every inbound and outbound movement separately.
This is why security groups are easier for most application rules. NACLs are powerful, but easier to misconfigure.
4. What That Mental Model Misses
Security groups and NACLs are not replacements for each other in every situation.
Security groups cannot create explicit deny rules. If you need to deny a known CIDR while allowing a broader range, a NACL may fit better, or you may need another network security service depending on depth.
NACLs cannot reference security groups. They use CIDR ranges, protocols, and ports. Security groups can reference other security groups, which is very useful for tiered application design.
NACL rule order matters. Rules are evaluated by rule number from lowest to highest until a match is found. Security groups evaluate all rules before deciding.
Ephemeral ports matter for NACLs. When a client connects to a server, response traffic often uses ephemeral ports on the client side. If outbound or inbound NACL rules do not allow the response path, the connection can fail even though the initial request rule looked correct.
AWS also has other network security services such as AWS Network Firewall, AWS WAF, Shield, and route-level controls. Security groups and NACLs are VPC primitives, not the entire security architecture.
5. AWS Mechanics
Security groups attach to elastic network interfaces and supported resources. They are stateful. Inbound rules allow traffic from sources. Outbound rules allow traffic to destinations. By default, custom security groups deny inbound traffic and allow outbound traffic unless changed.
Security group rules can reference CIDR ranges, prefix lists, or other security groups. Referencing another security group is common for app tiers:
app security group allows inbound from load balancer security group
database security group allows inbound from app security group
NACLs associate with subnets. A subnet uses one NACL at a time, and a NACL can be associated with multiple subnets. NACLs have inbound and outbound numbered rules. They support allow and deny. They are stateless, so return traffic must be explicitly allowed.
The default NACL allows all inbound and outbound traffic. A custom NACL denies all traffic until rules are added.
Both security groups and NACLs are free to use, but bad rules can create expensive downtime.
6. Architecture Examples
A web application uses an Application Load Balancer, EC2 app instances, and RDS.
Use security groups for the main application flow:
- ALB security group allows inbound HTTPS from the internet
- app security group allows inbound app port from the ALB security group
- database security group allows inbound database port from the app security group
This is clean because each tier trusts the previous tier by security group reference.
Use NACLs only if you need subnet-level guardrails, such as blocking a known malicious CIDR across an entire subnet or enforcing coarse inbound/outbound boundaries.
For a public subnet with a web tier, a restrictive NACL must allow inbound web traffic and outbound ephemeral response traffic. For private app subnets, it must allow the required app, database, and response paths. This is why NACL designs can become tedious.
7. SAA-C03 Exam Signals
"Stateful firewall" points to security groups.
"Stateless subnet-level filtering" points to NACLs.
"Allow only traffic from the load balancer security group" points to security groups.
"Deny traffic from a specific IP range at subnet level" points to NACLs.
"Return traffic is automatically allowed" points to security groups.
"Rules are evaluated in order" points to NACLs.
"Primary mechanism for controlling access to VPC resources" usually points to security groups.
8. Common Traps
Do not forget return traffic for NACLs.
Do not try to add deny rules to security groups. Security groups only have allow rules.
Do not use NACLs when a security group reference would express the application relationship more clearly.
Do not assume a route table issue is a security group issue. Trace route, NACL, security group, and instance listener separately.
Do not open SSH or RDP to 0.0.0.0/0 unless the scenario explicitly accepts that risk. It usually does not.
Do not build detailed per-instance policy in NACLs. They apply to subnets, not individual instances.
9. What To Learn Next
Next, study Application Load Balancer vs Network Load Balancer vs Gateway Load Balancer. Load balancer placement, listeners, health checks, and security groups appear together in many VPC scenarios.
Then revisit Public vs Private Subnets until you can trace a full request path without guessing.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.