Azure Hub-and-Spoke vs Virtual WAN for Landing Zones (2026)

The networking topology you choose for your Azure landing zone determines how traffic flows between workloads, how on-premises systems connect to the cloud, and how much control you retain over routing and security inspection. It is the single hardest decision to reverse once workloads are running in production.

The short answer: pick customer-managed hub-and-spoke if you run in one or two regions, need a specific firewall vendor, or want full routing control at the lowest cost. Pick Azure Virtual WAN if you span three or more regions, connect many branch offices or an SD-WAN, and would rather Microsoft run the hub and its routing.

Pick hub-and-spoke if…	Pick Virtual WAN if…
You deploy to one or two Azure regions	You deploy to three or more regions and want an automatic hub mesh
You have fewer than about 30 spokes, or you use Azure Virtual Network Manager to automate spokes	You expect many spokes plus many branches, VPN users, and ExpressRoute circuits in one fabric
You need a firewall or NVA that is not supported in a virtual hub	Azure Firewall, a supported in-hub NGFW, or a security SaaS meets your needs
You want to see and control every route table	You prefer declarative routing intent over hand-built UDRs
Cost is the main constraint (no hub fee, no hub data processing charge)	Operational simplicity is worth roughly $400 more per month at small scale (see the cost section)
You have no branch offices, or only a few site-to-site tunnels	You have dozens of branches or SD-WAN devices to onboard

Both topologies are first-class options in Microsoft’s Cloud Adoption Framework (CAF) landing zone reference architecture, and the Azure Landing Zones accelerator can deploy either one.

Azure offers two primary networking architectures for enterprise landing zones: the traditional hub-and-spoke model, where you build and manage a central hub VNet yourself, and Azure Virtual WAN (vWAN), where Microsoft manages the hub infrastructure and routing fabric on your behalf. Both are valid. Neither is universally better. The right choice depends on your organization’s scale, geographic footprint, hybrid connectivity requirements, and appetite for managing network infrastructure.

This guide breaks down both topologies in detail, compares them across the dimensions that matter for production environments, and covers the practical considerations that architecture diagrams alone do not address: DNS design, network segmentation, hybrid connectivity, cost, and migration paths. For broader context on landing zone design beyond networking, see our Azure landing zone best practices guide.

Hub-and-Spoke Topology

Hub-and-spoke is the most widely adopted networking topology for Azure landing zones. The concept is straightforward: a central hub VNet hosts shared network services, and individual spoke VNets (typically one per workload or application) peer to the hub. All traffic between spokes and between spokes and on-premises networks transits through the hub.

How It Works

The hub VNet acts as the central point of connectivity. It contains the network appliances and gateways that every spoke depends on:

Azure Firewall or third-party NVA for traffic inspection (both east-west between spokes and north-south to the internet)
VPN Gateway for site-to-site tunnels to on-premises data centers or branch offices
ExpressRoute Gateway for private, high-bandwidth connectivity to on-premises
Azure Bastion for secure administrative access to VMs without public IPs (see our guide to jumpboxes and Azure Bastion for more detail)
DNS Private Resolver for conditional DNS forwarding between on-premises and Azure

Each spoke VNet is peered to the hub. By default, VNet peering is non-transitive: Spoke A cannot talk to Spoke B through the hub without explicit routing. You solve this with User-Defined Routes (UDRs) on each spoke subnet that force traffic to the hub firewall’s private IP address. The firewall then evaluates the traffic against your rule set and forwards it to the destination spoke.

Hub Gateway Transit vs Direct Peering Between Spokes

There are two ways spokes in a hub-and-spoke design can reach each other and on-premises:

Transit through the hub. Spokes peer only to the hub. With allowGatewayTransit on the hub side and useRemoteGateways on the spoke side, every spoke shares the hub’s VPN or ExpressRoute gateway, so spokes do not need gateways of their own. Spoke-to-spoke traffic is routed by UDR to the hub firewall. This is the default landing zone pattern because every flow gets inspected.
Direct spoke-to-spoke peering. You peer specific spokes to each other (or let Azure Virtual Network Manager create a mesh). Traffic takes the shortest path with lower latency and no firewall processing charge, but it bypasses central inspection, so you rely on NSGs and security admin rules instead.

Most landing zones use hub transit by default and allow direct connectivity only for specific, high-volume, trusted flows (for example, an app tier talking to its own data tier in a separate spoke). Note that peering is billed per GB in both directions, including traffic that crosses the hub to reach a gateway, per Microsoft’s peering overview.

Automating Hub-and-Spoke with Azure Virtual Network Manager

The biggest historical complaint about hub-and-spoke was manual peering and route table work. Azure Virtual Network Manager (AVNM) removes most of it:

Connectivity configurations build a hub-and-spoke (optionally with direct spoke-to-spoke connectivity) or a mesh from a network group. Microsoft documents support for up to 1,000 spokes connected to a hub this way, beyond normal peering limits.
Dynamic network groups use Azure Policy conditions (for example, a tag) so a new spoke VNet joins the topology automatically when subscription vending creates it.
Routing configurations push UDRs, such as the default route to your hub firewall, to every spoke subnet centrally.
Security admin rules are evaluated before NSG rules, so the platform team can enforce rules workload teams cannot override.
IP address management (IPAM) allocates non-overlapping ranges from central pools.

AVNM is billed per managed virtual network for new instances. If AVNM covers your scale problem, it removes one of the main reasons teams used to move to Virtual WAN.

Deploying a Hub-and-Spoke with Bicep

The following Bicep example creates a hub VNet with subnets for Azure Firewall, a VPN Gateway, and Azure Bastion, then creates a spoke VNet and peers it to the hub. This gives you the foundational structure to build on.

@description('Azure region for all resources')
param location string = resourceGroup().location

@description('Address space for the hub VNet')
param hubAddressPrefix string = '10.0.0.0/16'

@description('Address space for the spoke VNet')
param spokeAddressPrefix string = '10.1.0.0/16'

// Hub Virtual Network
resource hubVnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: 'vnet-hub-eastus'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [hubAddressPrefix]
    }
    subnets: [
      {
        name: 'AzureFirewallSubnet'
        properties: {
          addressPrefix: '10.0.1.0/26'
        }
      }
      {
        name: 'GatewaySubnet'
        properties: {
          addressPrefix: '10.0.2.0/27'
        }
      }
      {
        name: 'AzureBastionSubnet'
        properties: {
          addressPrefix: '10.0.3.0/26'
        }
      }
    ]
  }
}

// Spoke Virtual Network
resource spokeVnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: 'vnet-spoke-app1-eastus'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [spokeAddressPrefix]
    }
    subnets: [
      {
        name: 'snet-app'
        properties: {
          addressPrefix: '10.1.1.0/24'
        }
      }
      {
        name: 'snet-data'
        properties: {
          addressPrefix: '10.1.2.0/24'
        }
      }
    ]
  }
}

// Peering: Hub to Spoke
resource hubToSpokePeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-11-01' = {
  parent: hubVnet
  name: 'peer-hub-to-spoke-app1'
  properties: {
    remoteVirtualNetwork: {
      id: spokeVnet.id
    }
    allowForwardedTraffic: true
    allowGatewayTransit: true
  }
}

// Peering: Spoke to Hub
resource spokeToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-11-01' = {
  parent: spokeVnet
  name: 'peer-spoke-app1-to-hub'
  properties: {
    remoteVirtualNetwork: {
      id: hubVnet.id
    }
    allowForwardedTraffic: true
    useRemoteGateways: true
  }
}

For teams choosing between IaC tools for this deployment, our Terraform vs Bicep vs ARM Templates comparison covers the trade-offs in depth.

Routing Configuration

The Bicep above creates the network skeleton, but without route tables the spokes will not send inter-spoke or internet-bound traffic through the hub firewall. You need a UDR on every spoke subnet that sends 0.0.0.0/0 to the firewall’s private IP.

# Create a route table for spoke subnets
az network route-table create \
  --resource-group rg-connectivity \
  --name rt-spoke-to-firewall \
  --location eastus \
  --disable-bgp-route-propagation true

# Add a default route pointing to the Azure Firewall private IP
az network route-table route create \
  --resource-group rg-connectivity \
  --route-table-name rt-spoke-to-firewall \
  --name default-to-firewall \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.4

# Associate the route table with a spoke subnet
az network vnet subnet update \
  --resource-group rg-app1 \
  --vnet-name vnet-spoke-app1-eastus \
  --name snet-app \
  --route-table rt-spoke-to-firewall

The --disable-bgp-route-propagation true flag is critical. Without it, BGP routes from your VPN or ExpressRoute gateway can override your UDR, causing traffic to bypass the firewall.

Strengths of Hub-and-Spoke

Full routing control. You define every route, every firewall rule, and every peering relationship. Nothing is abstracted away.
Bring your own NVA. If your organization standardizes on Palo Alto, Fortinet, or another vendor, you deploy their virtual appliance in the hub VNet. Azure Firewall is not required.
Cost predictability. You pay for the resources you deploy. There is no per-connection or per-routing-unit charge beyond the standard VNet peering costs.
Simplicity for single-region deployments. If your workloads are concentrated in one or two regions, hub-and-spoke is straightforward to design and operate.

Limitations of Hub-and-Spoke

Manual peering management. Without automation, every new spoke requires a VNet, peerings in both directions, route tables, and subnet associations. At 50+ spokes this becomes operationally heavy unless you use Azure Virtual Network Manager or IaC-driven subscription vending.
No transitive routing by default. You must configure UDRs and firewall rules to enable spoke-to-spoke communication. This is a common source of connectivity issues during initial deployment.
Multi-region complexity. Connecting hub-and-spoke topologies across regions requires hub-to-hub peering (global VNet peering), additional VPN or ExpressRoute gateways in each regional hub, and careful route management to avoid asymmetric routing.
Gateway transit limitations. A spoke VNet can only use remote gateways from one peered VNet, which constrains multi-hub designs.

Azure Virtual WAN Topology

Azure Virtual WAN is Microsoft’s managed networking service that provides hub infrastructure, routing, and branch connectivity as a platform service. Instead of building and managing your own hub VNet, you create a vWAN resource and deploy virtual hubs in each Azure region you operate in. Microsoft manages the hub routing fabric, and spokes connect to the virtual hub rather than a customer-managed VNet.

How It Works

A Virtual WAN resource is a logical container. Inside it, you deploy one or more virtual hubs, each in a specific Azure region. Each virtual hub can host:

Integrated VPN Gateway (site-to-site)
Integrated ExpressRoute Gateway
Point-to-site VPN gateway
Azure Firewall (deployed as a Secured Virtual Hub via Azure Firewall Manager)
Third-party security partners (Zscaler, Check Point, iBoss) via Security Partner Providers

Spoke VNets connect to the virtual hub using VNet connections (conceptually similar to peerings). The critical difference from traditional hub-and-spoke: Virtual WAN provides transitive routing by default. Spoke A can reach Spoke B through the virtual hub without any UDR configuration. The hub’s routing fabric handles it automatically.

What Is a Virtual Hub?

A virtual hub is a Microsoft-managed virtual network that contains the hub router plus whatever gateways and security appliances you add. You cannot deploy your own VMs or subnets into it. Each VNet can connect to only one virtual hub, and in a Standard Virtual WAN all hubs are connected to each other in a full mesh over the Microsoft backbone (Virtual WAN overview).

Azure Virtual WAN Basic vs Standard

	Basic	Standard
Site-to-site VPN	Yes	Yes
Point-to-site (user) VPN	No	Yes
ExpressRoute	No	Yes
VNet-to-VNet and inter-hub transit	No	Yes
Azure Firewall or NVA in the hub	No	Yes
Gateway scale units adjustable	No	Yes

You can upgrade Basic to Standard but cannot go back. For a landing zone, Standard is effectively the only option, because Basic lacks transit routing and ExpressRoute.

Virtual Hub Capacity and Address Space

The hub router deploys with 2 routing infrastructure units by default, which supports 3 Gbps aggregate throughput and 2,000 VMs across all connected VNets. Each additional unit adds 1 Gbps and 1,000 VMs, up to 50 units, and the router can autoscale above the minimum you set. A hub accepts at most 10,000 routes from its connected resources (hub settings).

The hub address space cannot be changed after creation. Microsoft’s minimum is a /24, but it recommends a /23 or larger, and a /22 if you will run Azure Firewall in the hub.

Deploying a Virtual WAN with Azure CLI

# Create the Virtual WAN resource
az network vwan create \
  --resource-group rg-connectivity \
  --name vwan-enterprise \
  --location eastus \
  --type Standard

# Create a virtual hub in East US
az network vhub create \
  --resource-group rg-connectivity \
  --name vhub-eastus \
  --vwan vwan-enterprise \
  --location eastus \
  --address-prefix 10.100.0.0/22 \
  --sku Standard

# Connect a spoke VNet to the virtual hub
az network vhub connection create \
  --resource-group rg-connectivity \
  --vhub-name vhub-eastus \
  --name conn-spoke-app1 \
  --remote-vnet /subscriptions/<sub-id>/resourceGroups/rg-app1/providers/Microsoft.Network/virtualNetworks/vnet-spoke-app1-eastus

# Create a site-to-site VPN gateway in the hub
az network vpn-gateway create \
  --resource-group rg-connectivity \
  --name vpngw-vhub-eastus \
  --vhub vhub-eastus \
  --location eastus \
  --scale-unit 1

An empty virtual hub takes about 5 to 7 minutes to create; a hub with a gateway takes about 30 minutes. Plan accordingly in your deployment pipelines. The /22 hub prefix above leaves room for Azure Firewall to scale.

Strengths of Virtual WAN

Automatic transitive routing. Spoke-to-spoke, spoke-to-branch, and hub-to-hub routing works without UDR management. This eliminates an entire category of configuration errors.
Built-in multi-region. Deploy virtual hubs in multiple regions and they automatically establish hub-to-hub connectivity. Cross-region traffic flows without additional peering or gateway configuration.
Branch connectivity at scale. vWAN was designed for organizations with dozens or hundreds of branch offices. It supports SD-WAN integration with partners like Cisco (Viptela/Meraki), VMware SD-WAN, and Barracuda.
Simplified operations. Microsoft manages the hub infrastructure, routing tables, and gateway high availability. Your network team focuses on policy and connectivity rather than infrastructure maintenance.
Routing intent and policies. vWAN’s routing intent feature lets you configure internet-bound and private traffic policies centrally, automatically generating the routes needed to send traffic through your security solution (see below).
Spoke onboarding at scale. Azure Virtual Network Manager can now connect many VNets to a Virtual WAN hub using network groups and a connection policy.

How Virtual WAN Routing Intent Works

Routing intent replaces most hand-built route tables in a secured virtual hub. Each hub can have at most one of each policy:

Internet traffic policy: the hub advertises a default route (0.0.0.0/0) to spokes, branches, and gateways, so internet-bound traffic goes to the security solution in the hub and out to the internet. The default route does not propagate across hubs, so each hub egresses through its own local firewall.
Private traffic policy: all branch-to-branch, branch-to-VNet, VNet-to-VNet, and inter-hub traffic goes through the security solution. This is what gives you inspected east-west traffic across regions without UDRs.

Supported next hops are Azure Firewall, a supported in-hub NGFW NVA, or a security SaaS. At the time of writing, Microsoft lists Check Point, Fortinet NGFW (and the dual-role Fortinet NGFW plus SD-WAN), and a Cisco NVA as eligible NVAs, with Palo Alto Networks Cloud NGFW supported as a SaaS next hop. Two limits catch people out: routing intent cannot be used on hubs with custom route tables, and static routes in the default route table that point to a VNet connection are not allowed. Decide on routing intent before you build custom route tables.

Limitations of Virtual WAN

Less routing control. You cannot deploy arbitrary resources into the virtual hub. Custom routing is possible through route tables and static routes, but you do not have the same granular control as a self-managed hub VNet.
Higher baseline cost. A Standard hub bills hourly whether or not it has gateways, plus per-GB data processing through the hub router, gateway scale units, and connection units. For small single-region deployments this is usually more expensive than a self-managed hub.
NVA constraints. While you can deploy Azure Firewall in the virtual hub, third-party NVA support in the hub is limited to specific Network Virtual Appliances certified for vWAN. If your organization requires a specific firewall vendor, verify it is supported before committing.
Troubleshooting opacity. When routing does not work as expected, diagnosing the issue in a managed hub is harder than in a self-managed VNet where you control every route table and NIC.
Deployment time. Virtual hubs and their gateways take longer to provision than standard VNet resources (about 30 minutes for a hub with a gateway). This affects both initial deployment and disaster recovery scenarios.
Shared services live in a spoke. Because you cannot deploy into the virtual hub, Azure Bastion, DNS Private Resolver, and domain controllers go in a shared services spoke.

Detailed Comparison

The following table summarizes the key differences across dimensions that affect real-world operations:

Dimension	Hub-and-Spoke	Azure Virtual WAN
Hub management	Customer-managed VNet	Microsoft-managed virtual hub
Transitive routing	Manual (UDRs + firewall)	Automatic
Multi-region	Hub-to-hub peering, manual route management	Automatic hub-to-hub mesh
VPN Gateway	Deploy and manage in hub VNet	Integrated, deploy via vWAN
ExpressRoute Gateway	Deploy and manage in hub VNet	Integrated, deploy via vWAN
Firewall options	Azure Firewall (Basic, Standard, Premium) or any NVA	Azure Firewall, supported in-hub NVAs, or security SaaS
SD-WAN integration	Manual (vendor-specific)	Built-in partner integrations
Spoke-to-spoke routing	Via firewall + UDRs	Automatic (direct or via firewall)
Spoke scale	Peering limits per hub VNet; up to 1,000 spokes with Virtual Network Manager	2,000 VMs by default, scaling to 50,000 VMs with routing infrastructure units; 10,000 routes per hub
DNS integration	DNS Private Resolver in hub	DNS Private Resolver in spoke (linked)
Cost model	Pay for deployed resources plus peering per GB	Hub hourly fee + hub data processing per GB + gateway scale units + connection units + extra routing units
Deployment speed	Minutes (VNet + peering); gateways take longer	5 to 7 minutes for an empty hub, about 30 minutes with a gateway
Routing control	Full (custom route tables, UDRs)	Managed (route tables, static routes, routing intent)
Recommended scale	1 or 2 regions, fewer than about 30 spokes (more with Virtual Network Manager)	3+ regions, 30+ spokes, many branches

When to Choose Hub-and-Spoke

Choose hub-and-spoke when:

Your deployment is single-region or dual-region. The operational overhead of managing hub infrastructure is manageable at this scale, and you save on vWAN fees.
You need a specific third-party NVA. If your security team requires Palo Alto VM-Series, Fortinet FortiGate, or another appliance that is not supported in Virtual WAN hubs, self-managed hub-and-spoke is the path. (Palo Alto Cloud NGFW and Fortinet NGFW do have Virtual WAN options, so check the current support list before deciding.)
You want maximum routing control. Some organizations need fine-grained control over every route for compliance or security reasons. Hub-and-spoke gives you visibility into every UDR and every NIC-level route table.
Your spoke count is under 30, or you automate spokes with Virtual Network Manager. Below this threshold, the burden of peering and route management is low enough that vWAN’s automation does not provide a compelling advantage, and AVNM pushes that threshold much higher.
Cost sensitivity is high. For smaller deployments, a hub VNet with Azure Firewall Basic or a third-party NVA can be significantly cheaper than a vWAN deployment with the same feature set.

When to Choose Virtual WAN

Choose Virtual WAN when:

You operate in three or more Azure regions. Multi-region hub-and-spoke with manual hub-to-hub peering and route management becomes unwieldy. vWAN’s automatic hub mesh eliminates this complexity.
You have 30+ spoke VNets. The peering management, route table updates, and firewall rule maintenance for large spoke counts is where vWAN’s automation delivers real operational savings.
Branch office connectivity is a priority. If you are connecting dozens of branch offices via site-to-site VPN or integrating with an SD-WAN platform, vWAN’s built-in branch connectivity is purpose-built for this scenario.
You prefer a managed service. If your network team is small and you want Microsoft to handle hub infrastructure, gateway HA, and routing fabric, vWAN reduces operational burden.
You need ExpressRoute and VPN coexistence. vWAN handles the coexistence of ExpressRoute and site-to-site VPN in the same hub more gracefully than the manual configuration required in hub-and-spoke.

Hybrid Connectivity: ExpressRoute and VPN

Both topologies support hybrid connectivity to on-premises environments, but the implementation details differ.

ExpressRoute

ExpressRoute provides private connectivity between your on-premises data centers and Azure. It does not traverse the public internet, which makes it the preferred option for latency-sensitive workloads, large data transfers, and regulatory scenarios that require private connectivity.

In hub-and-spoke, you deploy an ExpressRoute Gateway in the GatewaySubnet of your hub VNet and connect it to an ExpressRoute circuit. Spoke VNets learn on-premises routes via BGP through the gateway, provided useRemoteGateways is enabled on the peering.

In Virtual WAN, you deploy an ExpressRoute gateway in the virtual hub. The virtual hub automatically propagates on-premises routes to all connected spokes. If you have virtual hubs in multiple regions, ExpressRoute Global Reach or hub-to-hub transit can provide cross-region on-premises connectivity.

VPN as Backup for ExpressRoute

A common pattern is to use a site-to-site VPN as a failover path for ExpressRoute. In hub-and-spoke, you deploy both an ExpressRoute Gateway and a VPN Gateway in the same hub VNet. Failover requires careful BGP weight and AS path configuration to ensure traffic prefers ExpressRoute when it is healthy.

In Virtual WAN, both gateway types coexist in the virtual hub, and failover routing is handled more automatically through the vWAN routing fabric.

VPN-Only Connectivity

For organizations that do not need the bandwidth or SLA of ExpressRoute, site-to-site VPN provides encrypted connectivity over the internet. Both topologies support this. Virtual WAN adds value here for organizations with many branch offices, as it supports automated VPN tunnel provisioning from SD-WAN devices, which cuts the per-branch configuration effort from hours to minutes.

DNS Design

DNS is one of the most underestimated aspects of landing zone networking. It becomes especially critical when you start using Azure Private Endpoints, which require DNS resolution to direct traffic to private IP addresses instead of public endpoints.

Hub-and-Spoke DNS Architecture

In a hub-and-spoke topology, the recommended DNS design is:

Deploy Azure DNS Private Resolver in the hub VNet with inbound and outbound endpoints.
Host Azure Private DNS Zones (e.g., privatelink.blob.core.windows.net, privatelink.database.windows.net) in the connectivity subscription and link them to the hub VNet.
Configure spoke VNets to use the DNS Private Resolver’s inbound endpoint IP as their custom DNS server, or link Private DNS Zones directly to spoke VNets.
Set up conditional forwarding rules on the outbound endpoint so Azure resources can resolve on-premises DNS zones.
Configure on-premises DNS servers to forward Azure Private DNS zone queries to the DNS Private Resolver inbound endpoint.

# Create a DNS Private Resolver in the hub VNet
az dns-resolver create \
  --resource-group rg-connectivity \
  --name dnspr-hub-eastus \
  --location eastus \
  --id /subscriptions/<sub-id>/resourceGroups/rg-connectivity/providers/Microsoft.Network/virtualNetworks/vnet-hub-eastus

# Create an inbound endpoint (on-prem queries enter here)
az dns-resolver inbound-endpoint create \
  --resource-group rg-connectivity \
  --dns-resolver-name dnspr-hub-eastus \
  --name inbound-endpoint \
  --location eastus \
  --ip-configurations '[{"private-ip-allocation-method":"Dynamic","id":"/subscriptions/<sub-id>/resourceGroups/rg-connectivity/providers/Microsoft.Network/virtualNetworks/vnet-hub-eastus/subnets/snet-dns-inbound"}]'

Virtual WAN DNS Architecture

DNS in a Virtual WAN environment follows a similar conceptual model, but with an important nuance: you cannot deploy resources directly into the virtual hub VNet. Instead, you deploy the DNS Private Resolver in a shared services spoke VNet that is connected to the virtual hub. The Private DNS Zones are linked to this shared services VNet, and spoke VNets are configured to use the resolver’s IP as their DNS server.

This adds a hop but functions identically from a resolution perspective. The key is to ensure the shared services spoke VNet is connected to the virtual hub with the appropriate routing to allow DNS traffic from all other spokes.

Network Segmentation

Network segmentation (controlling which workloads can communicate with which) is central to a zero trust security posture. Both topologies provide segmentation mechanisms, but they differ in approach.

Segmentation in Hub-and-Spoke

In hub-and-spoke, segmentation is achieved through a combination of:

Network Security Groups (NSGs) on subnets to restrict traffic at the subnet boundary
Azure Firewall rules (or NVA rules) to control inter-spoke traffic at the hub level
Route tables that force all traffic through the firewall for inspection
Separate VNets for workloads that require strong isolation (a workload in its own spoke is network-isolated from other spokes by default until you explicitly allow traffic)

The granularity is excellent. You can define rules at the subnet level (NSGs), the network level (firewall rules), and the application level (application rules in Azure Firewall Premium with TLS inspection).

Segmentation in Virtual WAN

Virtual WAN provides segmentation through:

Custom route tables within the virtual hub that control which spokes can see each other’s routes
Labels that group route tables for policy application
Routing intent and policies that direct traffic through a security solution
NSGs on spoke subnets (the same as hub-and-spoke)

A common pattern is to create separate route tables for production and development spokes. Production spokes associate with the production route table and propagate routes only to that table. Development spokes do the same with a development route table. The result is that production and development workloads are network-isolated within the same virtual hub without any firewall rules.

For more fine-grained segmentation, you enable routing intent to send all private traffic through Azure Firewall in the secured virtual hub, then define application and network rules to control which spokes can communicate.

Migration Paths Between Topologies

Organizations sometimes need to migrate between topologies, typically from hub-and-spoke to Virtual WAN as they scale, though the reverse also happens.

Migrating from Hub-and-Spoke to Virtual WAN

This migration is disruptive but manageable with planning:

Deploy the Virtual WAN and virtual hub in parallel with your existing hub VNet. Both can coexist.
Connect a test spoke to the virtual hub (this requires removing its peering to the existing hub VNet first, because a spoke cannot use both at once).
Validate connectivity from the test spoke to on-premises (via the virtual hub’s gateways) and to other spokes still connected to the old hub.
Migrate spokes in batches. For each batch, remove the spoke-to-hub peering, create a VNet connection to the virtual hub, and update DNS settings if necessary. Each spoke experiences a brief connectivity interruption during the switchover.
Migrate gateways last. Once all spokes are on the virtual hub, move ExpressRoute and VPN connectivity from the old hub VNet’s gateways to the virtual hub’s integrated gateways.
Decommission the old hub VNet after validating that all traffic flows correctly through the virtual hub.

Plan for a maintenance window for each batch of spoke migrations. The peering removal and VNet connection creation each take a few minutes, but DNS propagation and route convergence can extend the total impact window.

Migrating from Virtual WAN to Hub-and-Spoke

This is less common but may be necessary if your organization needs NVA capabilities not supported in the virtual hub, or if vWAN costs become prohibitive.

The process mirrors the forward migration: deploy a new hub VNet in parallel, migrate spokes in batches (removing the virtual hub connection and creating a peering to the new hub VNet), and migrate gateways last. The same connectivity interruption applies during each spoke switchover.

Cost Comparison

Cost is frequently the deciding factor for mid-market organizations. The estimates below use Microsoft’s published pay-as-you-go list prices for East US from the Azure retail prices API as of October 2026, at 730 hours per month. They exclude per-GB charges, reservations, and enterprise discounts, so use the Azure pricing calculator for your own numbers.

What Does Azure Virtual WAN Cost vs Hub-and-Spoke?

Hub-and-spoke (15 spokes, single region, VPN plus ExpressRoute):

Component	Hourly list price	Monthly
Azure Firewall Standard	$1.25	~$913
VPN Gateway VpnGw1AZ	$0.21	~$153
ExpressRoute Gateway ErGw1AZ	$0.361	~$264
Azure Bastion Standard	$0.29	~$212
Fixed total		~$1,540

Plus per-GB charges: Azure Firewall data processing ($0.016 per GB) and VNet peering ingress and egress.

Virtual WAN (15 spokes, single region, VPN plus ExpressRoute):

Component	Hourly list price	Monthly
Standard virtual hub	$0.25	~$183
Azure Firewall Standard (secured virtual hub)	$1.25	~$913
Site-to-site VPN, 1 scale unit (500 Mbps)	$0.361	~$264
VPN connection unit (1 branch site)	$0.05	~$37
ExpressRoute, 1 scale unit (2 Gbps)	$0.42	~$307
ExpressRoute connection unit (1 circuit)	$0.05	~$37
Azure Bastion Standard (in a shared services spoke)	$0.29	~$212
Fixed total		~$1,950

Plus per-GB charges: hub data processing ($0.02 per GB), Azure Firewall data processing ($0.016 per GB), and VNet connection traffic, which Microsoft bills like peering. The default 2 routing infrastructure units (2,000 VMs) are covered by the hub price; each extra unit adds $0.10 per hour (about $73 per month).

What the numbers say:

At 15 spokes in one region, Virtual WAN costs roughly $400 per month more in fixed charges, plus its hub data processing fee. You are paying for managed routing and simpler operations, not saving money.
For very small deployments, the gap widens in relative terms. Hub-and-spoke with Azure Firewall Basic ($0.395 per hour, about $288 per month) and a VpnGw1AZ comes to about $442 per month. The smallest equivalent Virtual WAN (hub, Firewall Basic in the hub, one VPN scale unit, one site) is about $771 per month.
Adding regions adds a firewall and gateways per region in both models, so Virtual WAN’s multi-region advantage is mainly operational: automatic hub mesh, inter-hub routing, and routing intent instead of hand-maintained hub-to-hub routes.

Two pricing changes worth knowing: new non-zone-redundant VPN gateways (VpnGw1 to 5) can no longer be created as of November 1, 2025, and existing ones are being migrated to the AZ SKUs, which Microsoft repriced to support the migration (gateway SKU consolidation). Azure Firewall pricing is a fixed deployment charge per hour plus a per-GB processing charge, rising from Basic to Standard to Premium.

For broader strategies on managing Azure costs, see our cloud cost optimization guide.

Decision Framework

Use this framework to guide your topology decision:

Start with hub-and-spoke if:

You are deploying to one or two Azure regions
You have fewer than 30 spoke VNets
You need a third-party NVA that is not supported in a Virtual WAN hub
You want direct control over every aspect of routing
You are cost-conscious and willing to manage the operational overhead

Start with Virtual WAN if:

You are deploying to three or more Azure regions
You expect 30+ spoke VNets within the next 12 to 18 months
You have significant branch office connectivity requirements
Your network team is lean and you want to offload hub management to Microsoft
You are already using or planning to adopt SD-WAN

Regardless of topology, do the following:

Plan IP address spaces carefully upfront; renumbering a production network is painful
Centralize DNS management in the connectivity subscription
Enforce traffic inspection for both east-west and north-south flows
Automate spoke provisioning through Infrastructure as Code to prevent configuration drift
Document your routing design. A network topology diagram is not enough: document every route table, every peering, and every firewall rule set

What Comes Next

Choosing a networking topology is one piece of the landing zone puzzle. Once the network foundation is in place, you layer on identity, governance policy, monitoring, and workload deployment patterns. Our Azure landing zone best practices guide covers the management group hierarchy, accelerator options, and a full checklist. Network guardrails such as “deny public IPs in Corp” and “create Private Endpoint DNS records automatically” are enforced with Azure Policy; see Azure Policy best practices for governance at scale and our broader cloud governance guide.

For organizations still choosing a cloud platform, our Azure vs AWS vs GCP comparison provides a platform-level perspective. To see how network segmentation fits into a broader security strategy, read our practical guide to zero trust security. If your VPN tunnels are misbehaving in either topology, see troubleshooting Azure VPN Gateway.

The networking topology decision is not permanent, since migration paths exist between hub-and-spoke and Virtual WAN, but it is consequential. Map your requirements against the trade-offs here and choose the topology that fits your organization today while leaving room to grow.

Frequently Asked Questions

Which is better, Azure Virtual WAN or hub-and-spoke?

Neither is better in general. Customer-managed hub-and-spoke is cheaper and gives full routing control, which suits one or two regions and organizations that need a specific firewall vendor. Virtual WAN is better for three or more regions, many branch offices, or SD-WAN, because Microsoft manages the hub, transitive routing, and the hub-to-hub mesh.

What is the hub-and-spoke model in Azure?

Hub-and-spoke is a network topology where a central hub virtual network holds shared services such as Azure Firewall, VPN and ExpressRoute gateways, Azure Bastion, and DNS. Each workload gets its own spoke virtual network peered to the hub, and traffic between spokes or to on-premises flows through the hub, usually through the firewall.

Is Azure Virtual WAN a hub-and-spoke architecture?

Yes. Virtual WAN is a Microsoft-managed hub-and-spoke architecture. The difference is that Microsoft runs the hub, provides transitive routing between spokes, branches, and other hubs by default, and connects all hubs in a Standard Virtual WAN in a full mesh. In a traditional hub-and-spoke you build and operate the hub yourself.

What is a virtual hub in Azure?

A virtual hub is a Microsoft-managed virtual network inside Azure Virtual WAN. It contains a router and can host VPN, ExpressRoute, and point-to-site gateways plus Azure Firewall or supported network virtual appliances. You cannot deploy your own virtual machines into it, and each spoke virtual network connects to only one virtual hub.

What is the difference between Azure Virtual WAN Basic and Standard?

Basic supports only site-to-site VPN and does not mesh hubs or provide transit between virtual networks. Standard adds ExpressRoute, point-to-site VPN, VNet-to-VNet and inter-hub transit, Azure Firewall and NVAs in the hub, and adjustable gateway scale units. You can upgrade Basic to Standard but not downgrade. Landing zones should use Standard.

How much does Azure Virtual WAN cost compared to hub-and-spoke?

Using East US list prices in October 2026, a single-region design with 15 spokes, Azure Firewall Standard, VPN, ExpressRoute, and Bastion runs about $1,540 per month in fixed charges as hub-and-spoke and about $1,950 per month on Virtual WAN, before per-GB charges. A Standard virtual hub alone is $0.25 per hour, and Virtual WAN adds a hub data processing charge of $0.02 per GB.

Does VNet peering cost money?

Yes. Azure charges a small per-GB fee for both ingress and egress across a peering, and global peering between regions costs more than peering within a region. Traffic from a spoke to a gateway in the hub through gateway transit also incurs peering charges on the spoke side.

What is the difference between hub gateway transit and direct spoke peering?

With gateway transit, spokes peer only to the hub and share its VPN or ExpressRoute gateway, and spoke-to-spoke traffic is routed through the hub firewall for inspection. With direct peering, two spokes are peered to each other, so traffic takes the shortest path without central inspection. Most landing zones default to hub transit and allow direct connectivity only for specific trusted flows.

What is Virtual WAN routing intent?

Routing intent is a Virtual WAN feature that sends internet-bound traffic, private traffic, or both through a security solution in the hub, such as Azure Firewall, a supported next-generation firewall appliance, or a security SaaS. It programs the routes for you, including inter-hub traffic, but cannot be combined with custom route tables in the same hub.

Can Azure Virtual Network Manager replace Virtual WAN?

For many organizations, yes. Virtual Network Manager automates hub-and-spoke peering, optional direct spoke connectivity, user-defined routes, and security admin rules across subscriptions, which removes most of the manual work that used to push teams toward Virtual WAN. It does not provide the managed branch connectivity, SD-WAN integration, or automatic hub mesh that Virtual WAN does.

Can I use third-party firewalls with Virtual WAN?

Yes, with limits. You can run a third-party firewall in a spoke, use a security partner provider, or deploy a supported appliance directly in the hub. Only certain appliances can be the next hop for routing intent, and Microsoft maintains the list, so confirm your vendor is supported before choosing Virtual WAN.

Which topology does the Azure landing zone accelerator deploy?

The Azure Landing Zones accelerator supports both. You choose hub-and-spoke or Virtual WAN for the connectivity subscription when you configure the Bicep or Terraform deployment, and both can be deployed across multiple regions.

How Exodata Helps

Exodata designs and runs Azure landing zone networks for mid-market and enterprise teams: topology selection, IP and DNS design, Azure Firewall and routing intent configuration, Virtual Network Manager rollouts, and hub-and-spoke to Virtual WAN migrations without long outages. If you want a second opinion on your design or a cost model for your actual traffic, talk to an engineer. No sales pitch, just answers.

← Back to Blog

Azure Hub-and-Spoke vs Virtual WAN for Landing Zones (2026)

Hub-and-Spoke Topology

How It Works

Hub Gateway Transit vs Direct Peering Between Spokes

Automating Hub-and-Spoke with Azure Virtual Network Manager

Deploying a Hub-and-Spoke with Bicep

Routing Configuration

Strengths of Hub-and-Spoke

Limitations of Hub-and-Spoke

Azure Virtual WAN Topology

How It Works

What Is a Virtual Hub?

Azure Virtual WAN Basic vs Standard

Virtual Hub Capacity and Address Space

Deploying a Virtual WAN with Azure CLI

Strengths of Virtual WAN

How Virtual WAN Routing Intent Works

Limitations of Virtual WAN

Detailed Comparison

When to Choose Hub-and-Spoke

When to Choose Virtual WAN

Hybrid Connectivity: ExpressRoute and VPN

ExpressRoute

VPN as Backup for ExpressRoute

VPN-Only Connectivity

DNS Design

Hub-and-Spoke DNS Architecture

Virtual WAN DNS Architecture

Network Segmentation

Segmentation in Hub-and-Spoke

Segmentation in Virtual WAN

Migration Paths Between Topologies

Migrating from Hub-and-Spoke to Virtual WAN

Migrating from Virtual WAN to Hub-and-Spoke

Cost Comparison

What Does Azure Virtual WAN Cost vs Hub-and-Spoke?

Decision Framework

What Comes Next

Frequently Asked Questions

Which is better, Azure Virtual WAN or hub-and-spoke?

What is the hub-and-spoke model in Azure?

Is Azure Virtual WAN a hub-and-spoke architecture?

What is a virtual hub in Azure?

What is the difference between Azure Virtual WAN Basic and Standard?

How much does Azure Virtual WAN cost compared to hub-and-spoke?

Does VNet peering cost money?

What is the difference between hub gateway transit and direct spoke peering?

What is Virtual WAN routing intent?

Can Azure Virtual Network Manager replace Virtual WAN?

Can I use third-party firewalls with Virtual WAN?

Which topology does the Azure landing zone accelerator deploy?

How Exodata Helps

Related Posts

Azure Backup vs Veeam vs Commvault: Cloud Backup Compared [2026]

Azure Reserved Instances vs Savings Plans: Which Saves More? [2026]

Azure Policy Best Practices: 10 Patterns for Governance at Scale [2026]

Fix Entra Connect Sync Errors (Azure AD Connect) [2026]