ACLs vs Security Groups in AWS

AWS provides two layers of network security at the VPC level:

Feature	Security Groups	Network ACLs
Scope	Instance level	Subnet level
Stateful / Stateless	Stateful — if you allow inbound traffic, the response is automatically allowed outbound	Stateless — you must define both inbound and outbound rules
Use case	Fine-grained access control for instances and services	Broad subnet-level filtering
Complexity	Easier to manage for most cases	More complex to manage
Best practice	Primary access control for AWS workloads	Optional for extra protection or compliance requirements

---

When to use Security Groups only

• Most AWS workloads should use security groups because they are stateful and simpler.
• They work well for multi-tier designs when each tier has its own security group referencing the previous tier’s SG.
• This follows AWS best practice for least privilege.

Example:

• Web tier SG allows HTTP/HTTPS from the internet.
• App tier SG allows inbound traffic only from web tier SG.
• Database SG allows inbound traffic only from app tier SG.

---

When to add Network ACLs

You add NACLs when:

1. You want extra protection at the subnet level (defense in depth).
2. You need stateless filtering (e.g., block certain IP ranges regardless of instance-level rules).
3. You have compliance requirements that demand NACL use.
4. You want to filter traffic across multiple resources without touching each instance’s security group.

Example:

• Blocking a malicious IP range globally across your VPC subnets using a NACL.

---

💡 Key takeaway:
Security groups are the main access control mechanism. Use NACLs only for extra broad filtering or specific compliance needs. For most applications following AWS Well-Architected principles (like multi-tier web apps), security groups with tier separation are enough — which is why designs like C/E/F are preferred over A.