Transit Gateway vs VPC Peering

VPC peering: the simple case

A VPC peering connection is a 1:1 link between two VPCs. Once established, instances in either VPC can route to instances in the other as if they were in the same network — subject to security group and NACL rules. Peering is:

• Free. No per-hour or per-GB charges (intra-region). Inter-region peering charges data transfer at inter-region rates but no additional peering-specific fee.
• Cross-account. Works between VPCs in different accounts. Requires the other account to accept the connection request.
• Cross-region. AWS, Azure, and GCP all support peering across regions, using the cloud's backbone.
• Point-to-point. Each peering is one link between two VPCs. To connect three VPCs in a triangle, you need three peerings.
• Non-transitive. If A peers with B and B peers with C, A cannot reach C through B.

The non-transitive property is the most important limitation. It is also what fundamentally distinguishes peering from transit gateway.

The O(n²) problem

Peering is point-to-point, so a fully-connected mesh of N VPCs requires N×(N-1)/2 peering connections. The numbers grow uncomfortably fast:

Each VPC has a route table; each peering target requires its own entry. Adding a new VPC means adding N-1 peering connections and updating N existing route tables. The administrative burden compounds and human error rate compounds with it.

Transit gateway: the hub model

A transit gateway is a regional virtual router. Each VPC attaches to it once. Routing decisions happen on the gateway, not on each VPC. The topology becomes a hub-and-spoke:

• 10 VPCs attached to one transit gateway: 10 attachments total.
• 20 VPCs: 20 attachments total.
• 50 VPCs: 50 attachments total.

Adding a new VPC means one new attachment and a route-table update on the gateway. Existing VPCs see the new VPC's prefix appear in their route table automatically (if routing is configured to propagate).

Transit gateways also accept other attachment types:

• VPN attachments — IPsec VPNs to on-premises.
• Direct Connect Gateway attachments (AWS).
• Peering attachments — connect transit gateways across regions or accounts.
• Connect attachments — GRE tunnels to SD-WAN appliances.

This makes the transit gateway the single point of policy for all multi-VPC and hybrid traffic.

Side-by-side comparison

The decision rule

Start with peering. Move to transit gateway when one of these triggers fires:

1. 5+ VPCs that all need to talk to each other. The peering mesh becomes unmanageable.
2. Multiple VPCs need shared on-premises connectivity. Without transit gateway, each VPC needs its own VPN or Direct Connect attachment.
3. Multiple VPCs need shared egress through an inspection appliance. Centralized firewall inspection is much simpler with TGW than with peering.
4. Operational complexity from per-VPC route management is causing incidents. Route-table sprawl is a real production failure mode.

If you have 2-3 VPCs that need to talk and you have no on-premises, peering is correct. The transit gateway hourly attachment fee adds up to several hundred dollars per month for no operational benefit at that scale.

The hybrid case: peering + transit gateway

You do not have to pick one or the other. A common pattern:

• Most VPCs attach to a transit gateway for the shared backbone.
• Two specific VPCs that exchange very high traffic are peered directly. This bypasses the transit gateway's per-GB data processing charge.

For example: a logs VPC and a SIEM VPC pushing 10 TB/month between them would cost $200/month in transit gateway data processing alone. Peering them directly is free. Other VPCs continue to use the transit gateway for normal traffic.

Migration from full-mesh peering to transit gateway

The transition is rarely greenfield. Most organizations start with a few peering connections, grow to many, then migrate when the operational cost becomes painful. A safe migration:

1. Provision the transit gateway. No traffic flows through it yet.
2. Attach each VPC to the transit gateway. This does not affect existing peering traffic.
3. Add transit gateway routes to each VPC's route table. Initially, peering routes are still more specific (or earlier in the route table) and continue to be used.
4. One peering at a time, remove the peering routes from one side. Traffic now flows via transit gateway. Monitor for any issues. If something breaks, restore the peering routes immediately.
5. After all peering traffic has been redirected, delete the peering connections.

The migration is reversible at every step. The longest segment is verifying application connectivity after each switch — depending on test coverage, plan 1-2 weeks per peering connection in production-critical environments.

Centralized firewalling: the killer transit gateway pattern

The single biggest reason organizations adopt transit gateway beyond just multi-VPC connectivity: it enables a centralized firewall / inspection VPC pattern. Traffic between any two VPCs (or to/from on-premises) can be forced through an inspection VPC where a firewall appliance, IDS, or DPI tool processes it before forwarding.

The pattern:

1. Provision an inspection VPC with a firewall appliance (AWS Network Firewall, Palo Alto, Check Point, Fortinet, etc.).
2. Attach the inspection VPC to the transit gateway.
3. Configure the transit gateway route table so that traffic between spoke VPCs first routes to the inspection VPC.
4. The firewall processes traffic and forwards it onward through the transit gateway.

This is impossible with VPC peering because peering is direct VPC-to-VPC; there is no intermediate hop to insert inspection on. Once you need this capability, transit gateway is the only option.

Frequently Asked Questions

Is VPC peering transitive?

No. If VPC A peers with VPC B, and VPC B peers with VPC C, traffic from A cannot reach C through B. Peering relationships are point-to-point. This is the single most consequential limitation of peering and the reason transit gateway exists — a transit gateway is the hub that gives you transitive routing across many VPCs.

When should I switch from VPC peering to a transit gateway?

Roughly at 5-7 VPCs. The peering count scales O(n²) — 5 VPCs need 10 peerings, 10 VPCs need 45 peerings, 20 VPCs need 190 peerings. The administrative burden of managing route tables across all of them becomes the limiting factor before the peering count itself hits the per-VPC quota. Transit gateway centralizes routing — each VPC has one attachment to the gateway, and policies are managed centrally.

What is the cost difference between peering and transit gateway?

VPC peering is free — no per-hour charge, no data processing charge. AWS Transit Gateway costs roughly $0.05/hour per attachment plus $0.02/GB processed. For a 10-VPC network running 24/7 with 10 TB/month traffic, that is approximately $360/month in attachment fees plus $200/month in data processing = $560/month. The same 10 VPCs peered are free. Transit gateway pays for itself in operational simplicity at scale; peering pays for itself in cost at small scale.

Can VPCs in different regions peer with each other?

Yes — inter-region VPC peering is supported on all three major clouds. AWS calls it VPC Peering across regions; the connection uses AWS's backbone rather than the public internet. Data transfer is billed at inter-region rates rather than inter-AZ rates. For a network spanning many regions, inter-region transit gateway peering is more manageable than mesh inter-region VPC peering.

Does VPC peering allow overlapping CIDRs?

No. Both VPCs must have completely non-overlapping CIDR ranges. The peering connection itself fails to establish if any CIDR overlaps. This is why CIDR planning matters from day one — using 10.0.0.0/16 as the default for every VPC guarantees they can never be peered later. Always allocate non-overlapping CIDR ranges per VPC up front, even if you do not currently plan to peer them.