6.1.2. Security Groups and Network ACLs
š” First Principle: Security groups and NACLs both filter traffic, but they operate at different levels and with different evaluation models ā and confusing them causes misconfigured architectures. Security groups are stateful (return traffic is automatically allowed); NACLs are stateless (return traffic must be explicitly allowed). Understanding this distinction is non-negotiable for the exam.
Security Groups ā Stateful Firewall at the Instance Level:
| Property | Detail |
|---|---|
| Attached to | ENI (network interface) ā EC2 instances, RDS, Lambda in VPC, etc. |
| Default behavior | All inbound denied; all outbound allowed |
| Rule evaluation | All rules evaluated; most permissive wins (no explicit deny) |
| Stateful | If inbound is allowed, response traffic is automatically allowed outbound |
| Reference other SGs | Yes ā allow traffic from instances in another security group |
Security group chaining (referencing other groups) is a powerful pattern for tier-based access control:
Internet ā ALB SG (port 443 allowed from 0.0.0.0/0)
ā App SG (port 8080 allowed from ALB SG only)
ā DB SG (port 5432 allowed from App SG only)
No instance's security group allows direct internet access to the database ā the chain enforces the access model.
Network ACLs ā Stateless Firewall at the Subnet Level:
| Property | Detail |
|---|---|
| Attached to | Subnet |
| Default behavior | Default NACL allows all traffic; custom NACLs deny all by default |
| Rule evaluation | Rules evaluated in number order (lowest first); first match wins |
| Stateless | Return traffic must be explicitly allowed (ephemeral ports!) |
| Explicit deny | Yes ā unlike security groups, NACLs can explicitly deny |
Ephemeral Ports Problem: When a client connects to a server, the server responds on an ephemeral port (typically 1024ā65535) chosen by the client's OS. If your NACL allows inbound TCP 443 but doesn't allow outbound TCP 1024ā65535, the response traffic is blocked.
NACL Inbound + Outbound rules required for web traffic:
| Direction | Port | Protocol | Source/Dest | Purpose |
|---|---|---|---|---|
| Inbound | 443 | TCP | 0.0.0.0/0 | HTTPS requests in |
| Outbound | 1024ā65535 | TCP | 0.0.0.0/0 | Ephemeral port responses out |
| Inbound | 1024ā65535 | TCP | 0.0.0.0/0 | Ephemeral ports for outbound connections |
| Outbound | 443 | TCP | 0.0.0.0/0 | HTTPS requests to internet |
VPC Flow Logs: Capture metadata about network traffic (source/dest IP, port, protocol, action: ACCEPT/REJECT, bytes, packets) at the VPC, subnet, or ENI level. Flow logs go to CloudWatch Logs or S3. They don't capture packet contents ā just the flow record. Use flow logs to:
- Identify rejected traffic (diagnose security group / NACL blocks)
- Monitor traffic patterns
- Detect port scans or unusual connection volumes
ā ļø Exam Trap: Security groups have no explicit deny ā you can only allow or not-allow. NACLs have explicit deny rules. If you need to block a specific IP address from reaching your VPC (e.g., a known malicious IP), you cannot do this with a security group alone ā you need a NACL deny rule or AWS WAF. Security groups can't say "deny traffic from this specific IP."
Reflection Question: An EC2 instance's security group allows inbound port 443 from all sources, and the subnet NACL allows inbound 443 from all sources. HTTPS requests are still being rejected. What is the most likely cause, and which AWS tool would you use to diagnose it?
