VPC Peering vs Transit Gateway: When to Actually Switch

Stay on VPC peering until you have a concrete reason to leave it — roughly 4-5 VPCs, a hub you need to route through, or a shared-egress/inspection requirement. Peering is free for the connection itself; you pay only for data transfer, and same-AZ cross-VPC traffic is free within a Region. Transit Gateway (TGW) costs about $0.05/hour per attachment (~$36/month per VPC attached) plus $0.02/GB of data processed. The mesh you can hand-manage with peering becomes a full-time job somewhere between three and five VPCs, and that inflection point — not a vendor blog’s diagram — is your signal to switch.

Why peering feels great, then doesn’t #

A VPC peering connection is a one-to-one link. Two VPCs peer, routes get added to each side’s route tables, and traffic flows privately without a gateway hop. For a typical setup — one app VPC talking to a shared-services VPC, or a staging VPC reaching a monitoring VPC — this is the right tool. There’s no per-hour charge, latency is effectively the same as intra-VPC, and the security model is easy to reason about because each link is explicit.

The problem is that peering is non-transitive. If VPC A peers with B, and B peers with C, A still cannot reach C through B. To fully connect N VPCs you need N×(N−1)/2 peering connections: 3 VPCs need 3 links, 5 VPCs need 10, 8 VPCs need 28. Each link means route-table entries on both sides, and every new VPC forces you to touch every existing one. This is the quiet tax nobody prices in when they draft the first architecture diagram — it’s the same category of hidden cost we broke down in the anatomy of an AWS bill shock, except here the cost is operational, not a line item.

What Transit Gateway actually buys you #

Transit Gateway is a regional hub. Each VPC attaches once, and TGW handles routing between all attachments through route tables you manage centrally. Adding a sixth VPC means one attachment and one route table update — not five new peering connections. That’s the real value: the operational cost stops scaling quadratically and becomes linear. TGW also unlocks patterns peering can’t do cleanly, like a single shared NAT/egress VPC for internet access, centralized traffic inspection through a firewall VPC, and connecting VPCs to on-prem via a single VPN or Direct Connect attachment.

The trade-off is money and a small latency bump. You pay per attachment per hour whether or not traffic flows, and every gigabyte crossing the gateway is billed at the data-processing rate on top of normal transfer. For a five-VPC hub that’s roughly $180/month in attachment fees alone before any data. There’s also an extra routing hop, which adds a low-single-digit-millisecond latency for cross-VPC calls — usually irrelevant for service-to-service HTTP, occasionally relevant for chatty replication traffic.

The switch decision, stated plainly #

Do the arithmetic honestly. If you have three VPCs and no plan to grow past four, peering wins on both cost and simplicity — full stop. If you’re at five VPCs and climbing, or you need any-to-any reachability, a shared egress point, or centralized inspection, TGW’s flat ~$36/month/attachment is cheaper than the engineer-hours you’ll spend maintaining a mesh and debugging asymmetric routes. The one order that matters when you migrate is this:

• Stand up the Transit Gateway and attach VPCs without changing any route tables yet — attachments are inert until routes point at them.
• Add TGW routes and remove the corresponding peering routes one VPC pair at a time, verifying reachability after each pair.
• Delete the now-unused peering connections only after every route has moved and traffic is confirmed flowing through the gateway.

Reversing that order is how you cause an outage: pull peering routes before TGW routes exist and traffic goes nowhere. Because TGW is regional, remember that a peering connection can span Regions with inter-Region peering, whereas a single TGW is Region-scoped and needs TGW peering to reach another Region — a detail that surprises teams running active-active across us-east-1 and eu-west-1.

Where Vylara fits in this decision #

Vylara deploys into your own AWS account, so whatever network topology you land on is yours to keep and reason about. When you connect the GitHub App and the Vylara agent analyzes your repo, it detects the services and managed resources your app needs — a PostgreSQL database, a Redis cache, storage — and provisions them in your account on the first deploy, inside a VPC with security groups generated from your code rather than hand-copied defaults. We wrote about why that matters in security groups generated from your code: tighter rules, less drift.

Vylara’s default deployments target a single application VPC with a load balancer and blue/green releases, which is exactly the scale where peering — if you need it at all — beats a Transit Gateway. Vylara doesn’t automatically build a multi-VPC TGW hub for you; that architecture is a deliberate choice you make as you scale into multiple accounts and Regions. What Vylara does give you is the infrastructure chat: after launch you can ask the agent to describe your VPC, security groups, and load balancer configuration, and it reads that network state directly from AWS so you’re deciding against reality, not a stale diagram. Any change that modifies infrastructure still goes through your explicit approval.

Bottom line: treat Transit Gateway as an upgrade you earn, not a default you start with. Ship on the simplest topology that works — usually one VPC, occasionally a peering link or two — and switch to a hub when the peering-connection count crosses your patience threshold or a shared-egress requirement lands. For the broader picture of running production infrastructure this way, see the AWS pillar.