Ten VPCs in a full mesh need 45 peering connections. Twenty need 190. Those figures come from the full-mesh formula N × (N − 1) / 2, which a practical comparison of the two services tabulates for 2 to 20 VPCs. If you run between 4 and 20 VPCs, you already know the real cost is not the connection count. It is the route tables, security group rules and tribal knowledge behind each link.
This guide skips the definitions. It gives you triggers, a cost worksheet you fill in with your own numbers, and a cutover plan with a rollback path.
Operational load: the first trigger to measure
The comparison article describes peering as point-to-point with distributed management. It describes Transit Gateway (TGW) as hub-and-spoke with centralized routing. It also notes that peering does not provide transitive routing: if A peers with B and B peers with C, A cannot reach C through B. Every pair that needs to talk therefore needs its own link.
The article's table shows a full mesh needing 6 connections at 4 VPCs, 10 at 5, 45 at 10 and 190 at 20. Most real estates are not full meshes, so count your actual links rather than the theoretical maximum. Then count the route entries. This is an inference from how peering routing works: each link needs a route on both sides, in every route table that serves the relevant subnets. With TGW, each VPC route table points at the gateway, and the pairing logic moves into TGW route tables.
Here is a rough threshold, offered as judgment rather than a measured fact. If a new VPC means touching five or more existing VPCs, or a missing return route has already bitten you, peering has started to cost more than it saves. To get your own number, track for a month how many route or security group changes it takes to connect or disconnect one environment.
Segmentation and hybrid links: triggers that cost math may not outweigh
Two requirements can change the answer regardless of VPC count.
The first is segmentation. The comparison article describes TGW route tables as the way to control routing between attachments, for example allowing development to reach shared services while blocking development from production. In a peering mesh, you get the same result by omitting routes and policing every VPC separately.
The second is hybrid connectivity. The article lists connecting AWS to on-premises networks as a strong TGW use case and says it is not peering's primary role. If a VPN or Direct Connect link is on your roadmap, factor it in now. Moving twice costs more than moving once.
The table below is a rule of thumb built from those triggers, not a benchmark. Adjust the VPC thresholds to your own change history.
| Situation | Lean toward | |---|---| | 2 to 3 VPCs, stable, no hybrid link | Stay on peering | | 4 to 6 VPCs, few pairs actually talk | Stay, revisit at the next new VPC | | 7+ VPCs with many pairs, or growth planned | Migrate | | Need dev/prod isolation enforced centrally | Migrate | | VPN or Direct Connect to on-premises planned | Migrate | | One very high-volume pair, rest light | Hybrid: TGW plus a retained peering link | | Overlapping CIDRs you cannot renumber | Fix addressing first, then decide |
The sixth row deserves emphasis. Adopting TGW does not force you to delete every peering connection. A heavy point-to-point link, such as a data pipeline between two VPCs, can stay peered if the per-GB math says so.
Cost: a break-even worksheet with your own numbers
The comparison article summarizes pricing in one line: peering involves data transfer considerations, while TGW involves attachment and data-processing considerations. It adds that pricing varies by architecture, traffic, Region and usage. This guide hard-codes no rates because they change. Open the Amazon VPC pricing page (peering and data transfer) and the AWS Transit Gateway pricing page for your Region, then copy the current numbers into the variables below.
Define your inputs:
- A = number of TGW attachments (one per VPC you move)
- H = hours in the billing month (about 730)
- R_att = attachment price per hour
- G_tgw = GB per month that will cross TGW
- R_proc = TGW data-processing price per GB
- G_peer = GB per month you currently send over peering
- R_xfer = per-GB data transfer charge that applies to your peered traffic (the pricing page explains when this is zero and when it is not)
Then compute:
TGW_monthly = (A x H x R_att) + (G_tgw x R_proc)
Peering_monthly = G_peer x R_xfer
Infra_delta = TGW_monthly - Peering_monthly
Ops_saved = (hours/month saved on route and SG changes) x (loaded hourly cost)
Net = Ops_saved - Infra_delta
If Net is positive, migration pays for itself on your own terms. If it is negative but you need segmentation or a hybrid link, treat the delta as the price of that capability. For more on this, see more on best webdav mount tool for windows: pick and test one.
Run one more check for each pair that might stay on peering. Compare G x R_proc (what TGW would add for that pair's traffic) against G x R_xfer (what peering costs). If the TGW figure is large relative to the hours you would save on that one link, keep it peered. Measure Ops_saved from your change history instead of guessing.
Cutover: a phased runbook with a rollback
The goal is to build the entire TGW path before any production traffic touches it, then move one route at a time.
Route priority: verify, do not assume
During cutover, the key question is what happens when a VPC route table holds both a peering route and a TGW route for the same or overlapping destination. The comparison article does not cover it, and the answer should not come from memory.
Read the AWS documentation on route priority for VPC route tables. Look specifically at how it treats longest-prefix matches, static versus propagated routes, and identical destinations. Then prove the behavior in a non-production route table before you rely on it. The runbook below sidesteps the ambiguity by replacing a route's target in place, one destination at a time.
Phase 0: pre-checks
Inventory these before creating anything:
- CIDR overlap. The comparison article stresses planning IP space before connecting networks, and overlapping ranges create major limitations. List every VPC CIDR and confirm none overlap, including with on-premises ranges.
- Route tables. Export every route table that currently targets a pcx- connection. Save destination, target and associated subnets. This file is your rollback record.
- Security groups. Check for rules that reference a peer's security group ID or use the peer's CIDR. Confirm in the AWS documentation whether cross-VPC security group referencing works over TGW. If it does not, rewrite those rules to CIDR-based ones first.
- Subnets for attachments. Pick one subnet per Availability Zone you use in each VPC. Cross-AZ behavior affects traffic paths, so note it.
Phase 1: build TGW with no traffic on it
The commands below are unexecuted. They assume AWS CLI v2 and IAM permissions for EC2 networking actions. Replace every placeholder, and confirm flags against the current CLI reference. This pairs well with check storage layout before upgrading a proxy contract in depth.
## UNEXECUTED example: disable default association/propagation for explicit control
aws ec2 create-transit-gateway \
--description "core-hub" \
--options DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable
## UNEXECUTED: one attachment per VPC
aws ec2 create-transit-gateway-vpc-attachment \
--transit-gateway-id tgw-EXAMPLE \
--vpc-id vpc-EXAMPLE-A \
--subnet-ids subnet-EXAMPLE-1 subnet-EXAMPLE-2
## UNEXECUTED: route table, association, propagation
aws ec2 create-transit-gateway-route-table --transit-gateway-id tgw-EXAMPLE
aws ec2 associate-transit-gateway-route-table \
--transit-gateway-route-table-id tgw-rtb-EXAMPLE \
--transit-gateway-attachment-id tgw-attach-EXAMPLE-A
aws ec2 enable-transit-gateway-route-table-propagation \
--transit-gateway-route-table-id tgw-rtb-EXAMPLE \
--transit-gateway-attachment-id tgw-attach-EXAMPLE-A
Repeat for each VPC. Nothing changes for workloads yet, because no VPC route table points at the gateway.
Phase 2: cut over one low-risk pair, both directions
Pick a development pair. Change both sides, because the return route is where cutovers fail.
## UNEXECUTED: swap the target for one destination in VPC-A's route table
aws ec2 replace-route --route-table-id rtb-EXAMPLE-A \
--destination-cidr-block 10.1.0.0/16 --transit-gateway-id tgw-EXAMPLE
## UNEXECUTED: swap the return route in VPC-B's route table
aws ec2 replace-route --route-table-id rtb-EXAMPLE-B \
--destination-cidr-block 10.0.0.0/16 --transit-gateway-id tgw-EXAMPLE
Phase 3: verify
Run your real application check from both directions, such as a curl against the service port or a database connection. Then confirm the path with VPC Reachability Analyzer (create-network-insights-path, then start-network-insights-analysis). Also check VPC Flow Logs for accepted traffic between the two VPCs.
You should see requests succeed and the analyzer report the path as reachable through the attachment. The commands in this runbook are unexecuted, so confirm the exact output format in your own account.
Also read: related topic: google play organization vs personal account: which to pick
The failure case: a missing return route or association
Suppose you replace the route in VPC-A but forget VPC-B. Requests leave A through TGW, but replies head back through the old peering route. Expect timeouts and half-open connections rather than a clean error, and expect Reachability Analyzer to flag the broken hop.
A related failure is an attachment with no association to a TGW route table. The comparison article's troubleshooting chain applies directly: source, VPC route table, Transit Gateway, TGW route table, destination VPC, security controls. Walk it in that order.
Rollback
Keep the peering connection active and routable through the whole bake period. To roll back, replace the target again using the file you saved in Phase 0:
## UNEXECUTED rollback: point the destination back at the peering connection
aws ec2 replace-route --route-table-id rtb-EXAMPLE-A \
--destination-cidr-block 10.1.0.0/16 --vpc-peering-connection-id pcx-EXAMPLE
Delete a peering connection only after a full business cycle without incident, including any monthly batch jobs. Migrate pair by pair, and move the highest-risk production links last.
Who should choose what
- Stay on peering if you have a handful of VPCs, few real pairs, no hybrid plans and no isolation rules to enforce.
- Migrate now if adding a VPC means editing several others, if you need enforced segmentation, or if an on-premises link is coming.
- Migrate later if the worksheet's Net is close to zero and nothing else forces your hand. Set a trigger, such as the next new VPC.
- Plan a hybrid end state if most links are light but one or two carry heavy sustained traffic. Put the many on TGW and keep the heavy pairs peered, after comparing their per-GB figures on the current pricing pages.
