To vWAN or Not to vWAN
Every Azure networking design workshop eventually hits the same question: do we go hub-spoke or vWAN? This post works through when each pattern earns its place, what the cost picture actually looks like, and the mistakes architects make going either direction.
Cloud Stack
May 29, 2026 · 15 min read
Why This Matters in 2026
Azure estates have grown. Multi-region is now the norm for anything customer-facing. SD-WAN rollouts have pushed branch connectivity up the agenda. Azure Firewall is in almost every design. And platform teams are being asked to do more with the same headcount, which means the question of how much networking complexity you own versus what you hand to Microsoft has real business weight behind it.
The answer is still "it depends" but there are clear signals pointing one way or the other. That's what this post works through.
What is Azure Hub & Spoke?
The concept is simple. A central hub VNet acts as the transit and shared services network. Spokes connect via VNet peering and host your workloads. Everything shared lives in the hub: Azure Firewall or an NVA, ExpressRoute and VPN gateways, DNS, Bastion, whatever your organisation treats as central infrastructure. All traffic between spokes, and all traffic to on-premises, flows through the hub.
It's the pattern that maps well to how most networking teams think. Central perimeter, shared services, controlled egress. It fits neatly with the CAF landing zone model. Network engineers who've come from on-premises backgrounds find it familiar. And because you own the route tables, you can do whatever you need with traffic flows.
- Complete control over routing
- Works with any NVA or firewall
- Highly customisable
- Familiar to network engineers
- Maps naturally to landing zone governance
- Predictable cost at small/medium scale
- Aligns well with CAF landing zones
- Operational overhead grows with scale
- VNet peering sprawl at 50+ VNets
- Multi-region routing complexity
- 30-60 min config per new VNet
- Manual UDR management across spokes
- Inter-hub peering requires care
Hub and spoke is not a legacy pattern. It's well understood, well documented, and works reliably. The issue is that it has a ceiling. A lot of organisations don't notice they've hit it until they're already dealing with the consequences: sprawling peering configurations, route tables that take half a day to reason through, and networking tickets that back up every time a new team wants a VNet.
What is Azure Virtual WAN?
Virtual WAN is Microsoft's managed networking service. Instead of building and running your own hub VNets, you deploy Virtual Hubs. Microsoft manages the hub infrastructure, the routing engine, and the backbone connectivity between hubs in different regions. You connect things to it: branches via VPN or SD-WAN, VNets via peering, on-premises via ExpressRoute.
The practical difference from hub-spoke is straightforward. In hub-spoke, you own the route tables. You decide how traffic flows, you update UDRs when things change, and you manage gateway capacity. In vWAN, the platform handles routing propagation automatically. Connect a VNet to a hub and its address space is learned by the hub router. No manual UDR update required. That sounds small. At 10 VNets it is small. At 80 VNets across three regions, it's a significant operational difference.
- Automated routing at scale
- Global transit via Microsoft backbone
- Native SD-WAN partner integrations
- Branch connectivity is first-class
- 50th VNet = same effort as the 1st
- Real operational simplicity at scale
- Less architectural flexibility
- NVA clustering constraints
- Cost model is less intuitive
- Data processing fees can surprise
- Not justified for smaller estates
- Steeper learning curve initially
Architecture Diagrams
Diagram 1: Hub & Spoke (UK South & UK West)
Hub & Spoke: UK South & UK West
Diagram 2: Azure Virtual WAN (UK South & UK West)
Azure Virtual WAN: UK South & UK West
Feature Comparison
When Hub & Spoke is the Better Choice
One or two regions, a sensible number of VNets, stable traffic patterns. Hub-spoke fits this well and typically costs less. vWAN's ~£136/month fixed hub fee (per region) exists whether you're passing 1GB of traffic or 1TB through it. Add a VPN scale unit at ~£196/month and you're already paying more than a hub-spoke equivalent before any data flows. At low scale the operational savings from vWAN don't come close to covering that difference.
Hub-spoke lets you do what you need with route tables. If you have inspection requirements that don't follow a clean hub-and-spoke flow, or traffic that needs to take unusual paths for compliance or legacy reasons, custom UDRs give you that control. vWAN's routing model is opinionated. That's fine when your requirements align with it. When they don't, the workarounds get messy.
This is a specific area where vWAN can catch teams out. Not every NVA architecture is compatible with the way vWAN handles routing. If you're running active-active NVA clusters with specific failover behaviour, check carefully before assuming vWAN will support it. Some vendors work well. Others require architecture changes you may not want to make.
This comes up a lot in brownfield reviews. The team has invested time in building a governed hub-spoke landing zone, it's running well, and someone in a design workshop suggests moving to vWAN. The question to ask is: what's the actual problem you're solving? If the answer is "nothing specific, vWAN is more modern", that's not a good enough reason. Migration has real cost and risk. Don't do it without a clear rationale.
Hub-spoke costs are easier to model. Gateway charges, peering costs, firewall SKU. If you know your traffic volumes and patterns, you can forecast reasonably accurately. vWAN billing is harder to reason about upfront, particularly if you have spoke-to-spoke or inter-region traffic. When budget predictability matters, hub-spoke is the safer choice.
When Azure Virtual WAN is the Better Choice
Managing inter-region connectivity in a custom hub-spoke setup requires inter-hub VNet peering, careful route propagation between regions, and ongoing maintenance every time something changes. It works, but it's manual and it accumulates technical debt. vWAN handles regional transit natively. The hubs route to each other automatically over Microsoft's backbone. That alone is a meaningful time saving in a four-region estate.
If you have 50 branches coming in via VPN, or you're rolling out an SD-WAN overlay and want Azure to be one of the connectivity endpoints, vWAN is the right fit. The SD-WAN partner integrations with vendors like Barracuda, Check Point, and Fortinet are mature. Onboarding a new branch site doesn't require a networking engineer to manually configure a tunnel and update route tables. That matters when you're dealing with volume.
The per-GB data cost for spoke-to-spoke traffic is similar in both models (roughly £0.030/GB when you include peering charges on both sides). What changes at scale is the management overhead, not necessarily the raw platform bill. The per-VNet configuration time in hub-spoke (typically 30 to 60 minutes including firewall rules, DNS, UDRs) adds up to real engineering hours. Whether that justifies vWAN's fixed hub costs depends on your team's bandwidth and the volume of VNet onboarding you're doing.
If a small platform team is responsible for network connectivity across 30 application teams, the routing automation in vWAN genuinely changes the workload. A new team requests a VNet, it gets connected to the hub, routing propagates automatically. Compare that to the hub-spoke equivalent where someone needs to create the peering, add the UDR, check the firewall policy, update DNS. None of those steps are hard. But collectively, across many teams, they consume disproportionate time.
If your WAN team is deploying SD-WAN and cloud connectivity is on the roadmap, vWAN integrates with the major SD-WAN vendors in a way that's hard to replicate cleanly in hub-spoke. You get a consistent connectivity model from branch to Azure rather than a custom VPN setup bolted onto the side of your hub.
Cost Considerations
Cost is where this decision gets complicated. Anyone who gives you precise annual totals comparing the two without knowing your traffic patterns, branch count, and gateway requirements is guessing. What I can give you are the actual Microsoft unit prices and the cost model logic, which is more useful than a fabricated comparison table.
All figures below are from Microsoft's Virtual WAN pricing documentation (updated January 2026), converted to GBP at the May 2026 rate of £0.74 per $1. Azure publishes separate local currency pricing, so always check the Azure pricing page for current GBP rates before modelling.
| Component | Hub & Spoke | Azure Virtual WAN |
|---|---|---|
| Hub fixed cost | No hub fee (you own the VNet) | ~£0.19/hr per hub (~£136/month) |
| VPN gateway (500 Mbps) | VpnGw1: ~£0.14/hr (~£103/month) | 1 S2S scale unit: ~£0.27/hr (~£196/month) |
| Per branch connection | Included in gateway SKU | ~£0.04/hr per branch (~£27/month) |
| ExpressRoute gateway (2 Gbps) | UltraPerformance: ~£0.51/hr | 1 ER scale unit: ~£0.31/hr (~£228/month) |
| Per ER circuit connection | Included in gateway | ~£0.04/hr per circuit (~£27/month) |
| Spoke-to-spoke (same region) | ~£0.007/GB x4 (both sides of both peerings) = ~£0.030/GB | ~£0.007/GB x2 (peering) + ~£0.015/GB (hub processing) = ~£0.030/GB |
| Spoke-to-branch (same hub) | ~£0.007/GB peering + outbound bandwidth | ~£0.007/GB peering only. No hub processing charge |
| Inter-region hub-to-hub | Global VNet Peering at both ends + inter-region bandwidth | ~£0.015/GB hub processing per hub + inter-region bandwidth charges |
Source: Microsoft Learn: About Virtual WAN pricing, updated January 2026. Converted from USD at £0.74/$1 (May 2026). Verify current GBP rates directly on Azure pricing pages.
What This Looks Like at Different Scales
These scenarios include both Azure infrastructure costs and engineering time, modelled at £50/hr. On raw Azure infrastructure alone, hub-spoke is cheaper at every scale. Engineering time is what shifts the comparison at scale. It's the number most teams leave out of their cost model.
Azure infrastructure + engineering time at £50/hr. Assumes Firewall Premium, ~10TB/month at 50 VNets, ~50TB/month at 200+ VNets, 3-5 regions. Engineering hours are the biggest variable. If your team runs leaner or your rate differs, the crossover point shifts. Treat as directional.
The hub deployment fee is vWAN's base overhead. Every Standard vWAN hub costs ~£0.19/hr whether it's passing traffic or not. That's roughly £136/month per region before you add gateways or process any data. Hub-spoke has no equivalent fixed charge. For a small single-region deployment with light branch connectivity, this difference alone is the main cost driver.
Spoke-to-spoke variable costs are the same in both models. This surprises people. In hub-spoke, spoke-to-spoke traffic crosses two peering connections (both sides of each), totalling ~£0.030/GB. In vWAN, you pay ~£0.015/GB hub data processing plus ~£0.015/GB peering, also ~£0.030/GB. The per-GB cost is identical. What differs is the fixed infrastructure cost underneath it.
Branch connectivity is where the cost structures diverge most visibly. A single-branch VPN in hub-spoke (VpnGw1) costs around £103/month. The equivalent vWAN S2S scale unit costs ~£196/month plus ~£27/month per branch connection. For one or two branches, hub-spoke is clearly cheaper on the Azure bill. For 50 branches, vWAN's per-connection model becomes more competitive, and the operational overhead of managing individual VPN configurations at that volume in hub-spoke is significant.
Inter-region traffic adds up in both models. Sending data between UK South and UK West triggers inter-region bandwidth charges regardless of topology. In vWAN, you additionally pay ~£0.015/GB hub data processing at each hub the traffic crosses. That makes high-volume cross-region spoke-to-spoke traffic noticeably more expensive in vWAN than a direct Global VNet Peering connection between hubs.
vWAN inter-region spoke-to-spoke incurs ~£0.015/GB hub processing per hub crossed, on top of standard inter-region bandwidth charges. At high east-west volumes between UK South and UK West, model this before you commit.
Common Mistakes
"We should be on vWAN, it's what Microsoft is investing in" is something I hear regularly. It's not a bad observation, but it's not an architecture decision either. vWAN suits specific situations well. In others, you're paying more for a platform that constrains you without giving anything back. Start with your requirements, not with the product.
The opposite is just as common and probably more costly. A team running five regions and 120 VNets through a hub-spoke topology they designed three years ago for a quarter of that scale. The signs are usually visible: peering configurations no one fully understands, routing changes that take days to implement safely, network engineers who spend most of their time on connectivity tickets rather than anything strategic.
A spreadsheet comparing Azure resource costs between hub-spoke and vWAN is a starting point, not the answer. If your team is spending 20 hours a month managing routing configuration in a large hub-spoke setup, that's real cost. It just doesn't appear on the Azure bill. Factor it in honestly.
Hub-spoke routing is simple when you set it up. It gets complicated incrementally, and the complexity rarely announces itself until it's already accumulated. Each new region, each workload with unusual routing requirements, each shared service that needs to be reachable from multiple spokes adds a little more. Model what the architecture looks like at 2x or 3x your current scale before committing.
The virtual hub data processing charge (~£0.015/GB per hub crossed) is easy to miss when scoping a vWAN design. If you have significant inter-region traffic between UK South and UK West, it adds up. I've seen it come as a genuine surprise post-deployment. Price it before you commit.
Running hub-spoke and vWAN in parallel for longer than necessary creates a networking topology that is harder to reason about than either option on its own. If you're moving to vWAN, define the target state clearly and migrate to it. Don't let the transition become the steady state.
Final Thoughts
Neither of these is the wrong answer in absolute terms. Hub-spoke is not outdated. vWAN is not automatically better. They're different tools with different strengths, and the choice genuinely depends on your specific situation.
If you're in one or two regions with a manageable VNet count and a team comfortable running network configuration, hub-spoke is probably the right call. Keep it well governed, consider Azure Virtual Network Manager to reduce the manual overhead, and revisit the topology decision as you grow.
If you're running multiple regions, connecting branches at scale, or managing a large number of VNets with a small platform team, the case for vWAN is real. The routing automation and the inter-region transit are genuinely useful at that scale, and the cost position improves as the estate grows.
The mistake most teams make isn't picking the wrong pattern initially. It's not going back to question the decision as the environment evolves. The architecture that was right for 15 VNets in a single region is often not the right architecture for 100 VNets across four regions and 40 branch sites. Treat the networking topology as something to review periodically, not something you set once and leave.