AWS Glossary
VPC Peering vs Transit Gateway
Comparison of AWS networking solutions for connecting multiple VPCs and on-premises networks.
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
Need help with this topic?
Our AWS-certified team implements, audits, and optimizes these services in production — from Bedrock RAG pipelines to multi-account landing zones.