1 min lesson
Security groups vs. NACLs
Connect "Security groups attach to an interface and are stateful" to the decision you would make.
Step 1 of 3
Security groups vs. NACLsstateful vs. stateless
Both filter traffic, but they live at different layers and behave differently. Security groups attach to an interface and are stateful: allow a connection out and the return packets come back automatically. NACLs sit at the subnet boundary and are stateless: you must write both directions, including ephemeral return ports or the reply is silently dropped.
Learn more
Advanced table
Reach for security groups by default
- Property
- Attaches to
- Security group
- ENI / instance / pod
- NACL
- Subnet
- Property
- State
- Security group
- Stateful (return traffic auto-allowed)
- NACL
- Stateless (must allow both directions)
- Property
- Rules
- Security group
- Allow only
- NACL
- Allow and explicit deny
- Property
- Evaluation
- Security group
- All rules, most-permissive wins
- NACL
- Numbered, first match wins
- Property
- Default reach for
- Security group
- Day-to-day app access control
- NACL
- Coarse subnet guardrail / blocking a bad CIDR
| Property | Security group | NACL |
|---|---|---|
| Attaches to | ENI / instance / pod | Subnet |
| State | Stateful (return traffic auto-allowed) | Stateless (must allow both directions) |
| Rules | Allow only | Allow and explicit deny |
| Evaluation | All rules, most-permissive wins | Numbered, first match wins |
| Default reach for | Day-to-day app access control | Coarse subnet guardrail / blocking a bad CIDR |
Reach for security groups by default; use NACLs as a blunt subnet-wide backstop.
Security groups can reference other security groups as their source, not just IP ranges. "Allow the EKS node SG to reach the database SG on 5432" stays correct as instances churn, where a hand-maintained IP allowlist rots the moment autoscaling replaces a node.