This chapter covers Azure Virtual WAN, a networking service that provides optimized and automated branch-to-branch and branch-to-Azure connectivity through a global transit hub architecture. It is critical for the AZ-104 exam because networking questions (Objective 4.4) frequently test your understanding of Virtual WAN vs. traditional hub-and-spoke, its components, and configuration steps. Approximately 10-15% of exam questions touch on Virtual WAN or related hybrid connectivity concepts.
Jump to a section
Imagine a global courier company that operates a network of regional sorting hubs. Each hub is connected to every other hub via high-speed dedicated routes (the Microsoft backbone). Individual branch offices (your on-premises sites) send their packages to their nearest hub over local roads (VPN or ExpressRoute connections). Within the hub, packages are sorted and forwarded to the correct destination hub, which then delivers them to the final branch. The hub also has a special counter for packages destined to the company’s internal headquarters (Azure VNets). The key is that branches never need to know the exact location of other branches—they just send everything to their hub. The hub handles routing, load balancing, and even provides security inspection (Azure Firewall) if needed. This eliminates the need for a mesh of point-to-point connections between every pair of sites. In Azure Virtual WAN, the hub is a Microsoft-managed virtual hub that contains routing, connectivity, and security services. VNets connect to the hub via VNet peering, and branches connect via VPN or ExpressRoute. The hub automatically learns routes and propagates them, so traffic flows efficiently over the Microsoft backbone instead of the public internet.
What is Azure Virtual WAN?
Azure Virtual WAN is a networking service that brings together many networking, security, and routing functionalities into a single operational interface. It is designed to provide large-scale branch connectivity, optimizing traffic routing over the Microsoft global network backbone. Unlike a traditional hub-and-spoke topology where you manually configure a hub VNet, VPN gateways, and ExpressRoute gateways, Virtual WAN automates these deployments and provides a unified management plane.
Virtual WAN is not just a single resource; it is a collection of resources and configurations. At its core, a Virtual WAN (the resource) contains a set of virtual hubs. Each virtual hub is a Microsoft-managed VNet that contains various service endpoints such as VPN gateways (Site-to-Site and Point-to-Site), ExpressRoute gateways, Azure Firewall, and routing capabilities. These hubs are automatically interconnected via the Microsoft backbone, forming a full mesh. This means that traffic from a branch in one region can reach a VNet in another region via the hub-to-hub connection without traversing the public internet.
Why does it exist?
Before Virtual WAN, enterprises with many branch offices and multiple Azure regions had to create complex topologies. They would need to set up multiple VPN gateways, configure VNet peering, establish ExpressRoute circuits, and manage routing tables manually. This was error-prone and hard to scale. Virtual WAN solves this by providing a single pane of glass for all connectivity needs, automating the deployment of gateways and routing, and ensuring optimal traffic paths.
How it works internally
When you create a Virtual WAN and a virtual hub, Azure automatically deploys a managed VNet in the hub region. This VNet is not directly visible in your subscription's VNet list—it is managed by the Azure platform. The hub contains subnets for various gateway types. For example, a VPN gateway in the hub uses a dedicated subnet named GatewaySubnet. The hub also hosts the routing engine that processes route advertisements from connected branches and VNets.
Each virtual hub has a built-in router that supports transit routing. When you connect a VNet to a hub via VNet peering, the hub automatically injects routes into the VNet's route tables so that VMs in the VNet can reach other VNets and branches connected to the same hub. Similarly, branches (VPN or ExpressRoute) send their routes to the hub, which then propagates them to all other connected VNets and branches. This is done using BGP over the VPN or ExpressRoute connections.
Key components, values, defaults, and timers
Virtual WAN resource: The top-level container. You can have multiple Virtual WANs per subscription, but typically one per enterprise.
Virtual hub: A managed hub in a specific region. Each hub can serve multiple VNets and branches. Hubs within the same Virtual WAN are automatically connected via the Microsoft backbone with high bandwidth and low latency.
Hub-to-hub connection: Automatic; no user configuration needed. The bandwidth is determined by the hub SKU (Standard vs. Basic). Standard hubs support up to 20 Gbps per hub.
VPN gateway (Site-to-Site): Supports up to 10 Gbps aggregate throughput per hub for Standard SKU. Default BGP timer values: Keepalive 60 seconds, Hold time 180 seconds.
ExpressRoute gateway: Supports up to 10 Gbps per hub for Standard SKU. Requires ExpressRoute circuits with private peering.
Point-to-Site VPN gateway: Supports up to 200 concurrent connections per hub for Standard SKU (OpenVPN or IKEv2).
Azure Firewall: Can be deployed inside the hub for traffic inspection. This is called a secured virtual hub.
Routing intent: Feature that allows you to define how traffic should be routed (e.g., through firewall).
Virtual network connection: A connection from a VNet to the hub. It uses VNet peering (transitive peering is not supported directly, but hub provides transit).
Branch connection: Site-to-Site VPN or ExpressRoute connection from on-premises to the hub.
Configuration and verification commands
To create a Virtual WAN and hub using Azure CLI:
# Create a resource group
az group create --name my-vwan-rg --location westus
# Create a Virtual WAN
az network vwan create --name MyVWAN --resource-group my-vwan-rg --location westus --type Standard
# Create a virtual hub
az network vhub create --name MyHub --resource-group my-vwan-rg --vwan MyVWAN --location westus --address-prefix 10.0.0.0/24
# Create a Site-to-Site VPN gateway in the hub
az network vpn-gateway create --name MyVPNGateway --resource-group my-vwan-rg --location westus --vhub MyHub --sku Standard
# Create a VPN site (on-premises representation)
az network vpn-site create --name MyBranch --resource-group my-vwan-rg --location westus --virtual-wan MyVWAN --ip-address 203.0.113.1 --address-prefixes 192.168.1.0/24
# Connect the site to the hub
az network vpn-connection create --name MyConnection --resource-group my-vwan-rg --location westus --vpn-gateway MyVPNGateway --vpn-site MyBranch --shared-key MySecret123
# Connect a VNet to the hub
az network vhub-connection create --name MyVNetConnection --resource-group my-vwan-rg --vhub MyHub --remote-vnet MyVNetIdTo verify connectivity:
# List all connections in the hub
az network vhub-connection list --resource-group my-vwan-rg --vhub-name MyHub
# Show routing state
az network vhub show --name MyHub --resource-group my-vwan-rg --query 'routingState'How it interacts with related technologies
Azure Firewall: When deployed in a secured virtual hub, all traffic between VNets and branches can be forced through the firewall for inspection. This is configured via routing intent.
Network Virtual Appliances (NVAs): You can deploy NVAs in a spoke VNet and use route tables to direct traffic, but Virtual WAN's built-in routing may conflict. Custom route tables in the hub can override default behavior.
Azure DNS: Private DNS zones can be linked to VNets connected to the hub, but note that DNS resolution across hubs requires additional configuration (e.g., DNS forwarder).
Traffic Manager / Front Door: These services sit at the application layer and are complementary to Virtual WAN, which focuses on network-layer connectivity.
Limitations and edge cases
Virtual WAN does not support VNet-to-VNet transitive peering through the hub for traffic that does not go through the hub's router. All traffic between VNets must traverse the hub (hub acts as transit).
Basic SKU Virtual WAN does not support ExpressRoute or Point-to-Site VPN; only Site-to-Site VPN with limited throughput (100 Mbps per site).
Hub address space cannot overlap with any connected VNet or branch address space. Overlap causes routing issues.
Maximum number of virtual hubs per Virtual WAN: 20 (subject to quota).
Maximum number of VNet connections per hub: 500.
Maximum number of VPN sites per hub: 1000.
ExpressRoute circuits must be in the same region as the hub or connected via a global reach.
Create Virtual WAN resource
Start by creating the top-level Virtual WAN resource. Choose a name, region, and SKU (Basic or Standard). The SKU determines available features: Basic supports only Site-to-Site VPN with limited throughput; Standard supports VPN, ExpressRoute, Point-to-Site, Azure Firewall, and higher throughput. The Virtual WAN resource is a container for hubs; it does not consume any IP addresses or compute resources itself.
Create virtual hub in a region
Within the Virtual WAN, create a virtual hub in a specific Azure region. Provide a name, region, and address prefix (e.g., 10.0.0.0/24). This prefix defines the hub's internal address space. Azure will use this space for gateway subnets and internal routing. The hub is a managed VNet; you cannot see it in your VNet list. After creation, the hub is deployed with a router that manages transit routing.
Deploy gateways in the hub
Depending on your connectivity needs, deploy one or more gateways: VPN (Site-to-Site or Point-to-Site), ExpressRoute, or both. Each gateway requires a dedicated subnet within the hub's address space (e.g., GatewaySubnet for VPN). The gateway SKU determines throughput and capacity. For Standard hubs, VPN gateways support up to 10 Gbps aggregate. The deployment takes 30-45 minutes.
Connect on-premises branches
Create VPN sites representing your on-premises branches. Each site includes the public IP of the VPN device and the on-premises address prefixes (e.g., 192.168.1.0/24). Then create a VPN connection from the hub's VPN gateway to the site using a pre-shared key. BGP can be enabled for dynamic routing. For ExpressRoute, you create an ExpressRoute gateway and associate an ExpressRoute circuit.
Connect Azure VNets to the hub
For each VNet you want to connect, create a VNet connection in the hub. Specify the VNet ID and the hub. This creates a VNet peering between the hub and the VNet. The hub automatically propagates routes from other connections to the VNet, and vice versa. The VNet's address space must not overlap with the hub or other connected networks.
Configure routing and security
By default, the hub routes traffic between all connected endpoints. To enforce security, deploy Azure Firewall in the hub (secured virtual hub) and configure routing intent to direct traffic through the firewall. You can also create custom route tables in the hub to override default behavior, e.g., force traffic to an NVA in a spoke VNet.
Verify and monitor connectivity
Use Azure Monitor metrics and logs to check gateway health, traffic flows, and BGP status. In the Azure portal, the Virtual WAN blade provides a dashboard showing connected sites, VNets, and route tables. You can also use Azure CLI commands like `az network vhub show --query 'routingState'` to verify that routing is active.
Enterprise Scenario 1: Global Retail Chain with 500+ Stores
A multinational retailer with stores across North America, Europe, and Asia needed to connect each store to Azure for inventory management and POS systems. Previously, they used site-to-site VPNs from each store to a central hub VNet in one region, causing high latency for far-flung stores. With Azure Virtual WAN, they deployed a Virtual WAN with hubs in West US, West Europe, and Southeast Asia. Each store connected to the nearest hub via VPN. The hubs automatically interconnected over the Microsoft backbone, so traffic from a store in Japan to a VNet in West US traversed the backbone instead of the public internet, reducing latency by 40%. They used BGP on VPN connections for dynamic route propagation, which simplified adding new stores. A challenge was ensuring that the hub address spaces (10.0.0.0/16 per hub) did not overlap with store subnets (192.168.x.x). They also deployed Azure Firewall in each hub to inspect traffic between stores and VNets, meeting compliance requirements. Misconfiguration occurred when a store's VPN device had incorrect BGP timers (keepalive set to 10 seconds instead of 60), causing flapping; standardizing the configuration resolved it.
Enterprise Scenario 2: Financial Services with ExpressRoute and VPN Backup
A bank had two data centers connected to Azure via ExpressRoute circuits in two regions. They also had 50 branch offices that needed to connect to Azure and to each other. They used Virtual WAN with hubs in East US and West US. Each data center connected to both hubs via ExpressRoute (active-active). Branch offices connected via Site-to-Site VPN to the nearest hub. The bank used routing intent to force all traffic through Azure Firewall for inspection. They configured BGP communities to prioritize ExpressRoute over VPN. A common issue was that the ExpressRoute gateway in the hub had a default throughput of 10 Gbps, but the bank's traffic peaked at 8 Gbps, so they needed to monitor usage closely. They also learned that VNet connections to the hub must have non-overlapping address spaces; one team accidentally created a VNet with overlapping IPs, causing routing conflicts that were resolved by changing the VNet address space.
Scenario 3: Merger of Two Companies
After a merger, two companies needed to connect their Azure environments and on-premises networks. One used traditional hub-and-spoke with VPN gateways; the other used Virtual WAN. They decided to migrate the traditional topology to Virtual WAN. They created a new Virtual WAN and gradually moved VNet connections from the old hub to the new virtual hub. During migration, they used Azure Site-to-Site VPN between the old hub and new hub temporarily. The challenge was that the old hub had custom route tables that needed to be replicated in the Virtual WAN hub using custom route tables. They also had to re-establish ExpressRoute circuits to the new hub. The migration took two weeks, but once complete, management was simplified.
What AZ-104 Tests
Objective 4.4 covers 'Design and implement connectivity between on-premises and Azure' and includes Virtual WAN. The exam focuses on:
Understanding the difference between Basic and Standard SKUs (especially features like ExpressRoute support).
Knowing that Virtual WAN provides automatic transit routing between hubs and spokes.
Recognizing that VNet peering is used for VNet-to-hub connections, but the hub provides transitive routing.
Identifying scenarios where Virtual WAN is preferred over traditional hub-and-spoke (e.g., many branches, multiple regions).
Configuring VPN sites and connections, and understanding BGP propagation.
Secured virtual hub with Azure Firewall.
Common Wrong Answers
'Virtual WAN is just a VPN gateway.' Wrong – Virtual WAN is a managed service that includes multiple gateways, routing, and security. Candidates confuse it with a simple VPN gateway.
'VNets connected to the same hub can communicate directly without going through the hub.' Wrong – Traffic must go through the hub's router. Direct VNet peering between spokes is not transitive unless explicitly configured.
'Basic SKU supports ExpressRoute.' Wrong – Basic SKU only supports Site-to-Site VPN with limited throughput. Standard is required for ExpressRoute, Point-to-Site, and Azure Firewall.
'Virtual WAN hubs are peered like VNet peering.' Wrong – Hubs are automatically connected via the Microsoft backbone, not VNet peering. The connection is managed internally.
Specific Numbers and Terms
Standard hub throughput: up to 20 Gbps per hub (for hub-to-hub).
VPN gateway throughput: up to 10 Gbps per hub (Standard).
Maximum VPN sites per hub: 1000.
Maximum VNet connections per hub: 500.
BGP keepalive: 60 seconds; hold time: 180 seconds.
Hub address prefix must be /24 or larger.
Secured virtual hub: Azure Firewall deployed in the hub.
Edge Cases
If a VNet is connected to multiple hubs, it creates routing complexity and is not recommended. The exam may ask about this limitation.
ExpressRoute circuits must be in the same region as the hub or use Global Reach to connect to a hub in another region.
Overlapping address spaces between hub and spokes are not allowed and will cause routing failures.
How to Eliminate Wrong Answers
Look for keywords like 'automatic transit', 'managed hub', 'multi-region', 'branch-to-branch' – these point to Virtual WAN.
If the question mentions ExpressRoute or Point-to-Site VPN, eliminate Basic SKU.
If the question says 'manual configuration of VPN gateways and VNet peering', it likely refers to traditional hub-and-spoke, not Virtual WAN.
Remember: Virtual WAN uses the Microsoft backbone for inter-hub traffic, not the public internet.
Azure Virtual WAN provides a global transit network architecture with automatic routing and connectivity.
Standard SKU is required for ExpressRoute, Point-to-Site VPN, and Azure Firewall; Basic SKU only supports Site-to-Site VPN.
Virtual hubs are Microsoft-managed VNets that host gateways and routing; they automatically interconnect within the same Virtual WAN.
VNets connect to hubs via VNet peering, but traffic between VNets must traverse the hub's router.
Maximum of 20 hubs per Virtual WAN; up to 500 VNet connections per hub; up to 1000 VPN sites per hub.
BGP is used for dynamic route propagation between branches and hubs; default keepalive 60s, hold 180s.
Secured virtual hub integrates Azure Firewall for traffic inspection; configure via routing intent.
Overlapping address spaces between hub, VNets, and branches are not allowed and cause routing failures.
These come up on the exam all the time. Here's how to tell them apart.
Traditional Hub-and-Spoke (Manual)
Requires manual creation of hub VNet, VPN/ExpressRoute gateways, and VNet peering.
No automatic transit routing between spokes; you must configure route tables or NVAs.
Scaling to multiple regions requires repeating the manual process in each region.
Branch connectivity requires individual VPN tunnels to the hub, managed individually.
No built-in security services; you must deploy and configure Azure Firewall separately.
Azure Virtual WAN
Automated deployment of hubs, gateways, and routing via a single service.
Built-in transit routing between all spokes and branches through the hub's router.
Hubs in multiple regions automatically interconnect over the Microsoft backbone.
Branches connect to the nearest hub; configuration is centralized and simplified.
Supports secured virtual hub with integrated Azure Firewall and routing intent.
Mistake
Azure Virtual WAN is just a managed VPN gateway.
Correct
Virtual WAN is a comprehensive networking service that includes VPN gateways, ExpressRoute gateways, Azure Firewall, and automatic routing. It is far more than a simple VPN gateway; it provides a global transit network architecture.
Mistake
VNets connected to the same hub can communicate directly via VNet peering.
Correct
Traffic between VNets must go through the hub's router. The hub provides transitive routing, but there is no direct VNet peering between spokes unless explicitly created separately.
Mistake
Basic SKU supports all connectivity options.
Correct
Basic SKU only supports Site-to-Site VPN connections with limited throughput (100 Mbps per site). ExpressRoute, Point-to-Site VPN, and Azure Firewall require Standard SKU.
Mistake
Virtual WAN hubs are connected via VNet peering.
Correct
Hubs within the same Virtual WAN are automatically interconnected via the Microsoft backbone network, not through VNet peering. This is a managed, high-bandwidth connection.
Mistake
You can connect a VNet to multiple hubs without issues.
Correct
While technically possible, connecting a VNet to multiple hubs is not recommended and can cause routing complexity. Azure does not support transitive routing through multiple hubs for the same VNet.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Virtual WAN is a managed service that automates the deployment of hubs, gateways, and routing. Traditional hub-and-spoke requires manual creation of a hub VNet, VPN/ExpressRoute gateways, and VNet peering. Virtual WAN provides automatic transit routing between all connected endpoints, while traditional hub-and-spoke requires custom route tables or NVAs for transit. Virtual WAN also supports multiple interconnected hubs across regions, simplifying multi-region deployments.
Yes, but only with Standard SKU. You deploy an ExpressRoute gateway in the virtual hub and associate an ExpressRoute circuit. The circuit must be in the same region as the hub or use Global Reach to connect to a hub in another region. The ExpressRoute gateway supports up to 10 Gbps throughput per hub.
Each virtual hub has a built-in router that learns routes from connected VNets (via VNet peering) and branches (via BGP over VPN or ExpressRoute). The router automatically propagates these routes to all other connections. For example, a branch's on-premises prefixes are advertised to all VNets and other branches connected to the same hub. For multi-hub scenarios, hubs automatically exchange routes via the Microsoft backbone.
A secured virtual hub is a virtual hub that has Azure Firewall deployed inside it. This allows you to inspect and filter traffic flowing through the hub, including traffic between VNets, between branches, and between VNets and branches. You configure routing intent to force traffic through the firewall. This is a key feature for enterprises that need centralized security.
Yes, technically you can create multiple VNet connections from the same VNet to different hubs, but this is not recommended. It can cause routing asymmetry and complexity. Azure does not support transitive routing through multiple hubs for the same VNet. It is better to connect each VNet to only one hub.
Basic SKU only supports Site-to-Site VPN connections with a maximum throughput of 100 Mbps per site. It does not support ExpressRoute, Point-to-Site VPN, Azure Firewall, or hub-to-hub connections. Basic SKU is suitable for small-scale deployments with simple VPN needs. For production and multi-region scenarios, use Standard SKU.
You can use Azure Monitor to view metrics and logs for virtual hubs, VPN gateways, and ExpressRoute gateways. In the Azure portal, the Virtual WAN blade provides a dashboard showing connected sites, VNets, and route tables. You can also use Azure CLI commands like `az network vhub show --query 'routingState'` to check routing status. BGP status can be monitored via Azure Monitor metrics.
You've just covered Azure Virtual WAN — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?