AWS Transit Gateway vs VPC Peering: Which to Use and When

When you need to connect multiple VPCs — whether for multi-account architectures, shared services, or environment isolation — you have two primary options: VPC Peering and AWS Transit Gateway. They’re often treated as interchangeable. They’re not.

Here’s how to choose between them and when each is the right answer.

What each service does

VPC Peering creates a direct, private network connection between two VPCs. Traffic routes through the AWS backbone, not the public internet. The connection is one-to-one: VPC A peered with VPC B, VPC B peered with VPC C — that does not mean VPC A can reach VPC C. VPC peering is non-transitive.

AWS Transit Gateway (TGW) is a network hub that connects multiple VPCs and on-premises networks. VPCs attach to the Transit Gateway; the TGW routes traffic between them. Because all routing flows through a central hub, transitive routing works: VPC A attached to TGW, VPC C attached to TGW — A and C can communicate through the hub.

Cost comparison

This is often the deciding factor.

VPC Peering:

• No hourly charge for the peering connection itself
• Data transfer: $0.01/GB for cross-AZ traffic within a region
• Cross-region peering: varies by region pair ($0.01–$0.09/GB)
• Intra-AZ traffic within peered VPCs: free

Transit Gateway:

• Attachment charge: $0.05/hour per VPC or VPN attachment (~$36/month per attachment)
• Data processing: $0.02/GB processed through the TGW
• Cross-region (TGW peering): $0.02/GB + inter-region data transfer

At low traffic volumes, the math strongly favors VPC Peering:

TGW becomes cost-competitive only when the operational cost of managing many peering connections exceeds the Transit Gateway fee — which happens at scale.

The transitive routing problem

VPC Peering’s critical limitation: connections are non-transitive.

To fully connect 10 VPCs with peering, you need n(n-1)/2 = 45 peering connections. Each connection must be configured in both VPCs’ route tables. With 20 VPCs, you need 190 peering connections.

This creates:

• Operational complexity: every new VPC requires peering to every existing VPC
• Route table maintenance: each VPC route table must list routes to every peer
• Security group references: security group references work within a VPC; peered VPC SG references require explicit peering connection IDs

Transit Gateway solves this with hub-and-spoke topology. Each new VPC needs one TGW attachment. The TGW route table handles the rest.

The inflection point: When you have 5+ VPCs that all need to communicate, Transit Gateway’s operational simplicity typically justifies its cost premium.

Feature comparison

Overlapping CIDR blocks: Neither service allows VPCs with overlapping IP ranges to be connected. This is a hard constraint — plan your VPC CIDR blocks with this in mind. A common mistake in multi-account setups is allocating the same /16 to multiple accounts, then being unable to peer them later.

On-premises connectivity

With VPC Peering: On-premises networks connected via VPN or Direct Connect to one VPC cannot route traffic to other peered VPCs. A VPN terminates in one VPC; that VPC’s peers are not reachable from on-premises.

With Transit Gateway: Attach a VPN or Direct Connect Gateway to the TGW. All VPCs attached to the TGW become reachable from on-premises through a single VPN tunnel or DX connection. This is a significant architectural advantage for hybrid cloud setups.

If you have or plan to have an on-premises network connected to AWS, Transit Gateway is almost always the right choice. The alternative — multiple VPN connections to individual VPCs — is operational debt.

Multi-account patterns

AWS Organizations + Transit Gateway: The canonical pattern for multi-account AWS architectures. A networking account owns the TGW and shares it via AWS Resource Access Manager (RAM). Each workload account attaches its VPCs to the shared TGW without needing to own a TGW themselves.

This enables:

• Centralized network operations in one account
• Workload accounts that don’t need networking expertise
• Single point for routing policy enforcement
• Shared services VPC (logging, security tools, Active Directory) accessible from all workload VPCs

AWS Organizations + VPC Peering: Possible, but the management overhead at scale becomes prohibitive. Works well for 3-5 VPCs that need specific connections, not full mesh.

Route table design in Transit Gateway

TGW route tables are the primary isolation and routing control mechanism.

Single route table (simple): All attachments share one route table. Every VPC can reach every other VPC. Appropriate for small, trusted environments.

Multiple route tables (segmented): Separate route tables per environment or security domain. Production VPCs route through a production route table; dev VPCs through a dev route table. Traffic between production and dev requires explicit route entries — providing isolation by default.

TGW Route Tables:
├── Production RT
│   ├── Routes to: prod-app-vpc, prod-db-vpc, shared-services-vpc
│   └── Attachments: prod-app-vpc, prod-db-vpc
├── Dev/Staging RT
│   ├── Routes to: dev-vpc, staging-vpc, shared-services-vpc
│   └── Attachments: dev-vpc, staging-vpc
└── Shared Services RT
    ├── Routes to: all VPCs
    └── Attachments: shared-services-vpc

This pattern allows shared services (logging, monitoring, authentication) to reach all environments while production and dev/staging are isolated from each other.

Bandwidth considerations

VPC Peering: No aggregate bandwidth limit. Single TCP flow limited to 5 Gbps (same as standard EC2 network limits). For high-throughput use cases (large file transfers, high-volume inter-service traffic), peering performs well.

Transit Gateway: 50 Gbps aggregate per AZ. For most workloads, this is more than sufficient. For specific high-bandwidth use cases (large-scale data movement, video processing pipelines), measure whether TGW aggregate throughput could become a bottleneck.

Security considerations

VPC Peering: Traffic is private (AWS backbone) but security is managed at the security group and NACL level in each VPC. There’s no central policy enforcement point — each VPC manages its own ingress/egress rules for peered traffic.

Transit Gateway + Network Firewall: The TGW can be configured to route traffic through AWS Network Firewall before it reaches destination VPCs. This creates a centralized security inspection point for all inter-VPC traffic — the equivalent of a network firewall appliance in the TGW topology. Adds cost ($0.395/hour per AZ for the firewall endpoint + $0.065/GB processed) but provides deep packet inspection, intrusion detection, and centralized egress filtering.

For PCI DSS environments, the TGW + Network Firewall pattern satisfies network segmentation requirements more clearly than VPC Peering, where segmentation must be demonstrated at the security group level for each peer.

The decision framework

Use VPC Peering when:

• You have 2–4 VPCs with specific, stable connectivity requirements
• Traffic volume is low to moderate and cost sensitivity is high
• You don’t have on-premises connectivity requirements
• The connections are long-lived and unlikely to change

Use Transit Gateway when:

• You have 5+ VPCs or expect to add more
• You need on-premises connectivity accessible from multiple VPCs
• You need centralized routing policy (environment isolation)
• You have a multi-account AWS Organizations setup
• You want to add Network Firewall for centralized security inspection
• Operational simplicity matters more than per-unit cost

Migration path

If you started with VPC Peering and have grown to the point where TGW makes sense:

1. Create the Transit Gateway and attach all VPCs
2. Test routing through TGW (without removing peering routes)
3. Update route tables to prefer TGW routes
4. Remove peering connections after validating connectivity

The migration is non-disruptive if sequenced correctly. The primary risk is route table misconfiguration during the transition — test with non-production VPCs first.

Multi-VPC networking is one of those decisions that’s expensive to undo. If you’re designing a new multi-account architecture or evaluating whether to migrate from peering to Transit Gateway, I’m available to help scope it.

Nick Allevato is an AWS Certified Solutions Architect Professional with 20 years of infrastructure experience. He runs Cold Smoke Consulting, an independent AWS consulting practice.