4.3 Azure Virtual WAN Architecture & Hub Routing

Azure Virtual WAN (vWAN) is an enterprise networking service that brings networking, security, and routing functionalities together into a single unified operational interface. By automating large-scale hub-and-spoke connectivity over Microsoft's global dark fiber backbone, Virtual WAN eliminates the administrative complexity of managing discrete VNets, user-defined route tables, and manual peering topologies.

---

1. Virtual WAN Architecture: Basic vs. Standard Tiers

Virtual WAN is deployed as an overarching orchestration resource containing one or more regional Virtual Hubs. Choosing the correct Virtual WAN tier is fundamental to network architecture.

+---------------------------------------------------------------------------------------------------+
|                                 VIRTUAL WAN ARCHITECTURAL TIERS                                   |
|                                                                                                   |
|  BASIC VIRTUAL WAN:                                                                               |
|  * Single Hub per region                                                                          |
|  * Site-to-Site (S2S) VPN Only                                                                    |
|  * NO Spoke-to-Spoke Transit                                                                      |
|  * NO ExpressRoute, NO P2S User VPN, NO Secure Hub                                                |
|                                                                                                   |
|  STANDARD VIRTUAL WAN:                                                                            |
|  * Any-to-Any Global Transit (VNet-to-VNet, Branch-to-VNet, Branch-to-Branch)                      |
|  * Multi-Hub Inter-Region Full Mesh (Automated Backbone Routing)                                  |
|  * Full Gateway Suite: S2S VPN, ExpressRoute, P2S User VPN (OpenVPN/Entra ID)                     |
|  * Custom Hub Route Tables (Associations, Propagations, Labels)                                   |
|  * Secure Virtual Hub (Azure Firewall / NVA Integration via Routing Intent)                       |
+---------------------------------------------------------------------------------------------------+

Tier Comparison Matrix

[!TIP] Exam Upgrade Rule: You can upgrade a Basic Virtual WAN to a Standard Virtual WAN seamlessly through the Azure Portal or CLI. However, you cannot downgrade a Standard Virtual WAN back to Basic without deleting and recreating all hubs and connections.

---

2. Virtual Hub Architecture & Scale Units

A Virtual Hub is a Microsoft-managed virtual network deployed in a specific Azure region. Unlike standard customer-managed hub VNets, you do not deploy VMs, subnets, or manual route tables inside a Virtual Hub. Microsoft manages the underlying routing infrastructure.

Core Virtual Hub Constructs

1. Hub Address Prefix: A dedicated IPv4 address block (e.g., /24 or /23) assigned during hub creation. The minimum supported prefix size is /24.
2. Virtual Router: The managed routing engine inside the hub that handles dynamic route calculation, BGP propagation, and transit packet forwarding, delivering up to 50 Gbps aggregate throughput per hub.
3. Scale Units (Capacity Sizing):
   • VPN Gateway Scale Units: Sized from 1 Scale Unit (500 Mbps, 2 instances) up to 40 Scale Units (20 Gbps).
   • ExpressRoute Gateway Scale Units: Sized from 1 Scale Unit (2 Gbps) up to 10 Scale Units (20 Gbps).
   • User VPN (P2S) Scale Units: Sized from 1 Scale Unit (500 Mbps) up to 40 Scale Units (20 Gbps, 10,000 connections).

---

3. Hub-to-Hub Inter-Region Full Mesh Routing

In a Standard Virtual WAN with multiple Virtual Hubs deployed across different Azure regions (e.g., East US, West Europe, Southeast Asia), Azure automatically interconnects all Virtual Hubs in a full mesh over Microsoft's global private dark fiber backbone.

+---------------------------------------------------------------------------------------------------+
|                         MULTI-HUB GLOBAL INTER-REGION FULL MESH ROUTING                           |
|                                                                                                   |
|          +----------------------------+             +----------------------------+                |
|          |  Virtual Hub 1 (East US)   | <=========> | Virtual Hub 2 (West Europe)|                |
|          |  Prefix: 10.100.0.0/23     | (Auto Mesh) | Prefix: 10.102.0.0/23      |                |
|          +--------------+-------------+             +--------------+-------------+                |
|                         ^                                          ^                              |
|                          \                                        /                               |
|                           \                                      /                                |
|                            v                                    v                                 |
|                            +------------------------------------+                                 |
|                            |   Virtual Hub 3 (Southeast Asia)   |                                 |
|                            |   Prefix: 10.104.0.0/23            |                                 |
|                            +------------------------------------+                                 |
|                                                                                                   |
|   * Spoke VNet in East US communicates with Spoke VNet in Tokyo via Microsoft global backbone.     |
|   * Branch connected via S2S VPN to Hub 1 can reach Branch connected via ExpressRoute to Hub 2.   |
+---------------------------------------------------------------------------------------------------+

Global Transit Capabilities

• Spoke-to-Spoke Across Regions: Workload VMs in an East US spoke communicate directly with VMs in a West Europe spoke without deploying cross-region VNet peerings or intermediary NVA routers.
• Branch-to-Branch (Any-to-Any): An on-premises office connected via S2S VPN to the East US hub can route traffic directly to a corporate datacenter connected via ExpressRoute to the West Europe hub.

---

4. Custom Route Tables: Associations vs. Propagations

Virtual WAN provides granular traffic segmentation and isolation using Custom Virtual Hub Route Tables.

Key Routing Concepts: Associations and Propagations

+---------------------------------------------------------------------------------------------------+
|                          ROUTE TABLE ASSOCIATIONS vs. PROPAGATIONS                                |
|                                                                                                   |
|   +-------------------------------------------------------------------------------------------+   |
|   | CONNECTION (VNet Spoke, S2S VPN, ExpressRoute, P2S User VPN)                              |   |
|   +---------------------------------------------+---------------------------------------------+   |
|                                                 |                                                 |
|             [ ASSOCIATION (1-to-1) ]            |            [ PROPAGATION (1-to-Many) ]          |
|                         |                       |                         |                       |
|                         v                       |                         v                       |
|   +-----------------------------------------+   |   +-----------------------------------------+   |
|   | Destination Lookup Route Table          |   |   | Advertises its prefix INTO:             |   |
|   | * Which route table does this           |   |   | * Default Route Table                   |   |
|   |   connection use to forward packets?    |   |   | * Production Route Table                |   |
|   | * Exactly ONE Route Table per Connection|   |   | * Shared Services Route Table           |   |
|   +-----------------------------------------+   |   +-----------------------------------------+   |
+---------------------------------------------------------------------------------------------------+

Operational Rules

1. Association (1-to-1):
   • Defines the route table the connection looks up to make packet forwarding decisions.
   • Each VNet connection, VPN gateway, or ExpressRoute circuit can be associated with exactly one route table at a time.
2. Propagation (1-to-Many):
   • Defines which route table(s) the connection advertises its IP address prefixes into.
   • A connection can propagate its routes to zero, one, or multiple route tables simultaneously.
3. Labels:
   • A Label is a metadata tag used to group route tables across multiple hubs (e.g., Production_Label).
   • Configuring a connection to propagate to a Label ensures its prefixes are automatically injected into all route tables carrying that label across all regional hubs in the Virtual WAN.

Architectural Isolation Scenario: Production vs. Development

To completely isolate Production VNets from Development VNets while allowing both to access Shared Services and On-Premises:

---

5. Secure Virtual Hub & Routing Intent

A Secure Virtual Hub is an Azure Virtual WAN hub that contains an integrated security appliance—either a managed Azure Firewall or an integrated third-party Network Virtual Appliance (e.g., Fortinet, Check Point, Palo Alto)—deployed directly inside the hub infrastructure.

+-------------------------------------------------------------------------------------------------+
|                                 SECURE VIRTUAL HUB ARCHITECTURE                                 |
|                                                                                                 |
|   +-----------------------------------------------------------------------------------------+   |
|   | Secure Virtual Hub (East US)                                                            |   |
|   |                                                                                         |   |
|   |  +-----------------------------------------------------------------------------------+  |   |
|   |  | Azure Firewall (Integrated Directly inside Hub Infrastructure)                    |  |   |
|   |  | Managed via Centralized Azure Firewall Manager Security Policies                  |  |   |
|   |  +-----------------------------------------------------------------------------------+  |   |
|   |                                           ^                                             |   |
|   |       [ Routing Intent: Private Traffic ] | [ Routing Intent: Internet Traffic ]        |   |
|   |                                           v                                             |   |
|   |  +-----------------------------------------------------------------------------------+  |   |
|   |  | Virtual Router Engine (Automated Next-Hop Injection to Azure Firewall)            |  |   |
|   |  +-----------------------------------------------------------------------------------+  |   |
|   +-------------------------------------+-----------------------------------+---------------+   |
|                                         |                                   |                   |
|                                         v                                   v                   |
|   [ Spoke VNet A (10.1.0.0/16) ] <============== (Inspected Traffic) ============> [ On-Prem ]  |
|   [ Spoke VNet B (10.2.0.0/16) ] <=============> [ Azure Firewall ] ============> [ Internet ] |
+-------------------------------------------------------------------------------------------------+

Routing Intent & Routing Policies Deep Dive

Traditionally, forcing traffic through a firewall required creating and maintaining complex User-Defined Routes (UDRs) across dozens of spoke subnets. Routing Intent replaces manual route configuration with high-level declarative routing policies configured via Azure Firewall Manager:

1. Internet Traffic Policy:
   • When configured with next hop set to Azure Firewall, the Virtual WAN hub automatically generates and advertises a default route (0.0.0.0/0) to all connected spoke VNets and on-premises branch gateways.
   • All outbound public internet traffic is inspected and filtered by the Azure Firewall before egressing.
2. Private Traffic Policy:
   • When configured with next hop set to Azure Firewall, all private address prefixes (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and RFC 6598 100.64.0.0/10) are automatically routed to the Azure Firewall.
   • Enforces deep packet inspection (East-West traffic) for VNet-to-VNet, VNet-to-Branch, Branch-to-VNet, and Branch-to-Branch communication across the entire global WAN fabric with zero manual UDRs.