Azure Virtual WAN
Simplify global networking with Azure Virtual WAN — hub deployment, gateway scaling, custom routing, routing intent, and NVA integration.
Azure Virtual WAN
Virtual WAN (VWAN) is Microsoft’s managed networking service that brings together VPN, ExpressRoute, and VNet connectivity into a single operational model. Instead of building your own hub-and-spoke, Azure manages the hubs.
🎬 Video coming soon
Azure Virtual WAN Architecture
Azure Virtual WAN Architecture
~13:00Virtual WAN is Microsoft building the hub for you. In a traditional hub-spoke, you deploy VPN Gateway, ExpressRoute Gateway, Firewall, and routing. With Virtual WAN, Microsoft manages the hub. You tell Azure what gateways you need, connect your VNets and branches, and Microsoft handles routing, scaling, and redundancy.
Virtual WAN SKUs
| Feature | Basic | Standard |
|---|---|---|
| Site-to-Site VPN | Yes | Yes |
| Point-to-Site VPN | No | Yes |
| ExpressRoute | No | Yes |
| VNet-to-VNet (through hub) | No | Yes |
| Inter-hub connectivity | No | Yes (automatic) |
| Azure Firewall in hub | No | Yes |
| NVA in hub | No | Yes |
| Routing intent | No | Yes |
| Cost | Lower | Higher (more features) |
Exam Tip: Basic VWAN only supports Site-to-Site VPN. For anything else (P2S, ExpressRoute, transit routing, firewall in hub), you need Standard SKU. You can upgrade Basic to Standard but cannot downgrade.
Elena’s Global Architecture
☁️ Elena’s scenario: Skyline Logistics has offices in 15 countries across 3 regions. Instead of manually building hub-and-spoke in each region, she deploys a Standard VWAN with 3 regional hubs:
┌─── Hub: Australia East ───┐
│ S2S GW ER GW │
│ P2S GW FW │
│ VNet connections │
└───────────┬────────────────┘
│ (automatic)
┌─── Hub: West Europe ──┐ │ ┌─── Hub: East US ──────┐
│ S2S GW ER GW │──────┘──────│ S2S GW ER GW │
│ P2S GW FW │ │ P2S GW FW │
│ VNet connections │ │ VNet connections │
└────────────────────────┘ └─────────────────────────┘Key benefit: Inter-hub connectivity is automatic. Elena doesn’t create peering between hubs — VWAN handles it. Traffic between hubs routes over Microsoft’s backbone.
Hub Deployment
When creating a hub, you specify:
- Region — one hub per region (you can have multiple hubs in different regions)
- Address prefix — hub’s internal address space (e.g., 10.100.0.0/24). Azure manages subnets within it.
- Gateways — deploy S2S VPN, P2S VPN, and/or ExpressRoute gateways as needed
- Scale units — determine gateway throughput
Gateway scale units:
| Gateway Type | Scale Units | Throughput |
|---|---|---|
| S2S VPN | 1 unit | 500 Mbps |
| S2S VPN | 2 units | 1 Gbps |
| S2S VPN | 20 units | 10 Gbps |
| P2S VPN | 1 unit | 500 Mbps |
| P2S VPN | Multiple | Scales linearly |
| ExpressRoute | 1 unit | 2 Gbps |
| ExpressRoute | 5 units | 10 Gbps |
Scale units can be increased without downtime. You pay for the gateway capacity whether used or not.
Hub Routing
VWAN hubs use route tables to control traffic flow. The default route table handles most scenarios automatically:
Default behavior:
- All VNet connections, VPN connections, and ER connections associate with and propagate to the default route table
- All connected VNets can reach all VPN sites and vice versa
- All hubs exchange routes automatically (transit)
Custom route tables let you isolate traffic:
- Create separate route tables for different groups of connections
- Associate connections with specific route tables (controls which routes they receive)
- Propagate connections to specific route tables (controls who learns about them)
- Static routes for specific destinations (e.g., force traffic to firewall)
Routing intent simplifies security routing:
When you deploy Azure Firewall or an NVA in a VWAN hub and enable routing intent, all traffic (internet and/or private) is automatically routed through the security appliance.
| Routing Intent Policy | What It Does |
|---|---|
| Internet traffic | All VNet-to-internet traffic routes through the hub’s firewall |
| Private traffic | All VNet-to-VNet and VNet-to-branch traffic routes through the hub’s firewall |
| Both | All traffic goes through the firewall — zero-trust approach |
🔒 Aisha’s extension: If Sentinel Banking used VWAN, she’d enable routing intent for both internet and private traffic, forcing everything through Azure Firewall in each hub. No manual UDRs needed.
NVA in Hub
Network Virtual Appliances in VWAN Hubs
Standard VWAN supports deploying select NVAs directly in the hub:
Supported NVA types:
- SD-WAN appliances: Barracuda, Cisco Viptela/Meraki, VMware SD-WAN — these replace the built-in S2S VPN gateway with the vendor’s SD-WAN gateway
- Next-gen firewalls: Checkpoint, Fortinet — deployed alongside or instead of Azure Firewall for inspection
How it works:
- Deploy the NVA from Azure Marketplace into the VWAN hub
- Configure the NVA through its own management portal
- Configure routing to send traffic through the NVA
When to use:
- Your organisation standardises on a specific SD-WAN vendor
- Compliance requires a specific firewall vendor
- You need features Azure Firewall doesn’t provide (vendor-specific inspection engines)
Limitation: NVA deployment is controlled by VWAN and the NVA partner — you don’t get full IaaS control like deploying an NVA in a regular VNet.
Key Takeaways
- Basic VWAN: S2S VPN only. Standard: everything (P2S, ER, transit, firewall)
- Inter-hub connectivity is automatic in Standard VWAN
- Scale units determine gateway throughput — increase without downtime
- Routing intent forces all traffic through the hub’s firewall automatically
- NVAs can be deployed in the hub for SD-WAN or third-party firewalls
Test Your Knowledge
Elena needs P2S VPN, ExpressRoute, and inter-hub transit in her Virtual WAN. Which SKU must she use?
Aisha wants all VNet-to-VNet and VNet-to-internet traffic in her VWAN to go through Azure Firewall. What's the simplest approach?
Next up: Choosing Your Hybrid Connection — Compare all connectivity options and learn which to choose for each scenario.