An estate has grown from three VPCs to about twenty-five, all connected with VPC peering. What breaks down at that scale, and what does moving to a Transit Gateway change — including on the bill?

## What actually degrades Nothing about a peering connection gets slower as you add more of them. What degrades is the management surface. **Connection count.** A full mesh of *n* VPCs is *n(n−1)/2* connections. Three VPCs: three. Ten: forty-five. Twenty-five: three hundred. Each one was requested, accepted, tagged and is now something that shows up in an audit. **Route-table entries.** Every VPC's route tables need one entry per peer, in every route table associated with subnets that must reach that peer. Route tables have a quota on entries, and unlike a Transit Gateway you cannot summarize — you cannot point `10.0.0.0/8` at a single peering connection, because each connection only serves its own peer's address space. **Onboarding cost.** The killer. A new VPC is not one change; it is *n* connections and edits to *n* other VPCs' route tables, often across *n* AWS accounts with different owners and different change windows. **Still non-transitive.** All that work buys you no shared services path, no shared egress, and no single place for on-premises to land. ## What a Transit Gateway gives you A Transit Gateway is a regional routing hub. Attachment types include VPC, Site-to-Site VPN, Direct Connect gateway, peering to a Transit Gateway in another Region, and Connect attachments for SD-WAN appliances. Each VPC attaches once and carries one route — often a summary such as `10.0.0.0/8` — pointing at the gateway. The hub routes between attachments transitively, subject to its own route tables. On-premises connectivity arrives once, at the hub, rather than being rebuilt per VPC. And you share one gateway across the whole organization with AWS Resource Access Manager, so member accounts attach their VPCs to a gateway owned by a network account without owning the routing. Onboarding becomes O(1): one attachment, one route, one association. ## The bill, honestly This is where interview answers usually go thin. - **Peering:** no hourly charge for the connection, no per-GB processing fee. You pay only ordinary data-transfer charges, which for same-Region traffic depend on whether it crosses an Availability Zone boundary, and Region-crossing rates for inter-Region peering. - **Transit Gateway:** an hourly charge *per attachment* plus a *per-GB data-processing* charge for traffic through the gateway, on top of the same underlying data-transfer charges. Traffic between two VPCs on the hub is processed by the gateway — and, in the classic gotcha, traffic that traverses the hub in both directions can be charged on the way in and on the way out. The consequence: a chatty pair of VPCs moving tens of terabytes a month can cost meaningfully more on a hub than on a direct peering. Real estates therefore run a hybrid — the hub for general and hybrid connectivity, direct peering preserved for a small number of very-high-volume pairs. Saying that out loud is what marks the answer as operational rather than architectural-diagram-shaped. ## The other tradeoffs **A hop.** Traffic through the gateway takes an extra hop; the added latency is small but non-zero, and it matters for latency-critical east-west paths. **Per-attachment bandwidth.** A VPC attachment has a bandwidth ceiling; peering effectively rides the instances' own limits. For a single very high-throughput flow, direct peering is still the better pipe. **A shared failure and blast-radius domain.** The hub is now a component the whole estate depends on, and its route tables are a place where one mistake reaches everywhere. That is an argument for a dedicated network account, tight change control, and deliberate segmentation rather than one default route table. **Regional scope.** A Transit Gateway is regional. Multi-Region estates connect gateways with peering attachments between them, which is a design decision of its own. ## Migration shape You do not flip 300 connections in a night. The usual path: stand the gateway up in a network account, share it with RAM, attach VPCs one at a time, add the more specific Transit Gateway routes alongside the existing peering routes, validate, then remove peering routes and finally the peering connections. Because a more specific route wins over a less specific one in a VPC route table, you can move traffic pair by pair and keep a rollback. ## What interviewers listen for The combinatorics, the O(1) onboarding, the fact that the hub is where hybrid connectivity naturally lands — and then the cost caveat and the willingness to keep peering where it is genuinely cheaper. An answer that presents Transit Gateway as a strict upgrade has skipped the tradeoff the question is about.