Azure Virtual WAN vs Hub-and-Spoke for Your Landing Zone

Choose a traditional hub-and-spoke topology when your workloads live in one or a few Azure regions, you need fewer than 30 site-to-site IPSec tunnels, and you want full control of routing. Choose Azure Virtual WAN when you need global any-to-any connectivity across many regions, more than 30 branch sites, SD-WAN integration, or transitive routing between VPN and ExpressRoute, and you are willing to let Microsoft own the routing plane. The decision is really about operational ownership and scale, not raw capability, and it is hard to reverse once workloads land.

This is the first networking choice in an Azure landing zone, and it sits directly under every migration you will run afterwards. Get it wrong and you are re-IP-ing or re-peering production VNets later. Here is what each option actually is, what to check before you commit, and the cost that shows up months after the diagram looks finished.

Azure Virtual WAN vs hub-and-spoke: the decision criteria

Microsoft documents a reasonably clean split between the two topologies, and it is worth reading literally rather than by vibe.

Use Virtual WAN when any of these hold. Your organisation deploys across several Azure regions and needs global connectivity between VNets in those regions and multiple on-premises locations. You run an SD-WAN deployment or need more than 30 branch sites for native IPSec termination. Or you need transitive routing between a VPN and ExpressRoute, for example connecting a site-to-site VPN branch to an ExpressRoute-connected datacentre through Azure.

Use a traditional hub-and-spoke when you deploy across one or a few regions, you expect some cross-region traffic but not a full mesh, you have fewer than 30 IPSec site-to-site tunnels, and you want to manually configure and fully control routing and security.

The honest reading: Virtual WAN is Microsoft's managed answer to global scale and branch sprawl. Traditional hub-and-spoke is the answer when you want the routing table to be yours and your footprint is contained. Most mid-size companies running a handful of production workloads in one or two regions do not have the branch count that forces Virtual WAN, so the real question becomes how much routing you want to own.

What to check before you change anything

Do not pick a topology from a whiteboard. Four things decide the answer for you, and all of them are cheaper to check now than to unwind later.

Count your real connectivity endpoints

How many on-premises sites terminate IPSec tunnels into Azure today, and how many will in two years? If you are under 30 and not growing a branch estate, the branch-count argument for Virtual WAN disappears. If you already run a large SD-WAN or retail-style branch network, it points the other way.

Map your region plan honestly

A single-region or dual-region footprint does not need Virtual WAN's global transit. VNet peering is the preferred way to connect VNets in the same region, across regions, and across tenants, and it carries hub-and-spoke fine at that scale. Plan for where you will be, not where you are, but do not buy global transit for a two-region estate.

Settle transitive routing early

This is the detail that catches teams. VNet peering and global VNet peering are not transitive. Spoke A peered to the hub and spoke B peered to the hub cannot talk to each other through the hub unless you add user-defined routes and a network virtual appliance, such as Azure Firewall, in the hub to forward the traffic. If you need spoke-to-spoke or VPN-to-ExpressRoute transit, you are either building and owning that routing yourself in a traditional hub, or letting Virtual WAN do it.

Fix your IP address plan before anything peers

Overlapping address space is the one mistake that no topology forgives. Peering requires non-overlapping ranges, and re-IP-ing a production spoke after migration is a change-freeze-level event. Allocate hub and spoke ranges, leave room for the gateway and firewall subnets, and write it down before the first VNet exists.

If you are standing this up as the foundation for an on-premises exit, the connectivity layer is the critical dependency, and it is worth planning alongside the on-premises to cloud cutover rather than after it.

Traditional hub-and-spoke: what you actually build

In a traditional hub, you own a hub VNet that holds shared services, peered to spoke VNets that hold workloads. The hub is where hybrid connectivity and inspection live.

The hub subnets have reserved names and minimum sizes that you cannot fudge. The hub-and-spoke design guide lays them out:

The piece that pays for itself is gateway transit. With gateway transit, all spokes share a single VPN or ExpressRoute gateway you deploy in the hub. Without it, every spoke needs its own gateway to reach on-premises, which is expensive and operationally miserable. Gateway transit is what makes the hub-and-spoke model worth building.

Because peering is not transitive, routing is your job. To force spoke traffic through the firewall for inspection or spoke-to-spoke transit, you attach a user-defined route to the spoke subnet with a next hop of the firewall's private IP:

{
  "name": "to-hub-firewall",
  "properties": {
    "routes": [
      {
        "name": "default-via-firewall",
        "properties": {
          "addressPrefix": "0.0.0.0/0",
          "nextHopType": "VirtualAppliance",
          "nextHopIpAddress": "10.0.1.4"
        }
      }
    ]
  }
}

That control is the point of the traditional model. You decide exactly what hairpins through the firewall and what does not. The cost is that you maintain those route tables, and every new spoke or on-premises prefix is a routing change you own.

Virtual WAN: what Microsoft manages and what you give up

Virtual WAN is a Microsoft-managed service that provides global, dynamic, and transitive connectivity across regions and on-premises. The hub is no longer a VNet you own, it is a managed hub. It gives you any-to-any paths out of the box: VNet to VNet, VNet to branch, branch to VNet, and branch to branch, within and across regions, including the transitive routing that a traditional hub needs UDRs and an NVA to achieve.

The constraint is the trade. A Virtual WAN hub only hosts Microsoft-managed resources: the VPN and ExpressRoute gateways, Azure Firewall, and supported NVA or SaaS solutions. You do not drop an arbitrary appliance into the hub VNet the way you would in a traditional design, because there is no hub VNet you own.

Security steering is done through routing intent rather than hand-written route tables. When you configure a private traffic routing policy, all branch and VNet traffic including inter-hub traffic is forwarded to the next hop Azure Firewall, NVA, or SaaS solution. You can set a separate internet routing policy with a different next hop. It is cleaner than maintaining UDRs on every spoke, but it is also coarser: routing intent applies broadly rather than per-subnet, and you accept Microsoft's routing behaviour instead of defining your own.

The trade-off and what it costs later

The two models are not equally reversible. Peering, UDRs, and gateways in a traditional hub are resources you can refactor in place. Moving an estate from a traditional hub to Virtual WAN, or the reverse, means re-homing spoke connections, re-doing the inspection path, and retesting every on-premises route. That is why the branch count and region plan matter now rather than at review time.

The quieter cost is routing ownership. A traditional hub hands you full control and hands you full responsibility: every transitive path is a UDR plus an NVA you maintain. Virtual WAN removes that maintenance and removes that control, and when traffic takes a path you did not expect, you are debugging a managed routing plane instead of your own route tables. Neither is strictly better. Pick the one whose failure mode you would rather operate at 3am.

One rule holds in both: put hybrid connectivity in first. Setting up the VPN or ExpressRoute gateway is the dependency every migrated workload sits on, so it belongs in the design before workloads arrive, not bolted on after. Centralised inspection through Azure Firewall belongs in the same early pass, which is where the least-privilege, auditable-by-design network is cheapest to enforce. If you want a second pair of eyes on the topology and identity choices before you commit, that is exactly the kind of foundation work in landing zone networks and identity.

Frequently asked questions

Can I migrate from hub-and-spoke to Virtual WAN later?

Technically yes, but treat it as a project, not a config change. You re-home spoke VNet connections onto the managed hub, rebuild the inspection path through routing intent, and retest every on-premises and spoke-to-spoke route. Because it touches production connectivity, plan it with a cutover window rather than assuming an in-place switch.

How many IPSec tunnels before I need Virtual WAN?

Microsoft's guidance uses roughly 30 as the dividing line: a traditional hub suits fewer than 30 site-to-site tunnels, and more than 30 branch sites for native IPSec termination points toward Virtual WAN. The number is a signal about branch scale, not a hard cap. If you are nowhere near it and not growing a branch estate, the tunnel count is not your reason to choose Virtual WAN.

Does Virtual WAN support my own network virtual appliance?

Only within the managed hub's supported resource types. A Virtual WAN hub hosts Microsoft-managed resources such as the VPN and ExpressRoute gateways, Azure Firewall, and supported NVA or SaaS solutions, not an arbitrary appliance you deploy into a hub VNet. If your security design depends on a specific third-party appliance running exactly how you want it, confirm it is supported before you commit to Virtual WAN.

Do I need Azure Firewall in both designs?

If you want centralised east-west and north-south inspection, effectively yes, but it is placed differently. In a traditional hub you deploy Azure Firewall into a subnet named AzureFirewallSubnet and steer traffic to it with user-defined routes. In Virtual WAN you enable it through routing intent, which forwards private and internet traffic to the firewall without you writing per-spoke routes.

Is VNet peering transitive in a traditional hub-and-spoke?

No. VNet peering and global VNet peering are not transitive, so two spokes peered to the same hub cannot reach each other through the hub by default. You enable spoke-to-spoke transit by adding user-defined routes plus a network virtual appliance such as Azure Firewall in the hub. Virtual WAN provides this transitive routing as a managed feature instead.