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

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"). It does not by itself route between attachments whose CIDR blocks overlap (connecting overlapping networks needs private NAT gateways that translate to non-overlapping ranges, or PrivateLink instead). Ideal for enterprise-scale networking.
  • TGW route tables: Each attachment is associated with one TGW route table, which decides where its traffic goes, and can propagate its routes into others. Several route tables segment the network: an attachment can reach only the destinations its associated table has routes for, so association and propagation decide which VPCs can talk (for example, a default route to a shared egress or inspection VPC without routes to other spokes). A single flat table lets every attachment reach every other. For centralized inspection, route traffic through an inspection VPC and enable appliance mode on that VPC's attachment so both directions of a flow stay on the same AZ's appliance (symmetric routing).
• "AWS PrivateLink" (VPC endpoint services): Exposes one service behind an "NLB" (or "GWLB") to consumer VPCs through interface endpoints. Traffic stays on the AWS network, only that service is reachable (not the rest of the provider VPC), the consumer initiates the connections (one direction), and it works across accounts and with overlapping CIDR blocks. Use it for SaaS-style exposure or a single shared service; use Transit Gateway or peering when VPCs need broad routed connectivity, which requires non-overlapping CIDRs.
• Sharing across accounts with "AWS Resource Access Manager (RAM)": RAM shares resources owned by one account, such as Transit Gateways, VPC subnets and Route 53 Resolver rules, with specific accounts or a whole AWS Organization, without cross-account IAM roles or peering. A shared Transit Gateway lets members attach their own VPCs; VPC sharing lets participant accounts launch resources into the owner's shared subnets (the owner controls the VPC and routing, participants manage their own resources and security groups). Participants can write security group rules that reference another participant's or the owner's security group (as account-id/sg-id), because all of them live in the same VPC.
• Tenant isolation models (SaaS): Silo (a separate account or stack per tenant) gives the strongest isolation but the highest cost and operational load; pool (a shared stack with tenant ID enforced in the application and in IAM/resource policies) is the cheapest but offers only logical isolation; bridge/hybrid mixes them. Tiering lets you choose the model per tenant class rather than once for the whole platform.

Visual: VPC Peering vs. Transit Gateway

⚠️ 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?