Azure Landing Zone Networking: Hub-and-Spoke vs Virtual WAN [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.

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 — DNS design, network segmentation, hybrid connectivity, and migration paths — that architecture diagrams alone do not address. 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.

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. Every new spoke requires creating a VNet, establishing peerings in both directions, configuring route tables, and associating them with subnets. At 50+ spokes, this becomes operationally heavy.
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.

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/23 \
  --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

Virtual hub provisioning takes 20-30 minutes. Plan accordingly in your deployment pipelines.

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.

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. Virtual hubs incur hourly charges plus per-connection and per-routing-unit fees. For small deployments (under 10 spokes, single region), this can be significantly 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 significantly longer to provision than standard VNet resources. This affects both initial deployment and disaster recovery scenarios.

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 or any NVA	Azure Firewall or certified NVAs
SD-WAN integration	Manual (vendor-specific)	Built-in partner integrations
Spoke-to-spoke routing	Via firewall + UDRs	Automatic (direct or via firewall)
Max spokes per hub	Limited by peering (500)	Limited by routing (varies by SKU)
DNS integration	DNS Private Resolver in hub	DNS Private Resolver in spoke (linked)
Cost model	Pay for deployed resources only	Hub hourly fee + connection units + routing units
Deployment speed	Minutes (VNet + peering)	20-30 minutes (virtual hub)
Routing control	Full (custom route tables, UDRs)	Managed (route tables, static routes, routing intent)
Recommended scale	1-2 regions, fewer than 30 spokes	Multi-region, 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 certified for vWAN hubs, self-managed hub-and-spoke is the path.
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. Below this threshold, the operational burden of manual peering and route management is low enough that vWAN’s automation does not provide a compelling advantage.
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 — reducing 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 — a spoke cannot be peered to both simultaneously).
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. Here is a realistic monthly estimate for a moderate deployment in East US (prices are approximate and subject to change):

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

Azure Firewall Standard: ~$912/month
VPN Gateway (VpnGw1): ~$138/month
ExpressRoute Gateway (Standard): ~$146/month
Azure Bastion (Standard): ~$331/month
VNet peering (15 spokes, 1 TB inter-spoke traffic): ~$15/month
Total: ~$1,542/month

Virtual WAN (15 spokes, single region):

Virtual hub (Standard): ~$175/month
Azure Firewall Standard in hub: ~$912/month
VPN Gateway (1 scale unit): ~$138/month
ExpressRoute Gateway (1 scale unit): ~$146/month
VNet connections (15 spokes): included in hub cost
Routing infrastructure units: ~$73/month
Total: ~$1,444/month

At 15 spokes in a single region, the costs are comparable. Virtual WAN’s advantage becomes clearer as you add regions (where you would need additional hub VNets, firewalls, and gateways in hub-and-spoke) and as spoke counts grow past 30 (where operational costs of managing peerings and route tables add up). Conversely, for very small deployments (5 spokes, no ExpressRoute), hub-and-spoke with Azure Firewall Basic can cut costs significantly.

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 certified for vWAN
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-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 just one piece of the landing zone puzzle. Once your network foundation is in place, you need to layer on identity integration, governance policies, monitoring, and workload deployment patterns. Our Azure landing zone best practices guide covers these areas in detail.

For organizations evaluating which cloud platform to build on before committing to an Azure networking topology, our Azure vs AWS vs GCP comparison provides a platform-level perspective. And if you are still early in your cloud journey and want to understand how networking intersects with security strategy, our practical guide to zero trust security explains how network segmentation fits into a broader zero trust architecture.

The networking topology decision is not permanent — migration paths exist between hub-and-spoke and Virtual WAN — but it is consequential. Getting it right the first time saves months of re-architecture later. Take the time to map your requirements against the trade-offs outlined here, and choose the topology that fits your organization today while leaving room to evolve as your Azure footprint grows.

← Back to Blog

Azure Landing Zone Networking: Hub-and-Spoke vs Virtual WAN [2026]

Hub-and-Spoke Topology

How It Works

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

Deploying a Virtual WAN with Azure CLI

Strengths of Virtual WAN

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

Decision Framework

What Comes Next

Related Posts

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

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

Fix Azure AD Sync Errors: Connect & Cloud Sync Troubleshooting [2026]

Azure Policy Best Practices: Enforce Governance at Scale [2026]