A Virtual Private Cloud (VPC) is the foundational network isolation boundary in AWS (equivalent: Azure VNet, GCP VPC). Within a VPC, subnets are carved from the CIDR block and scoped to a single AZ; route tables control traffic flow; and Internet Gateways, NAT Gateways, and Transit Gateways control external connectivity. Proper network design — including IP address planning — is difficult to change post-deployment and directly affects security, latency, and egress costs.

Key Points

  • VPC CIDR sizing: use /16 (65,536 IPs) for production VPCs to allow room for subnet growth; never use overlapping CIDRs across VPCs that need to peer.
  • Public subnets have a route to an Internet Gateway (0.0.0.0/0 → IGW); private subnets route internet traffic via NAT Gateway (charged per GB: ~$0.045/GB in us-east-1).
  • NAT Gateway vs NAT Instance: NAT GW is managed, scales automatically, costs ~$0.045/hour + data; NAT Instance is self-managed, cheaper, but single point of failure.
  • VPC Peering is non-transitive: if VPC-A peers with VPC-B and VPC-C, B cannot reach C via A — use AWS Transit Gateway for hub-and-spoke connectivity across dozens of VPCs.
  • AWS Direct Connect provides dedicated 1–100 Gbps private connections from on-premises to AWS, bypassing the public internet — reduces latency variability and egress costs vs VPN.
  • Security Groups are stateful (return traffic automatically allowed); NACLs are stateless (require explicit inbound and outbound rules) and operate at subnet boundary.
  • VPC Endpoints (Gateway for S3/DynamoDB, Interface for others) allow private connectivity to AWS services without NAT Gateway, reducing latency and egress costs.
  • AWS PrivateLink exposes services across VPCs via private IP without VPC peering — used to share services between teams or consume SaaS APIs privately.

Real-World Example

Capital One uses AWS Transit Gateway to interconnect 100+ VPCs across accounts, with Direct Connect for hybrid connectivity to on-premises data centers for regulatory workloads.