c2.15 Segment networks with VPCs
Once an adversary has initial access, their ability to move laterally depends on network reachability. Separate workloads into VPCs and subnets, expose only what truly needs public access, and keep databases and internal tiers private to shrink the blast radius.
Implementation guidance
Public only where required
Place only resources that genuinely need inbound public access (such as a public web server) in public subnets, and keep everything else — databases, application tiers — in private subnets. When a private instance needs outbound internet (for updates), route it through a NAT gateway rather than giving it a public IP.
Reachability drives blast radius
After initial access, an adversary's lateral movement is bounded by what the network lets them reach. Tier access with security groups — for example, allow the database only from the web tier's security group, so a new autoscaled instance inherits the right access automatically. Isolating workloads across multiple VPCs and accounts contains an attack to a single VPC/account.
Connect deliberately
Connect a VPC to on-premises (VPN, ideally over AWS Direct Connect) only when that VPC actually needs on-premises access — do not connect everything "for the future". Use VPC peering when needed, but keep it minimal for the same reason.
Related
Pair network tiers with least-privilege security groups and a multi-account structure.
How it fits together
How to validate
- How are workloads organized — multiple accounts, multiple VPCs?
- Are critical workloads separated from the rest of the organization?
- Are public subnets limited to resources that truly need inbound public access?
Threats addressed
- If workloads are not separated into VPCs (and accounts), the blast radius after a compromise is far larger because the adversary can reach more of the network.
AWS services
Amazon VPC 
AWS Firewall Manager