2.1.2.1. VPC Security: Security Groups and Network ACLs
2.1.2.1. VPC Security: Security Groups and Network ACLs
💡 First Principle: Security Groups (SGs) and Network ACLs (NACLs) are virtual firewalls controlling VPC traffic. SGs protect instances; NACLs secure subnets, managing flow.
The Security Groups (SGs) and Network Access Control Lists (NACLs) are virtual firewalls controlling VPC traffic. SGs protect instances; NACLs secure subnets, managing flow.
Key Differences in VPC Security with SGs and NACLs:
- "Security Groups (SGs)":
- "Instance-level": Applies to individual EC2 instances or Elastic Network Interfaces (ENIs).
- "Stateful": If you allow inbound traffic, return outbound traffic is automatically allowed.
- "Allow-only": You define only allow rules. Implicitly denies everything else.
- "Network Access Control Lists (NACLs)":
- "Subnet-level": Applies to all EC2 instances within a subnet.
- "Stateless": Inbound and outbound rules are evaluated separately.
- "Allow and Deny": You can explicitly allow or deny traffic. Rules are processed in order (lowest numbered rule first).
Scenario: An SG allows only web traffic (ports 80, 443) to an EC2 instance, while a NACL blocks all inbound traffic to its associated subnet, creating layered defense.
Visual: Security Groups vs. Network ACLs
⚠️ Common Pitfall: Forgetting that NACLs are stateless. If you allow inbound traffic on a NACL, you must explicitly allow the corresponding outbound return traffic as well, unlike Security Groups.
Key Trade-Offs:
- Fine-grained (SG) vs. Broad (NACL): Security Groups are for specific instance-level control. NACLs are for broader subnet-level control. Using both provides defense-in-depth.
Reflection Question: How does combining Security Groups (instance-level, stateful) and Network ACLs (subnet-level, stateless) enhance VPC security by providing a layered defense-in-depth approach?
⚠️ Exam Trap: The Security Group vs. NACL distinction is one of the most frequently tested concepts. Memorize this table:
| Feature | Security Group | Network ACL |
|---|---|---|
| Scope | Instance (ENI) level | Subnet level |
| State | Stateful — return traffic auto-allowed | Stateless — must explicitly allow return traffic |
| Rules | Allow rules only | Allow AND deny rules |
| Evaluation | All rules evaluated together | Rules evaluated in number order (first match wins) |
| Default | Denies all inbound, allows all outbound | Allows all inbound and outbound |
Key Decision Criteria:
- "Block a specific IP" → NACL (only NACLs can explicitly deny)
- "Allow traffic from another security group" → Security Group (supports SG-to-SG references)
- "Ephemeral ports" → NACL concern (stateless, must allow return traffic on ports 1024-65535)
Seeing and inspecting VPC traffic:
- VPC Flow Logs record metadata about IP traffic to and from network interfaces — addresses, ports, bytes, and whether security groups and NACLs ACCEPTed or REJECTed it — not packet contents. Publish them to CloudWatch Logs, Amazon S3 or Amazon Data Firehose; logs in S3 are typically queried ad hoc with Amazon Athena (serverless SQL, nothing to provision). CloudTrail is different: it records API calls, not network flows.
- Centralized inspection: In a hub-and-spoke Transit Gateway network, route inter-VPC and internet-bound traffic through a dedicated inspection VPC. Run third-party firewall appliances there behind a Gateway Load Balancer, which deploys, scales and load-balances virtual appliances transparently; choose AWS Network Firewall instead when a managed AWS firewall (rather than your own appliances) is acceptable.
