2.3.1.1. Inter-VPC Connectivity (VPC Peering, Transit Gateway)

💡 First Principle: Enabling secure and scalable communication between distinct "VPCs" is essential for building modular, multi-account architectures without exposing traffic to the public internet.

Scenario: A large enterprise has over 100 VPCs spread across multiple business units and environments (Dev, Test, Prod). They need to connect these "VPCs" in a hub-and-spoke model, allowing common services in the hub "VPC" to be accessed by all spokes, and enabling communication between spoke "VPCs" via the hub. The solution must be scalable and minimize network complexity.

As organizations grow, they often deploy workloads into multiple "VPCs" for isolation, security, or organizational reasons. Efficient and secure inter-"VPC" connectivity becomes crucial.

• "VPC Peering": A networking connection between two "VPCs" that enables you to route traffic between them privately. Connects two "VPCs" directly, allowing instances in either "VPC" to communicate as if they were in the same network.
  • Practical Relevance: Simple to configure for a small number of "VPCs" (e.g., 2-3) or for a hub-and-spoke model with a single hub and a few spokes. Not transitive ("VPC A" peered to B, and B to C, does NOT mean A can talk to C). No overlapping "CIDR blocks" allowed.
• "AWS Transit Gateway (TGW)": A network transit hub that connects your "VPCs" and on-premises networks to a single gateway.
  • Practical Relevance: Scalable solution for connecting hundreds or thousands of "VPCs" and on-premises networks. Simplifies network architecture by eliminating complex peering mesh. Allows transitive routing ("VPC A" to "TGW" to "VPC C"). Supports overlapping "CIDR blocks" with NAT over "TGW" attachments. Ideal for enterprise-scale networking.

Visual: VPC Peering vs. Transit Gateway

Loading diagram...

⚠️ Common Pitfall: Using "VPC Peering" for a large number of "VPCs". This creates a complex and unmanageable "peering mesh" that is difficult to troubleshoot and scale. "Transit Gateway" is the purpose-built solution for hub-and-spoke at scale.

Key Trade-Offs:

• Simplicity (Peering) vs. Scalability (Transit Gateway): "VPC Peering" is simple for connecting two or three "VPCs". "Transit Gateway" has a slightly higher initial setup cost and complexity but is vastly more scalable and manageable for enterprise-wide networking.

Reflection Question: Why would "AWS Transit Gateway" be the most suitable solution for this enterprise network with over 100 VPCs in a hub-and-spoke model, and why would "VPC Peering" be an unmanageable choice for this scale, particularly regarding transitive routing and network complexity?