A city now has many VPCs and a growing mesh of peering links that is hard to operate. Leadership asks whether Transit Gateway is worth its attachment costs. What evaluation is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
A hub bus station costs money—but so does paving a driveway from every neighborhood to every other one. Weigh Transit Gateway fees against peering-mesh headaches.
Full Explanation
As a city accumulates many VPCs—parks, utilities, public safety, shared services—a full peering mesh becomes operationally expensive: route table sprawl, overlapping CIDR conflicts, and ticket load for every new spoke. AWS Transit Gateway centralizes connectivity with explicit attachment and data-processing charges. Leadership should compare those clear TGW fees against the total cost of maintaining the peering mesh, including engineer time, outage risk from misroutes, and delayed project delivery. When VPC count and east-west patterns grow, Transit Gateway often wins on total cost of ownership even though it is not free.
Always rejecting Transit Gateway because peering meshes never create operational cost fails by concept: ops overhead is real cost. Peering every new VPC to all existing VPCs without reviewing route or ops overhead scales the problem. Replacing all VPC connectivity with public internet IP allow lists abandons private networking and increases exposure.
Exam caveat: TGW data processing can dominate at high east-west volume—model bytes, not only attachment hours. For very small estates, peering may still be cheaper; the decision is comparative, not dogmatic.
Operational check: count VPCs and peering links, estimate monthly engineer hours spent on mesh changes, price TGW attachments and projected data processing, run a pilot hub for two departments, and compare incident counts and Cost Explorer networking totals after migration off the mesh.