VPC Peering vs. Transit for a Growing Network
You have 4 VPCs in one region: prod (10.0.0.0/16), staging (10.1.0.0/16), shared-services (10.2.0.0/16), and a new analytics VPC (10.3.0.0/16). Today prod and staging each peer with shared-services. Analytics needs to reach shared-services and prod, but not staging. Two more VPCs are planned next quarter. The network team is debating full-mesh peering versus a transit gateway (Cloud Enterprise Network / Transit Router).
1. Compare full-mesh peering with a transit gateway for this topology, including the CIDR constraint.
Read the worked answer
Full-mesh peering: every VPC peers with every other. For 6 VPCs that's 15 peering connections to manage, each with route-table entries on both sides. It works but scales poorly and peering is non-transitive - analytics peering with shared-services does not give it prod access; you need a direct peer.
Transit gateway / CEN: attach each VPC once, then control reachability with route tables. This gives you the "analytics reaches prod and shared-services but not staging" requirement cleanly via per-attachment route tables, and adding VPC 5 and 6 is two attachments rather than five new peers.
CIDR constraint: all four VPCs are in 10.0.0.0/16 with different second octets, so no overlap - good. But the plan must reserve space; if a future VPC uses 10.0.0.0/16 again you get an overlap that peering and transit both reject. Document an IP allocation plan now.
2. Which would you choose, and what operational risks come with it?
Read the worked answer
Choose the transit gateway/CEN. It matches the selective-reachability requirement and the growth path, and centralizes routing.
Risks to manage:
- Single point of failure / blast radius: a misconfigured route table can cut off many VPCs at once. Use change control and stage route changes.
- Cost model shift: you pay per attachment and per GB processed; model the analytics data volume before committing.
- Asymmetric routing if some VPCs keep direct peers alongside transit attachments - standardize on transit for east-west traffic.
- Bandwidth limits per attachment; verify analytics throughput needs.
Keep the CIDR allocation plan and a rollback path (retain peering configs until transit is validated).