Many spoke VPCs must interconnect through a hub rather than a full mesh of individual peerings. Which approach scales that design?
Select an answer to reveal the explanation.
Short Explanation
A full mesh of peerings gets messy fast—like every department insisting on its own private road to every other department. A transit hub is the central roundabout that spokes plug into. That hub-and-spoke pattern scales cleaner than n-squared peerings.
Full Explanation
A transit gateway or equivalent hub-and-spoke transit construct interconnects many spoke VPCs through a central routing layer, which scales more cleanly than maintaining a full mesh of individual peerings as municipal environments proliferate. Shared services, hybrid connectivity, or inspection hubs typically attach at the transit layer while each spoke attaches once with controlled route propagation. Creating a unique public internet VPN from every spoke directly to every other spoke recreates mesh complexity and often expands internet-facing surface area. Duplicating every subnet CIDR so overlapping addresses intentionally collide makes routing ambiguous and breaks interconnect designs. Disabling all routing so spokes can never exchange packets may enforce isolation but does not solve the stated requirement to interconnect many spokes scalably. Exam caveat: prefer hub-and-spoke transit when spoke count and shared-services needs grow; reserve simple VPC peering for small, static pairs of networks. Operational check: publish a non-overlapping IP addressing standard, attach spokes to transit with least-privilege route tables, centralize logging and optional inspection, validate east-west paths against municipal zoning rules, and rehearse adding a new department VPC without redesigning the entire mesh.