Network topology decays quietly. You start with two VPCs and a peering connection, which is fine. You add a third, then a fourth, and one day you have a full mesh where every VPC peers with every other one, route tables nobody dares touch, and a connectivity diagram that looks like a plate of spaghetti. Transit Gateway is the answer, but only if you use it with some restraint.
Why the mesh stops scaling
VPC peering is non-transitive, which is the detail that bites everyone. If A peers with B and B peers with C, A still cannot reach C. So as you grow you end up adding direct peers for every pair that needs to talk, and the number of connections grows roughly with the square of the number of VPCs, not linearly. Route table management becomes a full-time hazard, onboarding a new VPC means touching every existing one, and nobody can hold the whole picture in their head past about six VPCs.
The hub model
Transit Gateway turns the mesh into a star. Every VPC attaches to one central gateway, and the gateway routes between them. Adding a VPC is now one attachment, not N peering connections. You put the Transit Gateway in a dedicated network account, attach your spokes, and route on-premises connectivity (Direct Connect or VPN) through the same hub, so there is one place that knows how the whole network fits together.
A hub is only simpler than a mesh if you resist the urge to let every spoke talk to every other spoke.
Where teams reintroduce the spaghetti
The mistake is treating Transit Gateway as a flat switch where everything reaches everything by default. The power is in route tables. Use separate Transit Gateway route tables to enforce segmentation: production spokes that should not reach each other, a shared-services route table everyone can reach, and an inspection path for traffic that must be firewalled. Without this you have just moved your flat, ungoverned network behind a more expensive box.
- One Transit Gateway per region, living in the network account.
- Separate route tables to segment prod, non-prod, and shared services deliberately.
- Centralised egress and inspection so traffic to the internet passes through one controlled path.
- Default to no connectivity between spokes; open specific routes only where there is a real need.
When peering is still right
Transit Gateway is not free and it adds a per-gigabyte charge on traffic that crosses it. For two VPCs that exchange a lot of data and nothing else, plain peering is cheaper and simpler, and we keep it. The hub earns its cost once you have enough spokes that the mesh would be unmanageable. Below that threshold, do not pay for a gateway you do not need.
The goal is a topology a new engineer can understand in one diagram. A hub gives you that, but the discipline is in the route tables, not the box. Segment on purpose, default to closed, and the network stays legible as it grows.