Azure Virtual WAN vs. Hub-Spoke: Making the Right Call at Scale
- peterrivera813
- Apr 5
- 5 min read
There's a version of this conversation that goes badly. An architecture review board sees "Virtual WAN" in a vendor slide, assumes it's the modern default, and greenlights a migration without asking the questions that actually matter. Six months later, the team is debugging Secured Virtual Hub routing behavior at 2am and wondering how the "simplified" option got this complicated.
This post is for those who want the honest version of the trade-off — not the feature comparison table, but the real decision criteria that determine which topology you'll regret choosing.
The Core Misunderstanding
Most architecture conversations frame this as a generational choice — hub-spoke is the legacy approach, Virtual WAN is the modern replacement. That framing is wrong, and it leads teams into decisions they later regret. Virtual WAN doesn't eliminate network complexity. It redistributes it. Hub-spoke places complexity in layers your team already knows how to manage — User Defined Routes, VNet peering, NVA configuration, Azure Firewall policy. Those constructs are explicit, well-documented, and debuggable by any experienced Azure network engineer. Virtual WAN replaces them with a different set of abstractions — routing tables, propagation rules, association configurations, and Secured Virtual Hub behavior — that are less familiar, harder to reason about under pressure, and partially managed by Microsoft, which narrows your investigation toolkit when something breaks. The teams that struggle most with VWAN aren't the ones that chose it for the wrong reasons — they're the ones that chose it without fully accounting for where the complexity went. Before you commit to either topology, the right question isn't "which is newer?" It's "which complexity can my team own?"
When Hub-Spoke Is Still the Right Answer
Virtual WAN gets most of the attention in architecture conversations these days, and for good reason — at scale, its routing automation and any-to-any connectivity are genuinely compelling. But compelling isn't the same as correct for your environment. Before you greenlight a VWAN deployment, there are conditions where hub-spoke remains the stronger architectural choice — and getting this wrong means rebuilding your network topology mid-project.
You have a third-party NVA requirement Palo Alto, Fortinet, Check Point — VWAN Standard supports some NVA deployments in the hub, but feature parity is incomplete and the integration topology is messy. Teams often end up with a hybrid workaround that negates VWAN's routing simplicity. Validate your vendor's VWAN support before you commit.
You need deterministic, auditable routing UDRs are explicit — you can read a route table and reason about every traffic path. VWAN routing tables (defaultRouteTable, noneRouteTable), propagation, and association rules are powerful but hard to debug under pressure. If routing transparency matters to your ops team, hub-spoke wins.
You're operating at smaller scale Under ~50 spokes, single region, no branch offices — hub-spoke is lower cost and lower risk. VWAN Standard hub runs ~$1.25/hour before data processing charges. At small scale, that's real cost with limited benefit.
You're running custom routing topologies Asymmetric paths, multi-exit internet breakout, specific inspection flows — hub-spoke lets you express these precisely. VWAN's abstracted routing model makes non-standard topologies harder to implement and verify.
Your team doesn't have VWAN fluency yet Debugging hub-spoke at 2am means reading UDRs you wrote yourself. Debugging VWAN means reasoning through Microsoft-managed plumbing your team may not fully own. Build VWAN expertise deliberately, not under incident conditions.
When Virtual WAN Earns Its Place
You're multi-region with cross-region traffic VWAN handles inter-hub routing automatically — spokes in one region talking to spokes in another without manual BGP configuration or hairpinning through on-premises. This is genuinely difficult to replicate cleanly in hub-spoke at scale.
You have many branches or SD-WAN in scope Managing ExpressRoute + S2S VPN coexistence in hub-spoke requires careful BGP work and ongoing maintenance. VWAN abstracts this. Its SD-WAN partner integrations (Barracuda, select NVA partners) make branch connectivity significantly more scalable across dozens or hundreds of sites.
Your spoke count is large or growing fast Past ~150 spokes, hub-spoke becomes an operational tax — peering costs compound, route table management gets fragile, and any-to-any connectivity requires UDR discipline across every spoke. VWAN handles this natively.
Your team wants Microsoft to own routing complexity Legitimate for organizations where networking bandwidth is constrained. VWAN reduces configuration surface area, which matters when your team is managing a large environment with limited headcount.
The Secured Virtual Hub: Know This Before You Design
Deploying a firewall inside a VWAN hub creates a Secured Virtual Hub — and on paper, it looks like a clean solution. One hub, one firewall, traffic inspection handled centrally. In practice, it's where most VWAN deployments run into unexpected friction. Whether you're running Azure Firewall natively or integrating a third-party firewall like Palo Alto, Fortinet, or Check Point, the routing behavior rarely works exactly the way the team assumed it would — and the gaps almost always surface in production.
Routing intent isn't obvious — East-west, internet, and branch-to-spoke traffic are each independently routable through the firewall, but the default behavior often doesn't match team assumptions. Teams discover this in production.
New spokes require propagation rule updates — Easy to miss in a runbook, costly to diagnose when a spoke can't reach the firewall.
Debugging is harder — The underlying routing plumbing is Microsoft-managed, so your investigation toolkit is narrower than in hub-spoke.
Recommendation: Build a lab environment and deliberately break Secured Virtual Hub routing before you design for production. It's the fastest way to build real fluency.
Migration Reality Check
If you're already on hub-spoke, migration to VWAN is non-trivial:
Parallel infrastructure required — You can't lift-and-shift; you build VWAN alongside existing hub-spoke
Potential re-IP — In some topologies, address space conflicts forces address space reallocation
BGP cutover coordination — On-premises BGP failover during cutover requires careful planning and a hard maintenance window
No zero-downtime path — There's no blue-green option here. When you cut over, you're moving the network layer everything else runs on — and that window carries real risk.
Migrating from hub-spoke to VWAN is a network rebuild, not a reconfiguration. Plan for parallel infrastructure, a hard cutover window, and significant coordination across teams. If you're greenfield, this doesn't apply — but if you're already running hub-spoke in production, treat migration as its own project, not an afterthought.
Decision Framework
Every environment is different, but the right topology choice usually comes down to the same five or six questions. Use this framework as a starting point and if your answers land consistently in one column, that's your answer.
Question | Hub-Spoke | Virtual WAN |
Spoke count now / in 24 months | < 150 | 150+ |
Regions | Single/Multi-Region | Multi-Region/Global |
Third-party NVA required | Yes or Azure Firewall | Azure Firewall or VWAN-supported NVA |
Branch offices / SD-WAN | No | Yes |
Routing transparency needed | Explicit routing ownership | Accepts managed routing |
Greenfield or migration | Either | Greenfield preferred |
Bottom Line
For greenfield, multi-region, branch-heavy environments with no hard NVA constraints, Virtual WAN stands out—abstracting routing through automation while enabling any-to-any connectivity at scale to address real-world complexity. For everything else, particularly organizations with NVA dependencies, complex custom routing, or teams that prioritize routing transparency and auditability: Hub-spoke introduces deliberate complexity, but in return provides explicit routing control, observable traffic patterns, and a more tangible learning curve for engineering teams than Virtual WAN’s managed abstractions.
The worst outcome is choosing VWAN because it feels like the modern answer and discovering mid-deployment that your NVA integration doesn't work the way you expected, or that debugging a routing issue under pressure requires expertise your team hasn't built. Architecture decisions that optimize for vendor slides rather than operational reality always cost more than they save.
The right topology isn't the one that looks best in a design review — it's the one your team can diagnose, recover, and own when something breaks in production.
Comments