Introduction: Modern cloud-native companies (e.g. Airbnb, Netflix) operate complex virtual networks to support global, large-scale services. Achieving scalable, secure, and highly available networking in the cloud requires careful VPC architecture design. This report compares AWS and GCP best practices for Virtual Private Cloud (VPC) networks at enterprise scale. We focus on VPC structure, subnet segmentation, multi-account/project design, shared VPC strategies, cross-region connectivity, service isolation, and secure access patterns, with high-level ASCII diagrams illustrating key topologies.
AWS VPC Architectures at Scale
AWS’s Virtual Private Cloud provides an isolated networking environment per AWS account and region. Large organizations like Netflix and Airbnb leverage multiple AWS accounts and VPCs to achieve isolation, scalability, and resilience. This section covers standard AWS VPC layouts, multi-VPC/multi-account designs, transit connectivity, service isolation mechanisms, and security patterns in large AWS environments.
Standard AWS VPC Layout and Subnet Segmentation
A standard AWS VPC typically spans an entire AWS region (one VPC per region per account), divided into subnets (per Availability Zone) for different tiers (public, private, database, etc.). Subnets allow segmenting resources and controlling access via route tables and network ACLs. A common pattern is a 3-tier network: public subnets for front-end load balancers or bastions, private subnets for application servers, and isolated subnets for databases. Internet Gateways (IGW) attach to the VPC to allow outbound internet access from public subnets, while NAT Gateways in public subnets enable instances in private subnets to reach out to the internet securely (for updates, external API calls) without exposing those instances to inbound traffic. Security Groups (stateful instance-level firewalls) and Network ACLs (stateless subnet-level ACLs) enforce inbound/outbound rules for defense in depth. The ASCII diagram below shows a prototypical VPC layout in one region with multi-AZ subnets and basic routing:
AWS Region (e.g. us-east-1) └─ VPC 10.0.0.0/16 ├─ Public Subnet 10.0.1.0/24 (AZ-a) - IGW route | • EC2 instances (e.g. bastion, ALB) with public IPs ├─ Private Subnet 10.0.2.0/24 (AZ-a) - NAT Gateway route | • EC2 App servers (no public IP; egress via NAT) ├─ DB Subnet 10.0.3.0/24 (AZ-a) - no external route | • RDS Database (isolated, accessed only from Private subnet) └─ (... repeat subnets in AZ-b for HA ...)
In the above layout, the public subnet has a route to an Internet Gateway (allowing inbound/outbound internet for resources like load balancers or bastions). The private subnet has no direct internet route; instead, its default route points to a NAT Gateway in a public subnet for secure egress. The DB subnet has only local routes (no IGW or NAT), fully isolated except for internal access from the app tier. This arrangement supports multi-AZ high availability (each tier spans subnets in multiple AZs). It also aids security: external traffic only reaches the public tier (via the ALB or bastion), and internal tiers use private addressing and security groups for controlled communication.
Subnet design in AWS VPCs should consider IP address management. At scale, companies must carefully plan VPC CIDR ranges to avoid overlaps across many VPCs and with on-prem networks. AWS recommends a hierarchical IP addressing scheme (e.g. partition by environment, region, or team) and use of AWS VPC IP Address Manager (IPAM) to centrally manage IP allocations. Planning subnets with sufficient size for future growth is important, as resizing requires recreation. Many enterprises use /16 VPCs with /24 subnets per AZ for each tier as a starting point, adjusting based on projected instance counts. Consistent tagging/naming conventions (e.g. including environment, app, AZ in subnet names) help manage complex setups.
Evolving to Multiple VPCs and Accounts
As organizations grow, a single VPC often becomes insufficient for isolation and scaling needs. Companies evolve from one VPC to multiple VPCs across multiple AWS accounts for reasons such as separating production vs. development environments, isolating regulated data (PCI, HIPAA) from non-regulated, limiting blast radius, and delegating resource ownership to different teams. Airbnb’s AWS architecture, for example, shifted “from one to many” VPCs – using separate AWS accounts and VPCs for microservices, environments, and regions, connected via peering and transit gateways. This ensures that each app or environment has network isolation yet can communicate through controlled links.
... continue reading