AWS Transit Gateway vs VPC Peering
Compare hub-and-spoke transitive routing with direct non-transitive VPC connections for scale, control, cost, and operations.
Open editable diagramArchitecture diagram
Edit this exact diagram
Open on the canvasAWS Transit Gateway vs VPC peering architecture diagram comparing a transitive hub with many VPC attachments to direct pairwise VPC connections. The image links to a fully editable BuildPlane starter.
Overview
VPC peering creates a direct private route between two VPCs and does not support transitive routing through another peer. AWS Transit Gateway creates a regional hub whose attachments and route tables connect VPCs, VPNs, and Direct Connect gateways transitively. Peering minimizes infrastructure for a few direct relationships; Transit Gateway centralizes a network that has become a platform.
Components
- Shared decision context: Applications, inspection, DNS, and hybrid connections that multiple VPCs need to reach.
- AWS Transit Gateway: A regional routing hub with attachments and route tables for many networks. Segmented spoke networks reach shared services through centrally governed routes.
- VPC Peering Connection: A direct private route between two VPCs with no transitive routing through peers. A few VPCs connected and governed through individual peerings and route entries.
Comparison Flow
- Shared Network Services can enter the AWS Transit Gateway path and continue to Many VPC Attachments.
- Shared Network Services can instead enter the VPC Peering Connection path and continue to Small VPC Mesh.
- Choose the path whose operating model and constraints match the workload, then delete the unused branch in the editable diagram.
Customize First
- Count connections, routes, accounts, Regions, and expected data paths over three years.
- Separate production, shared-services, and inspection traffic with route tables.
- Model inter-AZ and service processing charges from the real traffic matrix.
Side-by-side decision
AWS Transit Gateway vs VPC Peering
Use peering for a few direct, stable VPC links. Use Transit Gateway when transitive routing, centralized segmentation, hybrid attachments, inspection, or multi-account scale makes routing a shared platform.
| Decision factor | AWS Transit Gateway | VPC Peering |
|---|---|---|
| Topology | Hub-and-spoke attachments | Pairwise point-to-point connections |
| Transitive routing | Supported through route tables | Not supported |
| Scale | Designed for many VPC and hybrid attachments | Best for a small stable connection set |
| Segmentation | Multiple TGW route tables and propagation controls | Routes and security managed per peering relationship |
| Hybrid and inspection | Central VPN, Direct Connect, and inspection patterns | No central transit hub behavior |
| Cost shape | Attachment and data processing charges | No hourly peering charge; data transfer still applies |
Related AWS guides
Understand the decisions behind this diagram
Use these practical explanations to compare services, failure boundaries, and operating tradeoffs before adapting the architecture.
Design rationale
Decisions that shape this architecture
Transitivity changes the trust model
A Transit Gateway route table can let one attachment reach many others. That is useful and dangerous. Separate production, non-production, shared services, and inspection into intentional association and propagation domains rather than building one flat transit network.
Peering mesh complexity grows quickly
Each VPC pair needs a connection, routes, DNS choices, ownership, monitoring, and lifecycle. A handful is simple; dozens across accounts create a configuration graph that is difficult to audit and change safely.
Traffic cost follows the path
Transit Gateway processing and inter-Availability Zone paths can matter at scale. Peering can be more direct, but a centralized design may reduce duplicated appliances and operational work. Model the real source-to-destination matrix.
Before production
Operational checks
Verify non-overlapping CIDRs and future address allocation.
Test route-table associations, propagation, blackholes, and failure paths.
Map inter-AZ, cross-Region, inspection, NAT, and hybrid traffic flows.
Monitor rejected routes, attachment health, bytes, and centralized appliance capacity.
Scope and tradeoffs
What this diagram does not solve
PrivateLink and VPC Lattice solve different scopes
If consumers need access to specific services rather than network-to-network reachability, service-level connectivity can reduce lateral exposure and routing complexity.
Transit Gateway is regional
Inter-Region peering between transit gateways and Cloud WAN can extend designs, but regional routing, data cost, and failure ownership remain explicit.
Common questions
Frequently asked questions
Does VPC peering support transitive routing?
No. If VPC A peers with B and B peers with C, A cannot reach C through B. A needs its own direct relationship or a transit service.
When should I move from peering to Transit Gateway?
When the number of pairwise links, accounts, hybrid attachments, route changes, or segmentation policies makes a central hub easier to operate and audit.
Is Transit Gateway always more expensive?
It adds attachment and processing charges, while peering has different transfer costs. At scale, reduced mesh complexity and centralized infrastructure can offset the service cost. Price the actual traffic paths.
Keep exploring
Related AWS architectures
NAT Gateway vs VPC Endpoint
Use VPC endpoints for high-value or high-volume supported services when private routing, endpoint policy, and reduced NAT processing create value. Keep NAT Gateway for package repositories, public APIs, and destinations without endpoint support. Most production VPCs use both: gateway endpoints for S3 and DynamoDB, interface endpoints for selected services, and zonally aligned NAT gateways for the remaining internet egress.
Explore the architecture
Security Groups vs Network ACLs in an AWS VPC
Use security groups to express which application tiers and resources may communicate, ideally through references to other security groups rather than broad IP ranges. Use network ACLs when a subnet needs an explicit deny, coarse IP-based boundary, or backup control against a missing resource rule. Because NACLs are stateless, inbound and outbound rules must both allow response ports, which makes aggressive policies harder to operate.
Explore the architecture
Hybrid Network with AWS Transit Gateway
This hub-and-spoke network architecture separates private connectivity from VPC routing and workload placement. It gives teams a clear place to discuss route-table isolation, shared services, inspection, address planning, redundant circuits, and the boundary between network and application ownership.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.