Transit Gateway vs VPC Peering for a Migration Landing Zone
Use VPC peering when you have a small, stable set of VPCs that need direct one-to-one connectivity and you want no per-hour charge. Use a Transit Gateway once you need transitive routing, centralised inspection, or more than a handful of VPCs, because peering is not transitive and a full mesh grows as n(n-1)/2 connections. That is the whole of the Transit Gateway vs VPC peering decision, but the cost you are choosing shows up months later, so it is worth getting right before you migrate anything onto it.
This is a landing-zone decision. You make it once, workloads land on top of it, and changing the topology after fifty accounts are live is a project of its own. The rest of this article is the detail a practitioner needs to make the call and wire it up.
What each one actually is
VPC peering is a point-to-point connection between exactly two VPCs. It gives full bidirectional connectivity between them, and the two VPCs can be in different accounts or different Regions. The constraint that drives every architecture decision here is that peering does not support transitive routing. If VPC A is peered with B and with C, an instance in B cannot reach C through A. You would need a separate peering connection between B and C.
A Transit Gateway is a routing hub. Each VPC, VPN, Direct Connect gateway or peering connection is an attachment, and the gateway routes between them using transit gateway route tables that you associate with attachments and propagate routes into. Because everything hangs off one hub, connectivity is transitive by default: any attachment can reach any other attachment whose routes are in the table it is associated with. You also get static routes for backup paths and blackholing.
The practical difference is the shape of the graph. Peering is a mesh you build edge by edge. A Transit Gateway is a star you connect spokes to. For three VPCs the mesh is trivial. For fifteen it is fifteen VPCs times fourteen, halved, so 105 peering connections and their route table entries, each of which you have to create, tag and reason about. That is where teams that started with peering end up rebuilding on a hub mid-migration.
The cost you are choosing
Neither option is free of a downstream bill, and they charge on different axes.
VPC peering has no per-hour connection charge. Data transfer over a peering connection that stays within one Availability Zone is free; traffic that crosses AZs is billed at standard in-Region rates, and cross-Region peering incurs inter-Region transfer charges. So peering is cheap on paper. The cost you defer is operational: the mesh, the route tables, and the fact that adding one VPC to a full mesh of n VPCs means creating n new connections and updating n existing route tables.
A Transit Gateway charges on two axes. You pay for the number of attachments per hour and for the amount of data processed through the gateway per gigabyte. Check the current rate for your Region on the pricing page before you model this, because both components add up in a busy multi-account environment. The trade you are making is real money per attachment-hour and per GB in exchange for a topology that stays flat as you add VPCs. One useful detail: data sent from a peering attachment to a Transit Gateway is not charged a data processing fee, which matters for inter-Region designs.
The honest summary: peering optimises for cost at low VPC counts and punishes you with operational drag as the count grows. A Transit Gateway optimises for operational simplicity and charges you a metered fee for it. The break-even is not a fixed number of VPCs; it is the point where the mesh stops being something a human can hold in their head, which for most teams is somewhere under ten VPCs.
| Dimension | VPC peering | Transit Gateway |
|---|---|---|
| Topology | Point-to-point mesh | Hub and spoke |
| Transitive routing | No, one hop only | Yes, via route tables |
| Per-hour charge | None | Per attachment-hour |
| Data charge | In-Region and cross-Region transfer only | Per GB processed, plus transfer |
| Scaling to add a VPC | New connection to every existing VPC | One attachment |
| Central inspection | Not natively | Yes, with appliance mode |
| Best fit | 2 to ~5 stable VPCs | Many VPCs, shared services, inspection |
What to check before you change anything
Do not change routing on a live network without confirming these first. Each one has bitten a migration.
Overlapping CIDR blocks
Neither peering nor a Transit Gateway routes between VPCs with overlapping IP ranges. If your on-premises estate and your new VPCs share RFC 1918 space, that has to be resolved in IP planning, not at the routing layer. Peering additionally has a DNS quirk: private DNS hostnames for a VPC whose CIDR falls outside the RFC 1918 ranges cannot be resolved to private IPs across the peering connection. Sort addressing before topology.
Cross-VPC DNS resolution
With peering, you cannot query the Amazon-provided DNS server in the peer VPC by default. You enable DNS resolution on the peering connection, or you run Route 53 Resolver rules. If a migrated app resolves a database by private hostname, confirm this works before cutover, not during it.
Quotas
Both sides have limits you can hit. There is a quota on the number of active and pending peering connections per VPC, and a full mesh burns through it fast. Transit Gateways have their own attachment and route quotas per gateway. Most are adjustable through a support case, but a limit increase is not something you want to discover you need on migration night. Read the current values for your account.
MTU and jumbo frames
If you rely on jumbo frames, the numbers differ by path. A Transit Gateway supports an MTU of 8500 bytes between VPCs, Direct Connect and peering attachments, but only 1500 bytes over VPN connections. Applications that assumed 9001-byte frames on-premises will see fragmentation or drops. Test large-payload traffic before you trust the path.
Stateful inspection and AZ affinity
If you plan to route inter-VPC traffic through a firewall or Gateway Load Balancer, know that a Transit Gateway keeps Availability Zone affinity by default, which causes asymmetric routing that stateful appliances drop. The fix is to enable appliance mode on the inspection VPC's attachment. Peering has no equivalent central-inspection story, which is one of the strongest reasons to choose a hub when security review is part of the migration. If encryption in transit across the hub is a compliance requirement, the Transit Gateway also has an encryption control option that enforces it for attached VPCs.
Getting these guardrails and the network foundation right up front is the boring, deliberate work that makes the actual cloud migration cutover uneventful, and it is the kind of decision our cloud architecture practice designs for where you will be in three years, not just at go-live.
The same decision on Google Cloud
The trade-off is not AWS-specific. On Google Cloud, VPC Network Peering gives you the low-cost mesh, and it does not provide transitive routing either: if net-a peers with net-b and with net-c, that does not connect net-b and net-c. Whichever cloud you are on, the question is identical: a cheap mesh you outgrow, or a metered hub you do not.
Frequently asked questions
Is Transit Gateway always better than VPC peering?
No. For two to about five stable VPCs that need direct connectivity, peering has no per-hour charge and less moving machinery. A Transit Gateway earns its metered cost once you need transitive routing, central inspection, or enough VPCs that the peering mesh becomes hard to reason about. Choose based on where the network is heading, not just today's count.
How many VPC peering connections do I need for a full mesh?
For n VPCs it is n(n-1)/2 connections, because peering is point-to-point and non-transitive. Five VPCs need ten connections; ten need forty-five; fifteen need over a hundred. Each connection also needs matching route table entries on both sides, which is the real operational cost as the number grows.
Does traffic through a Transit Gateway cost more than peering?
They bill differently. A Transit Gateway charges per attachment-hour and per gigabyte of data processed, while peering has no per-hour charge and only bills data transfer, with same-AZ transfer over peering being free. Peering is cheaper per byte at small scale; the Transit Gateway buys you operational simplicity for a metered fee. Model both against your actual traffic and Region rates.
Can I route inter-VPC traffic through a firewall with peering?
Not natively. Peering is point-to-point with no central point to insert inspection. A Transit Gateway supports a central inspection VPC, but you must enable appliance mode on that attachment to avoid the asymmetric routing that stateful firewalls drop. If centralised inspection is a requirement, that alone usually decides it in favour of a hub.
Can I start with peering and move to a Transit Gateway later?
Yes, but it is disruptive. You attach the VPCs to the gateway, migrate routes, and tear down peering connections one at a time, testing each path. Doing this after workloads are live means changing production routing, so it is far cheaper to make the call before migration. That is exactly why the topology is a landing-zone decision rather than something to defer.
