©️2025 Created by Anuradha Samaranayake
Hub-and-spoke vs Virtual WAN — which one for your landing zone?
CLOUD DIARY
AZURE · NETWORKING · 2026
THE LANDING ZONE FORK IN THE ROAD
OPTION A
Hub-and-spoke
you build the hub
and own the routing
VS
OPTION B
Virtual WAN
Microsoft runs the hub
and the transit
Every landing zone design hits this fork in week one — and it is the hardest decision to reverse once workloads are running.
Both are valid. Neither is better. What actually decides it is your region count, your branch count, and how much routing you want to own.
#Azure
#LandingZone
#VirtualWAN
#HubAndSpoke
⚡ SKIP TO THE SCORER
✍️ Anuradha · about a minute to an answer
the shared problem
Same job, two ways to do it
Both topologies exist to solve one constraint: a virtual network can't span subscriptions. When every workload sits in its own subscription — exactly what the landing zone design principles tell you to do — each one gets its own VNet, and those VNets still need shared hybrid connectivity, transit and inspection.
That shared middle is the hub. The only real question is who builds and operates it.
⚖️
Everything else — cost shape, routing effort, how far it scales — follows from that one answer.
Option A · Hub-and-spoke
YOU BUILD IT · YOU ROUTE IT
A hub VNet you create yourself, holding the shared services: Azure Firewall or an NVA, the VPN or ExpressRoute gateway, Bastion, DNS. Every workload VNet peers to it. You write the route tables that push traffic through the firewall — and you maintain them as the estate grows.
↔ scroll on mobile · moving dots show traffic direction
Microsoft says use it when
You're in a single region, or in multiple regions without needing transit between them. ExpressRoute is your main hybrid link and VPN connections stay under 100 per gateway. You depend on centralised NVAs and granular routing control.
What it costs you in effort
A peering pair and a route table per spoke. Firewall rules, gateway sizing and DNS forwarders are yours. Want transit between ExpressRoute and VPN gateways? That needs Azure Route Server — it doesn't happen on its own.
✓ full control over routing and inspection
✓ any NVA you like, configured your way
✓ cheaper at small scale — no hub fee
! route tables multiply with every spoke
! peering isn't transitive
! cross-region transit is manual work
Option B · Azure Virtual WAN
MICROSOFT BUILDS IT · THE FABRIC ROUTES
Same shape, different ownership. You create a virtual hub per region and Microsoft runs it. Spokes connect to the hub rather than peer through it, hubs mesh with each other automatically, and branches, ExpressRoute circuits and remote users all land on the same fabric.
↔ scroll on mobile · Standard SKU gives any-to-any connectivity by default
Microsoft says use it when
You need hub-and-spoke across more than two Azure regions, or global transit connectivity — any-to-any between VNets, branches, ExpressRoute and point-to-site users. The Basic SKU only does site-to-site VPN in a single hub, so in practice you'll want Standard.
What it saves you
Transit and hub-to-hub routing come built in. Branch onboarding is automated from SD-WAN devices, turning per-branch setup from hours into minutes. Gateway failover between ExpressRoute and VPN is handled by the fabric instead of hand-tuned BGP weights.
✓ transit routing you don't maintain
✓ scales cleanly past two regions
✓ built for many branches and tunnels
! hub fee applies whether it's busy or idle
! less low-level control
! custom NVAs only where supported
where it actually bites
Routing — not the picture, the maintenance
both force traffic through a firewall — one needs a route table per spoke, the other a single policy
This is the part people underestimate. With ten spokes, hand-managed route tables are fine. With eighty spokes across four regions they become a full-time job — and the place outages are born. If your estate is heading that way, the managed fabric is buying you something real.
one minute, six questions
Score your own environment
Answer for the estate you're designing for — today, and realistically in two years.
the dimensions that change your day
Side by side
| what | hub-and-spoke | Virtual WAN |
|---|---|---|
| Who runs the hub | You do | Microsoft |
| Transit between spokes | Route tables + firewall, per spoke | Built in |
| ExpressRoute ↔ VPN transit | Needs Azure Route Server | Native |
| Multi-region | Global peering, wired by you | Hub-to-hub, automatic |
| Many branches / SD-WAN | Manual per tunnel | Automated onboarding |
| NVA freedom | Anything you want | Supported partners in the hub |
| Cost shape | Pay per component you deploy | Hub fee + scale units, always on |
| Sweet spot | 1–2 regions, few tunnels, tight control | 3+ regions, many branches, scale |
learn these here, not in a change freeze
Five things that catch people out
🔁 Peering is not transitive
Two spokes peered to the same hub still can't reach each other. You need route tables pointing at the firewall — this surprises someone on every project.
🧾 The vWAN hub bills while it sleeps
A virtual hub costs money from the moment it exists, busy or not. For a two-region estate with light traffic, a self-built hub is often cheaper.
🧭 DNS is a separate design
Neither topology solves name resolution for you. Private DNS zones, resolvers and forwarders need planning either way — and it's where private endpoints usually break.
📈 Design for year two
One region and five spokes today is easy. Ask where the business will be in two years — extra regions and acquisitions are what break the small design.
🚚 It's not a life sentence — but moving isn't free
There's a documented migration path from a classic hub-and-spoke into Virtual WAN, and the landing zone IaC modules support both topologies. But migrating a live estate means re-pointing every spoke connection and re-testing every route. Choosing well now is much cheaper than choosing again later.
my take
Three questions, in this order
01
Count regions and branches
One or two regions and a handful of tunnels? Hub-and-spoke, every time. Three or more regions, or dozens of branches? The fabric earns its fee.
02
Ask who maintains it
A dedicated network team that wants control will be happy with route tables. A two-person platform team will drown in them.
03
Check the non-negotiables
A specific NVA, an unusual inspection requirement, or a compliance rule about traffic paths can settle the whole debate on its own.
📌 Still can't tell? Start with hub-and-spoke. It's cheaper to run, it teaches your team how the routing actually works, and there's a supported path into Virtual WAN when you outgrow it. The reverse journey is the painful one.
📚 Reference
CAF: traditional topology →
CAF: Virtual WAN topology →
Hub-spoke reference architecture →
Hub-spoke with Virtual WAN →
Networking design guide →
Diagrams drawn for this post using the official Microsoft Azure architecture icon set.
#Azure
#AzureNetworking
#VirtualWAN
#HubAndSpoke
#LandingZone
#CloudArchitect
#ExpressRoute
#CAF