Azure Virtual WAN (vWAN) is a cloud-native networking service that aggregates connectivity, routing, and security services into a single operational interface.
Instead of manually building and managing complex mesh networks across multiple regions, Virtual WAN provides a centralized managed hub architecture designed to connect branch offices, remote workers, data centers, and Virtual Networks (VNets) globally over the Microsoft backbone network.
Key Architectural Concepts
The diagram shows an Azure Virtual WAN with two secured hubs, each with an Azure Firewall. The hubs are auto-peered to each other. Spoke VNets, branch VPN or remote users, and ExpressRoute connect to the hub in their region.
Points worth making in an interview:
- “Secured hub” means a hub with a firewall. Azure Firewall Manager (or Firewall Policy) attaches security and routing intent to the hub. With routing intent, traffic between spokes, branches, and the internet is forced through the firewall instead of flowing directly.
- Hub-to-hub connectivity is automatic and managed. Unlike a hand-built hub-and-spoke, you don’t maintain peerings or user-defined routes. That reduces misconfiguration, which is a common cause of bypassed inspection.
- Control that moves to policy. Segmentation shifts from NSG-per-subnet thinking to firewall policy, route tables, and routing intent, so your review should focus on whether inter-hub and branch-to-spoke traffic is actually inspected.
- Limits to be honest about. Spokes in the same hub can have lateral paths unless you enforce inspection for inter-spoke traffic. Firewall inspection also adds cost and latency, and this design does not secure what happens inside a spoke, so workload-level controls (NSGs, private endpoints, identity) are still needed.
1. The Virtual WAN Resource
Represents the global overlay container across your Azure enterprise. It manages the global routing topology and connects multiple hubs across regions.
2. Virtual Hubs
Managed Google/Microsoft-hosted Virtual Networks deployed in specific regions. Hubs act as the core transit points in each region and host gateways for:
- Site-to-Site VPN: Connects branch offices directly into the hub.
- Point-to-Site VPN (User VPN): Connects remote workers/devices directly to Azure.
- ExpressRoute: Connects private on-premises circuits.
- Spoke Virtual Networks: Connects Azure workloads via VNet peering.
3. Hub-to-Hub Transitivity
When you deploy multiple hubs across different Azure regions within the same Virtual WAN, Azure automatically interconnects them. This provides out-of-the-box global transit routing between branch offices, user VPNs, and VNets across regions without manual route configuration.
Basic vs. Standard SKU
| Feature | Basic SKU | Standard SKU |
| Site-to-Site VPN | Supported | Supported |
| ExpressRoute & Point-to-Site VPN | Not supported | Supported |
| VNet-to-VNet Routing | Limited | Full transitive routing |
| Secured Virtual Hub (Azure Firewall) | Not supported | Supported |
| Inter-Hub (Global) Routing | Not supported | Automatic mesh routing |
Traditional Hub-and-Spoke vs. Azure Virtual WAN
| Scenario | Traditional Hub-and-Spoke | Virtual WAN (Secured Hub) |
| Hub Infrastructure | Customer-managed VNets, VMs, and gateway subnets. | Microsoft-managed hub scale sets and gateways. |
| Routing Management | Manual User Defined Route (UDR) tables on every subnet. | Centralized Routing Intent automatically pushing routes. |
| Cross-Region Transit | Manual VNet peering between regional hubs and custom UDRs. | Automatic inter-hub transit over Microsoft’s global backbone. |
| Security Integration | NVA/Firewall management requiring complex route tables. | Azure Firewall Manager integration in 1 click. |