Hub-and-Spoke Networking
Hub-and-spoke is the standard enterprise network topology on Azure: a central hub VNet holds shared services — the firewall, the VPN or ExpressRoute gateway, shared DNS — and workload spoke VNets peer into it. Traffic between spokes and to on-premises flows through the hub, where it can be inspected and controlled centrally.
It exists because of two facts established earlier: VNet peering is non-transitive, and address planning is permanent. The hub gives spokes a shared, inspected path to each other and to on-premises without a full mesh of peerings, and centralizes the expensive shared resources (a single gateway, a single firewall) instead of duplicating them per workload.
The Topology
Each spoke VNet peers with the hub, not with other spokes. Because peering is non-transitive, spoke-to-spoke traffic must route through the hub deliberately — via a firewall or network virtual appliance — which is exactly the control point you want. The hub becomes the single place to inspect, log, and police traffic crossing between workloads and to the outside.
Shared Services in the Hub
The hub centralizes what every spoke needs but should not each own: the ExpressRoute or VPN gateway for on-premises connectivity, Azure Firewall for egress inspection, shared DNS resolution, and sometimes a shared application gateway. Centralizing these saves the cost of a gateway per workload and gives one place to manage connectivity and security policy.
Spoke Isolation
Each spoke is a workload's isolated network, peered only to the hub, so a compromise or misconfiguration in one spoke does not reach another except through the hub's controls. This isolation with a controlled join is the security benefit — workloads are segmented by default and connected on purpose.
Virtual WAN
At scale, hand-built hub-and-spoke peering becomes heavy to operate. Azure Virtual WAN is the managed alternative: a Microsoft-managed hub that automates the connectivity, routing, and branch/VPN/ExpressRoute integration of a large hub-and-spoke or global transit network. Between the two, Azure Route Server adds dynamic BGP routing to a hand-built hub — so a network virtual appliance can exchange routes with the VNet automatically — without migrating to Virtual WAN. Choose hand-built for small, static topologies, add Route Server when a hand-built hub needs dynamic routing, and move to Virtual WAN when scale and many connections make manual management painful.
Hand-built hub-and-spoke — You own the hub VNet, peerings, gateway, and firewall. Choose it for small, static topologies with full control.
Virtual WAN — Microsoft-managed hubs that automate routing and branch/VPN/ExpressRoute connectivity. Choose it for scale, many connections, or global transit.
- Building a full mesh of spoke-to-spoke peerings instead of routing through the hub, losing the central inspection point and multiplying connections.
- Forgetting peering is non-transitive and expecting spokes to reach each other through the hub with no firewall or route in place.
- Duplicating gateways and firewalls per spoke instead of centralizing them in the hub.
- Hand-building and operating hub-and-spoke at a scale where Virtual WAN would manage the routing for you.
- Overlapping spoke address ranges, which breaks the peering the whole topology depends on.
- Putting workloads in the hub instead of keeping it for shared services only, coupling everything to the central network.
- Peer each spoke to the hub only, and route spoke-to-spoke and on-premises traffic through the hub's firewall.
- Centralize shared services — gateway, firewall, DNS — in the hub rather than per spoke.
- Keep each workload in its own isolated spoke, connected to the hub on purpose.
- Plan non-overlapping address space across the hub and all spokes up front.
- Use Virtual WAN when scale or many connections make hand-built management painful.
- Reserve the hub for shared services; keep workloads in spokes.
Knowledge Check
Why does hub-and-spoke route spoke-to-spoke traffic through the hub?
- VNet peering is non-transitive, so the hub provides a deliberate, inspected path between spokes
- Spokes are physically unable to peer with one another at the platform level, so the hub is the only possible route
- The hub path is required for cross-spoke DNS name resolution to work
- Routing through the hub is measurably faster than direct VNet peering
What belongs in the hub VNet?
- Shared services — the gateway, firewall, and DNS — not individual workloads
- Each workload's application servers and front-end web tiers, consolidated centrally
- Nothing at all; the hub stays empty as a pure transit VNet
- Only the database tiers consolidated out of every spoke
When is Azure Virtual WAN preferable to hand-built hub-and-spoke?
- At scale or with many connections, where it automates routing and branch/VPN/ExpressRoute integration
- For a small, static two-spoke topology with no growth planned
- Whenever the design needs a central firewall to inspect and filter all north-south and east-west traffic
- Only when there is no on-premises connectivity to integrate at all
You got correct