Hub-and-Spoke vs Azure Virtual WAN: Which Network
Architecture Wins for Modern Enterprise Deployments?
Neither topology is wrong, and neither is universally right — which is exactly why so many teams pick one based on which blog post they read first rather than which one actually fits their region count, their routing complexity, and their appetite for owning the plumbing. This is the comparison with the real numbers: what each one actually costs per hour, where each one actually breaks under scale, and the specific decision points that should move you off the default.
The question "hub-and-spoke or Virtual WAN" gets asked constantly and answered lazily just as often — usually with whichever one the person asking has personally operated, presented as if it were the objectively correct default. It isn't. Hub-and-spoke is a pattern: you build the hub VNet, you deploy the gateways and firewall into it, you peer every spoke to it, and you write and maintain the routing yourself. Virtual WAN is a managed service: Microsoft operates the hub router, the mesh between regional hubs, and a meaningful slice of the routing logic, and you consume it through configuration rather than construction. Both connect the same spokes to the same shared services. They differ in who owns the plumbing, what that ownership costs in dollars and operational effort, and — critically — where each one's design assumptions start to strain as your region count, connection count, and routing complexity grow past what either one was comfortable with at the size you started. This comparison works through the real cost structure, the real scalability ceilings, and the real decision points, not a generic "it depends."
Both topologies exist to answer an identical architectural question: how do dozens or hundreds of workload VNets reach each other, reach on-premises networks, and reach the internet, through a small number of centrally-managed chokepoints rather than a chaotic full mesh of ad hoc peerings. Where they diverge is ownership.
| Dimension | Hub-and-Spoke | Virtual WAN |
|---|---|---|
| Who builds the hub | You — a VNet you provision and configure | Microsoft — a managed virtual hub router |
| Who writes the routing | You — route tables, UDRs, BGP if applicable | Largely automatic, tunable via Routing Intent |
| Multi-region mesh | Manual — you design hub-to-hub connectivity | Automatic — Standard Virtual WAN fully meshes regional hubs |
| Billing model | Pay for the resources you deploy (gateway SKU, firewall, peering) | Per-hub base fee, plus scale units, plus data processing |
| Operational control | Full — you can customize anything | Bounded by what the managed service exposes |
Neither row in that table is a strict improvement over the other — "you can customize anything" is a feature when you have specific requirements the managed service doesn't support, and a liability when it means your team is maintaining routing logic that a managed service would have handled correctly by default.
Hub-and-spoke is the original, foundational Azure network topology — a central hub VNet holding shared services, with workload VNets ("spokes") peered to it individually. It predates Virtual WAN and remains the pattern most Azure networking documentation, training, and existing production environments are built around.
- Everything in the hub is a resource you provision. VPN Gateway or ExpressRoute Gateway for on-premises connectivity, Azure Firewall (or a third-party NVA) for inspection and egress filtering, Azure Bastion for secure VM access, and Private DNS Zones for name resolution.
- Spokes connect via VNet peering. Each spoke peers directly to the hub. Spoke-to-spoke traffic typically routes through the hub via user-defined routes (UDRs), not direct spoke-to-spoke peering, so the firewall can inspect it.
- Routing is explicit and manual. You write UDRs that force traffic destined for other spokes or on-premises networks through the hub's firewall or gateway, rather than taking a direct path.
- Multi-region requires deliberate design. There's no automatic mesh between regional hubs — if you need transitive connectivity between a hub in East US and a hub in West Europe, you design and build that connectivity yourself, commonly via ExpressRoute or a Global VNet Peering-based approach.
Hub-and-spoke remains Microsoft's recommended default in the Cloud Adoption Framework's landing zone reference architecture, and it's what most organizations already have in production if they built their Azure footprint before Virtual WAN matured or chose the more familiar, well-documented pattern deliberately. A large existing base of hub-and-spoke knowledge, tooling, and operational experience is itself a real factor in the decision — not just a technical one.
Azure Virtual WAN is a managed networking service that centralizes and simplifies large-scale connectivity across VNets, on-premises sites, and remote users, without you manually stitching together dozens or hundreds of peerings, gateways, and custom routes. Technically, a Virtual WAN resource is a global container; within it you deploy regional Virtual Hubs, each containing a Microsoft-managed router plus optional gateways.
- The virtual hub router is Microsoft-managed. You don't provision or patch it — you configure connections and let Azure operate the underlying routing infrastructure.
- Standard Virtual WAN fully meshes regional hubs automatically. Deploy hubs in multiple regions and Virtual WAN connects them via Microsoft's global backbone without you designing hub-to-hub connectivity yourself.
- Routing infrastructure units (RIUs) govern throughput and capacity. A virtual hub defaults to 2 RIUs; each additional unit adds roughly 1 Gbps of throughput and support for 1,000 more connected VMs.
- A secured virtual hub integrates Azure Firewall natively. Rather than deploying and wiring up a firewall yourself in a hub VNet, a secured hub adds Azure Firewall (or a supported NVA) as a first-class, managed component of the hub.
- Autoscaling responds to load, within limits. The hub router autoscales based on spoke VM utilization and processed data, though scaling isn't instantaneous — provisioning the correct minimum RIUs for known baseline load remains important for consistent performance.
Once a virtual hub is created, Virtual WAN hub pricing applies immediately — the $0.25/hour base fee starts regardless of whether you've attached a VPN gateway, ExpressRoute gateway, or any VNet connections yet. Creating an empty hub takes roughly 5-7 minutes; creating a hub with a gateway attached at the same time can take around 30 minutes. Factor this into both cost planning and deployment-time expectations before you provision hubs speculatively "for later."
Cost comparisons between the two topologies are frequently vague — "Virtual WAN costs more" or "hub-and-spoke is cheaper" without the underlying numbers. Here are the actual, current, documented figures.
| Virtual WAN cost component | Rate | Notes |
|---|---|---|
| Virtual hub base fee | $0.25/hour | Per hub, from creation, whether or not gateways are attached |
| Hub router data processing | Per-GB, varies by scenario | Applies to VNet-to-VNet transit through the hub; does NOT apply to branch-to-branch or VNet-to-branch via the same hub |
| VPN S2S Scale Unit | ~$0.261/hour example | Aggregate branch connection speed, scalable up to 20 Gbps |
| VPN S2S Connection Unit | ~$0.05/hour example | Per branch site connected; supports up to 1,000 connections per region |
| NVA Infrastructure Unit (secured hub) | $0.25/hour | Additional to the hub base fee — a secured hub with firewall runs roughly $0.50/hour combined, before data and marketplace NVA licensing |
| Additional routing infrastructure units | Scale-unit priced | Beyond the default 2 RIUs, priced per additional unit — check current rates for your region |
Hub-and-spoke has no equivalent "platform fee" line item — you're billed only for the resources you deploy: the VPN Gateway or ExpressRoute Gateway SKU you choose, Azure Firewall (Standard or Premium) at its own hourly rate plus data processing, and VNet peering charges (both directions, per GB). The absence of a base platform fee is real, but it's not the same as "free" — it shifts cost from a predictable per-hub line item to the sum of whatever resources your specific hub design requires, plus the engineering time to design, build, and maintain that configuration correctly.
| Cost dimension | Hub-and-Spoke | Virtual WAN |
|---|---|---|
| Base platform fee | None | $0.25/hr per hub (scales with region count) |
| Gateway costs | You choose and pay for the SKU directly | Scale-unit priced, separately from the hub base fee |
| Firewall costs | Azure Firewall or NVA, deployed and billed independently | Secured hub adds NVA Infrastructure Unit on top of hub fee |
| Multi-region cost driver | Linear with however many hubs you build — plus hub-to-hub connectivity you design | Linear with hub count — but mesh connectivity is included, not separately engineered |
| Hidden cost | Engineering time to design, build, and maintain routing correctly | Paying for managed capacity (RIUs) you may be over-provisioning "just in case" |
A narrow Azure-bill comparison undersells hub-and-spoke's true cost and oversells Virtual WAN's. Hub-and-spoke's "no platform fee" looks cheaper on a monthly invoice, but every hour spent designing UDRs, debugging asymmetric routing, and building hub-to-hub mesh for a second region is real engineering cost that doesn't appear on the Azure bill at all. Virtual WAN's per-hub fee is a visible, budgetable cost precisely because it's paying for work — routing logic, mesh connectivity, autoscaling — your team would otherwise be doing manually. For an accurate comparison, weigh the Azure invoice against the engineering hours each topology actually requires at your organization's scale.
Both topologies scale — the question is what specifically has to change as you grow, and where the hard limits sit.
| Scale dimension | Hub-and-Spoke | Virtual WAN |
|---|---|---|
| Adding spokes within a region | Linear effort — new peering + UDR per spoke | Simpler — connect the VNet to the hub; routing largely automatic |
| Adding a new region | Build a new, largely independent hub; design hub-to-hub connectivity yourself | Add a new virtual hub; auto-meshes with existing hubs on Standard Virtual WAN |
| Throughput scaling | Manually resize gateway SKU or firewall tier as needed | Routing infrastructure units, autoscaling within provisioned minimums |
| Route table limits | Governed by standard Azure VNet/UDR limits | Hard ceiling: 10,000 routes accepted per hub, regardless of RIU count |
| Single-flow throughput | Governed by gateway/firewall SKU limits | Performance degradation above 1.5 Gbps in a single TCP flow, regardless of RIU count |
| Remote user scale | VPN Gateway P2S connection limits, SKU-dependent | Up to 100,000 users supported per hub for Point-to-Site scenarios |
Two specific Virtual WAN limits deserve attention before you assume more RIUs solves every scale problem. First, a virtual hub accepts a maximum of 10,000 routes from connected resources — virtual networks, branches, and other hubs combined — no matter how much routing capacity you provision; large, highly-segmented environments with many small VNets can approach this ceiling faster than raw throughput would suggest. Second, a single TCP flow can experience performance degradation above roughly 1.5 Gbps regardless of the hub's total provisioned capacity, because that ceiling is a property of single-flow processing, not aggregate router throughput. Neither limit is exotic to hit at genuine enterprise scale — model both explicitly rather than assuming "add more RIUs" is a universal answer.
Hub-and-spoke doesn't have an equivalent hard platform ceiling in the same way — its practical scaling limit is usually how much manual routing complexity a team can correctly maintain before mistakes creep in. A hub-and-spoke environment with dozens of spokes and hand-written UDRs is technically capable of scaling further, but the operational risk of a routing misconfiguration rises with every spoke added by a team relying on manual processes rather than the kind of managed routing intent Virtual WAN provides by default.
Both topologies can achieve equivalent security postures — centralized inspection, consistent egress filtering, segmented traffic — but the mechanics of how firewall placement and segmentation are configured differ meaningfully.
| Security aspect | Hub-and-Spoke | Virtual WAN |
|---|---|---|
| Firewall deployment | You deploy Azure Firewall (or an NVA) into the hub VNet directly and wire it into routing manually | A "secured hub" integrates Azure Firewall as a native, managed component |
| Forcing traffic through inspection | UDRs on every spoke, written and maintained by you | Routing Intent — declare that internet and/or private traffic should route through the firewall; Azure handles the route propagation |
| Segmentation between environments | Separate hubs, separate route tables, or NSGs at the spoke level | Route tables associated with specific hub connections, enabling segmentation without a full separate hub |
| Third-party NVA support | Full flexibility — deploy any supported NVA into the hub as you see fit | Supported via NVA Infrastructure Units in a secured hub, with marketplace licensing on top |
| Consistency across regions | You must replicate firewall rules and routing design per hub manually | More consistent by default — the same Routing Intent pattern applies per hub with less duplication risk |
The most common hub-and-spoke security gap in practice isn't a missing firewall rule — it's a spoke that was added without the correct UDR forcing its traffic through the hub firewall, leaving it able to reach the internet or other spokes directly. This is a configuration-discipline problem, not an architectural flaw, but it's a real and recurring one precisely because nothing in hub-and-spoke's design prevents a new spoke from being peered without matching routing being applied. Virtual WAN's Routing Intent model reduces this specific risk by making "route this traffic through the firewall" a declared hub-level setting rather than a per-spoke UDR someone has to remember to write correctly every time.
Routing is where the operational-effort difference between the two topologies is most concrete and most often underestimated during initial architecture decisions.
| Routing task | Hub-and-Spoke effort | Virtual WAN effort |
|---|---|---|
| Force spoke traffic through firewall | Write and associate a UDR per spoke subnet | Declare Routing Intent once at the hub level |
| Enable spoke-to-spoke transitivity | UDRs routing through the hub, or direct peering (bypassing inspection) | Automatic, transitive by default through the hub router |
| Enable cross-region transitivity | Design and build hub-to-hub connectivity yourself | Automatic via Standard Virtual WAN's full mesh |
| Troubleshoot asymmetric routing | Manual review of every relevant UDR and route table | Centralized effective-route views in the Virtual WAN hub |
| Onboard a new spoke correctly | Requires the operator to remember every routing convention | Largely inherits correct behavior from hub configuration automatically |
Routing Intent — the Virtual WAN capability to declare, at the hub level, that internet-bound and/or private (inter-VNet, branch) traffic should route through a secured hub's firewall — replaces what would otherwise be dozens or hundreds of hand-written UDRs in a comparable hub-and-spoke design. For organizations whose primary hub-and-spoke pain point is routing complexity specifically (not cost, not multi-region mesh), Routing Intent alone is often the deciding factor in a Virtual WAN migration, independent of the other comparison dimensions in this guide.
"Which one wins" depends entirely on which of these questions describes your actual situation — not a universal ranking.
| Your situation | Points toward |
|---|---|
| Single region, small number of spokes, team comfortable owning routing | Hub-and-spoke — the per-hub platform fee buys you little at this scale |
| Multiple regions needing transitive connectivity between them | Virtual WAN — automatic mesh replaces significant manual engineering |
| Many branch offices or SD-WAN partner connections | Virtual WAN — built specifically for this connectivity pattern at scale |
| Strict requirement for full customization of every network component | Hub-and-spoke — you're not bounded by what a managed service exposes |
| Team has deep hub-and-spoke operational experience, little Virtual WAN exposure | Hub-and-spoke, at least short-term — factor retraining cost into any migration decision |
| Routing complexity (UDR sprawl, asymmetric routing bugs) is your primary pain point today | Virtual WAN — Routing Intent directly addresses this |
| Existing Azure Landing Zone deployment already on hub-and-spoke, working fine | Stay — migrating a working topology for its own sake is rarely justified |
Virtual WAN is the newer service, and newer sometimes gets read as "better" by default — but the comparison in this guide shows real trade-offs in both directions, not a strict improvement. A single-region deployment with a handful of spokes gains little from Virtual WAN's multi-region mesh capability while still paying its per-hub fee and giving up some direct control. The genuinely correct framing is: Virtual WAN wins specifically when its managed-mesh and Routing-Intent capabilities solve a real problem you have; hub-and-spoke wins specifically when your scale doesn't yet justify that platform fee and your team already owns the routing competently.
A structured way to reach a defensible decision — or a defensible decision to stay put — rather than choosing based on which topology is more discussed this year.
Inventory your actual current pain points, not hypothetical future ones
List concrete, specific problems: "we've had two incidents from asymmetric UDR misconfiguration," "adding a new region took six weeks of manual hub design," "our Azure bill has no line item we can attribute to network platform overhead." Vague dissatisfaction ("hub-and-spoke feels old") isn't a decision input.
Model the real cost of each option at your actual scale
Using this guide's verified pricing components (hub base fee, RIU scale units, gateway/firewall costs on the hub-and-spoke side), build a genuine monthly estimate for both topologies at your current region count and projected growth — not a generic industry comparison.
Estimate the engineering hours each option requires, honestly
For hub-and-spoke: hours to design, build, test, and maintain UDRs and hub-to-hub connectivity for your actual region count. For Virtual WAN: hours to learn the service, migrate existing routing logic, and validate Routing Intent behavior matches your security requirements. Neither number is zero — compare them honestly rather than assuming the managed service is free of effort.
If migrating, pilot in a non-production environment first
Build a parallel Virtual WAN deployment for a single region and a subset of non-critical spokes. Validate routing behavior, firewall inspection, and failover characteristics match your requirements before committing to a full migration.
Plan the cutover as a phased migration, not a big-bang switch
Migrate spokes region by region or workload-tier by workload-tier, validating connectivity and security posture at each stage, rather than attempting to move an entire multi-region hub-and-spoke estate to Virtual WAN in a single maintenance window.
Document the decision and its reasoning, regardless of outcome
Whether you migrate or stay, write down why — the specific pain points, the cost model, the engineering-hour estimate. This becomes the reference the next architect reaches for instead of re-litigating the same comparison from scratch in two years.
Getting this decision wrong doesn't always look the same — it fails differently depending on which direction the mistake runs.
| Anti-pattern | Why it feels right | Why it isn't |
|---|---|---|
| Deploying Virtual WAN for a single-region, small-footprint environment | "It's the modern, recommended path" | Pays the per-hub platform fee and accepts reduced customization for multi-region mesh capability you're not using |
| Staying on hub-and-spoke purely out of familiarity as regions multiply | "We know how to operate this" | Manual hub-to-hub design effort compounds with every new region — familiarity doesn't reduce the actual engineering hours required |
| Migrating to Virtual WAN without validating Routing Intent against existing security requirements | "It's a managed service, it must handle this correctly" | Routing Intent's default behavior may not match bespoke inspection rules a custom hub-and-spoke firewall configuration was enforcing — validate explicitly, don't assume equivalence |
| Provisioning far more RIUs than current load requires "to be safe" | "More capacity avoids future scaling pain" | Paying for unused scale-unit capacity indefinitely, when autoscaling (tuned to a reasonable minimum) would track actual load more cost-effectively |
| Treating cost comparison as Azure-bill-only | "The invoice is the objective number" | Ignores engineering-hour cost entirely, systematically favoring hub-and-spoke's "no platform fee" over its real operational overhead |
| Big-bang migration of an entire multi-region estate in one maintenance window | "Faster to just do it all at once" | A single mistake in Routing Intent configuration or connection setup can take down connectivity across every region simultaneously — phase it |
Key Takeaways
Frequently Asked Questions
Related FAVRITE Articles
- How to Design Azure Landing Zones: The Enterprise Architecture Blueprint
- Azure Front Door Wildcard Revalidation Fix
- Azure Availability Set vs Availability Zone: The Complete Guide
- Microsoft Defender for Cloud: A Practical Guide