A Virtual Private Cloud (VPC) is the fundamental isolation layer in cloud computing, mimicking a traditional data center network but with software-defined flexibility. For senior engineers, understanding VPCs goes beyond creating subnets; it involves designing for high availability, security boundaries, and hybrid connectivity.
1. CIDR Blocks and Addressing
VPC creation starts with assigning a generic CIDR (Classless Inter-Domain Routing) block. A common pattern is to use RFC 1918 private address space (e.g., 10.0.0.0/16). This provides 65,536 IP addresses. When designing for multiple environments (Dev, Stage, Prod) or multi-region setups, non-overlapping CIDRs are critical to enable future peering.
2. Subnetting Strategy: Public vs. Private vs. Isolated
Effective segmentation usually follows a multi-tier architecture:
- Public Subnets: Have a direct route to an Internet Gateway (IGW). Used for Load Balancers, Bastion hosts, or NAT Gateways.
- Private Subnets: Have no direct route to the IGW but can access the internet via a NAT Gateway located in a public subnet. Used for application servers, container clusters.
- Isolated Subnets: No internet access (inbound or outbound). Strictly for data stores (RDS, ElastiCache).
3. Routing and Gateways
Route Tables are the logic engines of the VPC. Subnets are associated with route tables.
- Internet Gateway (IGW): Performs 1:1 NAT for instances with public IPs.
- NAT Gateway: Performs N:1 PAT (Port Address Translation) allowing private instances to initiate outbound connections (e.g., `yum update`) without accepting inbound connections.
4. Scaling Connectivity: Peering vs. Transit Gateway
As organizations grow, they use multiple VPCs.
- VPC Peering: Non-transitive, 1:1 connection. Good for simple setups. Mesh complexity grows quadratically (N*(N-1)/2).
- Transit Gateway: A hub-and-spoke model. Transitive routing. Simplifies management for large organizations with hundreds of VPCs and VPN connections.