Why We Switched from Full-Mesh VPC Peering to AWS Transit Gateway: A Production Breakdown

The Growth Bottleneck of VPC Peering

When companies begin their cloud journey on AWS, VPC Peering is usually the default choice for connecting two Virtual Private Clouds. It is simple, requires no hourly gateway fee, and delivers line-rate performance within the same AWS Region.

However, as infrastructure matures into multi-account and multi-tier architectures (e.g., separate VPCs for Ingress DMZ, App Compute, Core Database, and Shared Tooling), VPC Peering quickly encounters fundamental architectural limitations.

          FULL MESH PEERING (Complex: N*(N-1)/2 links)
             ┌─────────┐
         ┌───┤  VPC A  ├───┐
         │   └────┬────┘   │
         │        │        │
     ┌───┴─────┐  │   ┌────┴────┐
     │  VPC B  ├──┼───┤  VPC C  │
     └───┬─────┘  │   └────┬────┘
         │        │        │
         └───┐ ┌──┴──┐ ┌───┘
             └─┤VPC D├─┘
               └─────┘

For $N$ VPCs, a full mesh requires $\frac{N(N-1)}{2}$ peering links:

• 4 VPCs = 6 Peering Connections
• 10 VPCs = 45 Peering Connections
• 20 VPCs = 190 Peering Connections

Worse, VPC Peering does NOT support transitive routing. If VPC A is peered with VPC B, and VPC B is peered with VPC C, traffic from VPC A cannot transit through VPC B to reach VPC C.

---

The Transit Gateway (Hub-and-Spoke) Revolution

AWS Transit Gateway solves this by acting as a high-performance regional virtual cloud router. Each VPC connects to the Transit Gateway using a single VPC Attachment.

                TRANSIT GATEWAY HUB (Scalable & Deterministic)
                       ┌─────────────────────────┐
                       │  VPC A (Public / Ingress│
                       └────────────┬────────────┘
                                    │
                                    ▼
                 ═════════════════════════════════════
                     AWS TRANSIT GATEWAY (TGW Hub)
                 ═════════════════════════════════════
                        ▲                 ▲
                        │                 │
             ┌──────────┴──────────┐   ┌──┴──────────────────┐
             │  VPC B (App Tier)   │   │ VPC C (Database Tier│
             └─────────────────────┘   └─────────────────────┘

Key Technical Advantages

1. Deterministic Supernet Routing (10.0.0.0/8): Instead of managing dozens of individual CIDR routes in every route table, we add a single summary route:

   Destination: 10.0.0.0/8  -->  Target: tgw-0239c0e4cb62ee813
   

2. Equal-Cost Multi-Path (ECMP): Transit Gateway supports ECMP across multiple VPN attachments or Direct Connect links, scaling aggregated throughput up to 50 Gbps per VPC attachment.
3. Multi-Route Table Isolation (Network Segmentation): You can create distinct TGW Route Tables to enforce strict air-gapping between Production and Staging VPCs while still allowing both to access a shared Services VPC.

---

When to Choose What?

Requirement	VPC Peering	AWS Transit Gateway
Topology	Point-to-Point Mesh	Centralized Hub-and-Spoke
Transitive Routing	❌ No	✅ Yes
Routing Table Overhead	High (Exponential)	Low (Centralized Summary Routes)
Direct Connect / VPN Aggregation	❌ Separate per VPC	✅ Centralized at TGW
Pricing	Data transfer only	Hourly attachment + Data processing
Best For	2-3 VPCs with low complexity	Enterprise, Multi-Account, Microservices

---

Conclusion

In our production deployment in Mumbai (ap-south-1), switching to Transit Gateway (tgw-0239c0e4cb62ee813) reduced our route table configuration complexity by over 80% and gave us instant cross-VPC reachability between Public Ingress, Application, and Private Database tiers with zero packet drops.