AWS Transit Gateway vs VPC Peering: Cost, Complexity, Scale

If you have two VPCs that need to talk, AWS gives you two main options: VPC peering (a direct point-to-point connection) or Transit Gateway (a hub-and-spoke router). They have very different cost, complexity, and scaling profiles. Picking the wrong one can result in either a $0 solution that scales poorly or a $200+/month bill for what should be free.

This article compares the two, walks through the breakeven analysis as VPC count grows, and covers the operational patterns that work.

The two options at a glance

VPC Peering: simple, free, doesn't scale

A VPC peering is a direct connection between two VPCs. Once established, instances in either VPC can route to instances in the other (provided route tables and security groups allow it).

Pros

• No fixed cost. Pay only for data transfer ($0.01/GB cross-AZ, $0.02/GB cross-region in 2026).
• Simple to set up. Request peering, accept, update route tables, done.
• No latency added. Direct VPC-to-VPC routing.
• Supports referencing security groups across the peering (within a single region).

Cons

• Not transitive. If VPC-A peers with VPC-B and VPC-B peers with VPC-C, VPC-A cannot reach VPC-C through VPC-B. Each pair needs its own peering.
• Quadratic scaling. A full mesh of N VPCs needs N(N-1)/2 peerings. 10 VPCs = 45 peerings. 20 VPCs = 190 peerings. That's a lot of route tables to maintain.
• 125 peering limit per VPC (with quota increase). For very dense organizations this becomes a hard cap.

Transit Gateway: hub-and-spoke that scales

Transit Gateway (TGW) is a managed router. You attach VPCs to it, configure routing, and traffic flows through the hub.

Pros

• Transitive routing. Any attached VPC can reach any other attached VPC.
• Linear scaling. Adding a new VPC means one new attachment, not N new peerings.
• Multiple route tables let you segment which VPCs can reach which others (e.g., prod and dev isolated even though attached to the same TGW).
• Supports VPN and Direct Connect attachments, so on-premises networks fit the same topology.
• Inter-region TGW peering for global mesh.

Cons

• Fixed cost. $0.05/hour ($36/month) per TGW, plus $0.05/hour per attachment ($36/month per attached VPC), plus $0.02/GB processed.
• For 10 VPCs: $36 (TGW) + 10 × $36 (attachments) = $396/month base, before any data.
• Slight added latency (~1-2 ms) for traffic going through the TGW versus direct peering.
• Cannot reference security groups across attachments (must use CIDR-based rules).

The breakeven analysis

Setup time and operational cost matter, but raw AWS bills are easier to compute. For data transfer the cost is similar either way (TGW adds $0.02/GB processing on top of the underlying transfer). For the fixed costs:

Strictly on AWS bill, peering is always cheaper. The reason TGW exists is operational complexity. Maintaining 1,225 peerings is not feasible for human operators — every new VPC requires updating ~50 other VPCs' route tables. Mistakes in any of them cause silent connectivity failures.

For most organizations, the breakeven is around 5-7 VPCs where the operational burden of maintaining the peering mesh outweighs the TGW cost.

The hybrid pattern (most common in practice)

Production AWS organizations often use both:

• Transit Gateway as the primary backbone for most VPCs.
• VPC peering for specific high-traffic VPC pairs where TGW's per-GB processing cost matters.

For example, suppose your shared services VPC needs to reach your application VPC at 50 TB/month. Through TGW that's $1,000/month in processing fees alone. A direct peering between those two VPCs is free (data transfer cost is the same either way). Hybrid setups can save substantial money for known-high-bandwidth flows.

Route table segmentation with TGW

One of TGW's killer features is multiple route tables. Use cases:

• Prod/dev isolation: Prod VPCs use a route table that does not have routes to dev VPCs, and vice versa.
• Inspection VPCs: Force all traffic to traverse a firewall VPC before reaching destination VPCs.
• Per-environment segments: Each business unit's VPCs see only their own.

This is the AWS-native equivalent of MPLS L3VPN-style segmentation, without needing actual MPLS.

Common mistakes

• Using TGW for 2-3 VPCs. Almost always overkill. Use peering until your mesh becomes painful.
• Using peering for 10+ VPCs. The operational pain is real, even if the AWS bill is lower. Migrate to TGW.
• Forgetting TGW processing fees on cross-VPC traffic. $0.02/GB adds up. Audit your top bandwidth pairs.
• CIDR overlaps in TGW attachments. Like peering, TGW rejects overlapping VPC CIDRs. See our multi-cloud CIDR planning article.
• Not using route tables for segmentation. A single TGW with one route table is just a faster peering mesh. The segmentation features are the real value.

Alternatives worth knowing about

• AWS Cloud WAN — newer service, manages multi-region TGW topologies and on-prem connectivity from a single policy document. Worth evaluating for global deployments.
• VPC Lattice — service-level connectivity (not VPC-level), better for microservice-to-microservice traffic across VPCs.
• PrivateLink — for service exposure rather than full mesh routing. Often better when only specific services need to be reachable across VPCs.

Key takeaways

• VPC peering is free, point-to-point, and scales quadratically. Good for 2-5 VPCs.
• Transit Gateway costs ~$36/month + per-attachment + per-GB processing, but scales linearly with route table segmentation features.
• Breakeven point operationally is around 5-7 VPCs.
• Hybrid (TGW backbone + peering for high-bandwidth pairs) is the cost-optimized pattern.
• Always non-overlapping VPC CIDRs — both peering and TGW reject overlaps.