Azure Virtual WAN: Secured Hubs and Branch Connectivity
Azure Virtual WAN at a security engineer's level — secured virtual hubs (Azure Firewall integrated into the hub), branch connectivity via Site-to-Site VPN and ExpressRoute, hub routing policies, and how vWAN security maps to SC-500 objectives.
Virtual WAN, in one module
Azure Virtual WAN (vWAN) is Microsoft’s global hub-and-spoke networking service. Instead of manually building hubs in each region and managing peerings and VPN gateways, you create a vWAN, drop “virtual hubs” in the regions you operate, and connect branches (S2S VPN, ExpressRoute, point-to-site VPN) and VNet spokes to the hubs. Azure does the heavy lifting.
For SC-500, the key concept is the secured virtual hub — a hub with Azure Firewall (and optionally Azure Firewall Manager-managed third-party security partner provider) integrated directly into it, so all traffic transiting the hub passes through Azure Firewall. One central enforcement point, multiple regions, multiple branches.
Standard vs Secured Virtual Hub
| Feature | Standard hub | Secured virtual hub |
|---|---|---|
| What's deployed | vWAN hub with VPN/ER gateways | Hub + Azure Firewall (or partner SECaaS) deployed inline |
| Inspection of traffic | No native inspection | All traffic configured via routing intent passes through Azure Firewall |
| Centralisation | Per-VNet inspection if needed (Azure Firewall in spoke) | One central firewall per hub serves all spokes and branches |
| Best for | Connectivity-only deployments where security is handled at spoke level | Production enterprise deployments needing central inspection and policy |
A Secured Virtual Hub is the SC-500 default when the scenario describes central security inspection across multiple VNets / branches in a vWAN topology.
Routing intent
Routing intent is the declarative mechanism that tells the hub how to route traffic:
- Private traffic (between spokes, branches, etc.) → route through Azure Firewall
- Internet traffic (outbound from spokes) → route through Azure Firewall
Setting routing intent programmes the underlying effective routes across all hub connections automatically. Without routing intent, you’d manually configure user-defined routes per VNet — slow and error-prone at scale.
Branch connectivity
| Branch type | Use case |
|---|---|
| Site-to-Site (S2S) VPN | Branch offices connected over the internet via IPsec — typical for SMB / cost-sensitive deployments |
| ExpressRoute (with private peering) | Dedicated private circuit from on-prem to Azure via an ER provider — typical for regulated and bandwidth-heavy workloads |
| ExpressRoute Direct | Direct fibre from on-prem to Microsoft's edge — for hyperscale / extreme-bandwidth scenarios |
| Point-to-Site (P2S) VPN | Remote users connecting via VPN client (OpenVPN / IKEv2) — can integrate with Microsoft Entra for authentication |
P2S VPN to a vWAN hub supports Microsoft Entra ID for user authentication and Conditional Access for posture enforcement — the SC-500 right answer for connecting remote users with identity-aware enforcement.
Scenario: Asha consolidates Aurora’s network on vWAN
Aurora Health Service operates across 3 regions, 12 hospital branch sites, and ~80 VNets:
- vWAN with 3 secured virtual hubs (Aus East, Aus Southeast, NZ North). Each hub has an integrated Azure Firewall.
- Routing intent: private + internet traffic both route through Firewall on each hub.
- Branches: 12 hospital sites connect via S2S VPN to their nearest hub; the head-office datacentre connects via ExpressRoute.
- Remote staff: P2S VPN to the nearest hub with Microsoft Entra authentication + Conditional Access requiring compliant device + phishing-resistant MFA.
- Azure Firewall Manager holds the base policy (allow internal hospital flows, block known-bad lists, log everything); child policies per hub add region-specific rules.
Result: one central security policy enforced at three hubs; ~80 VNets get hub-mediated inspection automatically; branches reach Azure via encrypted VPN/ER with hub inspection; remote staff identity-aware.
Key terms
Knowledge check
Asha at Aurora Health Service is rolling out a vWAN topology with 3 hubs and ~80 spoke VNets. She wants all inter-spoke traffic AND all spoke-to-internet outbound inspected centrally per region. Which configuration fits?
Esme at Northwind Bank wants remote staff connecting via P2S VPN to the bank's vWAN hub to be authenticated via Microsoft Entra ID and gated by Conditional Access (compliant device, phishing-resistant MFA). Which P2S VPN authentication option fits?
What’s next
Next: VPN connections and Microsoft Entra Private Access — Site-to-Site VPN security configuration, plus the new Zero Trust Network Access (ZTNA) capability that replaces VPN entirely for many remote-access scenarios.