Hub-and-Spoke Is Dead, Long Live Hub-and-Spoke: Azure Networking with Virtual WAN

Azure gives you two ways to build a global network: classic hub-and-spoke you assemble yourself, or Virtual WAN, where Microsoft runs the hub. The right answer depends on scale, routing complexity, and how much undifferentiated heavy lifting you want to own.

Classic hub-spoke: still the right default under ~3 regions

You control everything: the hub VNet, the firewall, the route tables, the peering mesh. That control is a feature and a liability — every UDR is yours to maintain, and transitive routing between spokes goes through infrastructure you operate.

resource peering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-01-01' = {
  name: '${spokeVnet.name}/to-hub'
  properties: {
    remoteVirtualNetwork: { id: hubVnetId }
    allowForwardedTraffic: true
    useRemoteGateways: true
  }
}

Where Virtual WAN earns its premium

• Any-to-any transitive routing without UDR archaeology.
• Global transit across regions on the Microsoft backbone with hub-to-hub routing managed for you.
• Branch connectivity at scale — hundreds of S2S VPN sites with automated configuration.
• Routing intent sends all traffic through the hub firewall with one setting instead of fifty route tables.

The cost: less visibility, per-hub baseline pricing, and some advanced scenarios (NVA quirks, exotic routing) that fight the abstraction.

The honest decision table

Migrating without a maintenance window

The trick is that a spoke can only use one gateway path at a time, but peerings can coexist:

1. Stand up the Virtual WAN hub alongside the existing hub.
2. Connect shared services (DNS, identity) to both.
3. Move spokes one at a time: swap the peering, verify effective routes, watch flow logs.
4. Leave the old hub as a shell for a month before decommissioning.

Whichever model you pick, write it down as a decision record with the triggers that would change the answer — "we adopt Virtual WAN when we exceed two regions or fifty branch sites" turns a future argument into a checklist.