Layering Both for Defense in Depth

Defense in depth means stacking independent controls so a failure or gap in one does not expose the workload. In a VPC, security groups and network ACLs are two such layers, joined by route tables, WAF, and Network Firewall to form overlapping barriers around your resources.

Security groups give fine, per-resource, stateful control with allow-only rules. NACLs give coarse, subnet-wide, stateless control with both allow and deny. Using them together lets you set a broad subnet baseline while tuning each resource precisely.

For inbound traffic to reach an instance, both the NACL and the security group must permit it. A deny at either layer drops the packet. This AND logic means a restrictive NACL acts as a backstop even if an overly permissive security group is created by mistake.

Use NACLs to enforce subnet-level guardrails that no resource owner can override, such as denying a known malicious CIDR or blocking traffic between tiers that should never communicate. Because NACLs are coarse, keep these rules broad and stable.

Use security groups for the day-to-day, least-privilege rules: open port 443 on the web tier, allow the app tier to reach the database, and reference groups instead of IPs. This is where most of your network policy lives because it is precise and stateful.

A classic layered design places public, private-app, and private-data subnets in separate tiers. NACLs prevent the data subnet from talking directly to the internet, while security groups chain web to app to database. An attacker breaching one tier still faces both controls at the next.

Layering shrinks the blast radius of a compromise. If an app server is breached, tight security groups stop it from scanning the data tier, and NACLs stop subnet-wide lateral movement. The attacker is boxed in rather than free to roam the VPC.

Confirm your layered rules actually behave by analyzing VPC Flow Logs. Reject entries reveal blocked attempts; unexpected accepts reveal gaps. Pair Flow Logs with Athena queries to audit whether traffic between tiers matches your intended design.

Because NACLs are stateless and limited to 20 rules per direction by default, do not try to express granular policy in them. Over-loading NACLs creates ephemeral-port headaches and rule-number sprawl. Keep them simple and let security groups carry the detail.

Security groups and NACLs filter on IP, port, and protocol only. To inspect HTTP content, block SQL injection, or filter by domain, you add higher layers: WAF for web requests and AWS Network Firewall for deep packet inspection, both covered later in this category.

A mature VPC layers route tables, NACLs, security groups, Network Firewall, and WAF, each catching what the others miss. The SCS-C02 exam rewards choosing the right control at the right layer and combining them rather than relying on any single one.

Reason about layered controls.

Defense in depth stacks NACLs and security groups so a gap in one is caught by the other. Both must allow inbound for traffic to pass, making a restrictive NACL a backstop. Use NACLs for coarse subnet guardrails and security groups for fine per-resource least privilege. Verify with Flow Logs, keep NACLs simple, and add WAF or Network Firewall for content-aware filtering.