Hub-and-spoke puts shared connectivity, DNS and usually egress in one network, and attaches application VPCs or VNets as spokes. On AWS the hub is often AWS Transit Gateway plus a network account. On Azure it is a hub virtual network in a Connectivity subscription, peered to spoke VNets. On Google Cloud the closest production pattern is Shared VPC: a host project owns the subnets, service projects attach to them. Spokes should not hold their own internet gateways if you need one inspection point and one NAT bill. Provider docs dated 2026-08-30 define the primitives. Transitive routing is not automatic on every peering type.

Background terms sit in cloud networking fundamentals. Egress money sits in egress cost planning.

Assumptions

  • You can list Transit Gateway attachments, VNet peerings or Shared VPC associations in at least one environment.
  • This page covers AWS Transit Gateway, Azure hub-spoke (Virtual WAN as a named alternative) and Google Cloud Shared VPC. Alibaba CEN is on the Alibaba APAC page.
  • You are deciding where inspection and NAT live, not designing a full SD-WAN.
  • Brownfield estates with overlapping CIDRs are in scope as a blocker, not as a CIDR-migration plan.

What the hub is for

The hub is the place you put things you do not want copied in every application network:

  • On-premises attachment (AWS Direct Connect, Azure ExpressRoute, Cloud Interconnect)
  • Shared DNS resolvers
  • Inspection (AWS Network Firewall, Azure Firewall, a third-party NVA)
  • Central NAT or Cloud NAT
  • Private endpoints to shared platform services

The spoke is the place the workload lives. Route tables in the spoke send default or shared-service prefixes to the hub. They do not send all spoke-to-spoke traffic through the hub unless you decided that inspection is worth the extra hop.

Provider differences that break copy-paste diagrams

AWS Transit Gateway. A transit gateway is a regional network transit hub. You attach VPCs, VPN and Direct Connect gateways, then isolate or share connectivity with transit-gateway route tables. Attachments in the same region can talk if the route tables allow it. Inter-region peering of transit gateways is a separate attachment and a separate data-processing charge. VPC peering is still valid for a pair of VPCs that should never see the hub. Peering is not transitive.

Azure hub-spoke. Microsoft documents a hub VNet that holds the gateway and firewall, with spokes peered to the hub. VNet peering is not transitive. Spoke-to-spoke traffic must go through a hop in the hub (Azure Firewall, a router NVA or Azure Virtual WAN) if you need that path. Azure Virtual WAN is the managed alternative when you have many regions and many branches. It is a different product from a DIY hub VNet.

Google Cloud Shared VPC. The host project owns the VPC and subnets. Service projects run GCE, GKE and other resources on those subnets. This is not the same as VPC Network Peering. Peering connects two VPC networks. Shared VPC shares one network. Landing-zone diagrams usually show one Shared VPC per environment (prod, non-prod), not one VPC per team.

Alibaba Cloud uses Cloud Enterprise Network (CEN) and transit routers. Do not rename those to Transit Gateway. See Alibaba Cloud architecture for APAC workloads.

Confirm attachments and routes

aws ec2 describe-transit-gateways \
  --query 'TransitGateways[].{Id:TransitGatewayId,State:State,Asn:Options.AmazonSideAsn}' \
  --output table

aws ec2 describe-transit-gateway-attachments \
  --filters Name=transit-gateway-id,Values=tgw-0123456789abcdef0 \
  --query 'TransitGatewayAttachments[].{Id:TransitGatewayAttachmentId,Type:ResourceType,State:State}' \
  --output table

State: available on the transit gateway only means the TGW exists. Attachments in pending or pendingAcceptance are not forwarding. ResourceType of vpc versus peering versus direct-connect-gateway tells you whether a spoke is local, inter-region or hybrid. If a spoke VPC is missing from this list, its route table may still point at tgw-... and blackhole.

Azure:

az network vnet peering list --resource-group rg-connectivity --vnet-name vnet-hub -o table

Peering PeeringState must be Connected on both sides. AllowForwardedTraffic must be true on the spoke if the hub will hairpin return traffic.

Google Cloud:

gcloud compute shared-vpc list-associated-projects HOST_PROJECT_ID

A service project that is not associated cannot place instances on the host subnets, even if someone copied a subnet CIDR into a ticket.

Egress and inspection stay in the hub on purpose

An AWS NAT gateway is zonal, billed per hour and per GB processed. Azure NAT Gateway and Cloud NAT have their own meters. If every spoke creates its own NAT, you multiply hourly charges and you lose a single place to read flow logs. The NAT cost runbook is NAT gateway cost increase.

Inspection in the hub adds a hop and a throughput limit. Size the firewall or NVA for peak spoke-to-internet and spoke-to-spoke flows you actually allow. Do not assume the hub can inspect east-west at line rate because the diagram looks clean.

Risks and limitations

Transit Gateway, Azure Firewall and Cloud NAT are regional. A second region needs a second hub or Virtual WAN hub, plus inter-region cost. See cross-region disaster recovery before you copy the hub “for DR” without an RTO.

Overlapping CIDRs cannot attach to the same TGW route table or the same Shared VPC. The failure is at attach time, not at the first packet.

IPv6, private NAT and service-network endpoints change the default route story. Read the current NAT and TGW pages before you lock a design that assumes IPv4 default routes only.

Hub-and-spoke does not replace identity isolation. A flat set of spoke attachments with 0.0.0.0/0 to the hub is still a large blast radius if security groups and NSGs are open.

Official sources