Transit Gateways and Hub-and-Spoke

One hub instead of a mesh

A transit gateway (TGW) is a regional, managed router that many VPCs and VPN or dedicated connections attach to. Each VPC needs one attachment and a route sending other networks' CIDRs to the TGW, rather than a peering to every other VPC. This is the hub-and-spoke model: ten VPCs need ten attachments, not forty-five peerings. A TGW also has its own route tables, which give you segmentation. For example, production and development VPCs can each reach a shared-services VPC (logging, CI runners, DNS) while being unable to reach each other, simply by controlling which attachments propagate routes into which TGW route table. Transit gateways in different regions can be peered. The trade-offs are cost per attachment and per GB processed, and one extra hop compared with direct peering. Google Cloud's Network Connectivity Center and Azure Virtual WAN serve a similar hub role.

Hub-and-spoke

Spoke VPCs never connect to each other directly. Traffic goes from a spoke VPC to the transit gateway hub and then out to another spoke, the shared-services VPC or the on-premises connection.

Count the links before you choose

Two or three VPCs with stable needs: peering is simpler and has no per-GB hub charge. Many VPCs, multiple accounts, VPNs or a need to isolate environments from each other: a transit hub pays for itself in operational sanity.

त्वरित जाँच: How many peering connections does a full mesh of 8 VPCs require?

• 8
• 28
• 16
• 64