VPC Peering vs Transit Gateway

Definition

VPC Peering is a direct layer-3 connection between two VPCs — traffic stays on the AWS network, and each peering relationship is a 1:1 link with its own route table updates. AWS Transit Gateway is a regional hub that many VPCs, VPN connections, and Direct Connect attachments plug into; route tables on the hub control which attachments can talk to which. Peering is simpler and cheaper at small scale; Transit Gateway scales linearly instead of quadratically as VPC count grows.

When to use it

VPC Peering

• Two or three VPCs that need full bidirectional connectivity and will stay at that scale.
• Temporary or dev/test links between a sandbox VPC and a shared services VPC.
• Same-region peering where data transfer cost is acceptable and you want zero hourly attachment fees.

Transit Gateway

• Five or more VPCs, or an organization that adds accounts/VPCs regularly.
• Hub-and-spoke with on-premises via Site-to-Site VPN or Direct Connect on the same attachment model.
• Cross-account connectivity with centralized route management and optional inter-region peering between Transit Gateways.
• Segmented routing — e.g., shared-services VPC reachable from app VPCs but not from each other.

When not to use it

VPC Peering

• Transitive routing expectations — peering A↔B and B↔C does not give A↔C; each pair needs its own peering connection and routes.
• Many-VPC mesh — ten VPCs need up to 45 peering connections; operational overhead explodes.
• Overlapping or conflicting CIDRs — peering requires non-overlapping IP ranges.

Transit Gateway

• Two VPCs on a tight budget — hourly per-attachment cost exceeds free regional peering for a pair.
• Latency-sensitive same-AZ traffic where an extra hop through the TGW matters (rare but real for HFT-style workloads).

Tips

• Document CIDR allocation across accounts before the first peering connection — retrofitting non-overlapping ranges is painful.
• For Transit Gateway, use separate route tables per segment (prod, dev, shared services) instead of one flat table.
• Enable TGW flow logs when troubleshooting asymmetric routing — peering and TGW issues often show up as one-way connectivity.
• Regional peering is free; inter-region peering and TGW data processing both bill per GB — model cross-region traffic early.

Gotchas

Serious

• Transitive peering myth — teams assume hub VPC routing works like a router; it does not. Missing routes cause “works from one direction” failures that are hard to spot.
• Overlapping CIDRs block peering entirely; TGW can connect the attachments but routes still cannot resolve conflicting destinations.
• Single Transit Gateway as sole path — if the TGW route table is misconfigured, every spoke loses connectivity at once; test route changes in a non-prod segment first.

Regular

• Forgetting to update both sides — peering requires accepter-side routes and security groups/NACLs, not just the requester.
• DNS resolution across peering — enable “DNS resolution” and “DNS hostnames” on both VPCs or private hosted zone association fails silently.
• Starting with peering and migrating later — replatforming 20 peering connections to TGW is a project; pick TGW early if growth is likely.

Official references

• What is VPC peering?
• What is a transit gateway?
• Transit gateway route tables
• VPC peering configurations

Related FactualMinds content

• VPC networking best practices for production
• AWS Architecture Review
• Amazon VPC