We have three VPCs and peering is becoming unmanageable
VPC peering is fine for two or three VPCs. Above that it scales poorly: every new VPC needs N new peerings. Transit-gateway is the right step, but it costs.
Try this first
- 1Count your peerings: 4 VPCs means 6 peerings, 5 means 10. Above that, transit-gateway starts to make sense.
- 2Deploy one transit-gateway per region and attach every VPC. Route tables on the gateway decide who can reach whom.
- 3Calculate cost upfront: transit-gateway attachment is hourly per VPC plus per-GB data. For low-volume inter-VPC traffic, peering can stay cheaper.
- 4For cross-region or cross-account: transit-gateway peering or Cloud WAN. Stop maintaining manual per-VPC routes.
- 5On Azure this is Virtual WAN, on GCP it's Network Connectivity Center. Same pattern, different names.
When to bring us in
If you have more than ten VPCs or multi-account with cross-region traffic, a network architect who does this often is worth bringing in.
See also
- Everyone logs in with the AWS root accountRoot is for emergencies and billing. Day-to-day work belongs in IAM users or SSO.
- Every developer has AdministratorAccessAdministratorAccess everywhere is convenient now, painful later. Start with role-based policies.
- Everyone has individual IAM users with their own passwordIdentity Center (formerly AWS SSO) links to your IdP and issues temporary credentials per session.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.