1. Peering Limitations & Transit Routing
🔑 Non-Transitive by Default
VNet peering is non-transitive. If VNet-A peers with VNet-B, and VNet-B peers with VNet-C, traffic from A cannot reach C through B — unless you explicitly configure routing (UDRs + NVA or gateway transit).
Gateway Transit
A hub VNet with a VPN/ExpressRoute gateway can share that gateway with peered spoke VNets via Allow Gateway Transit (hub side) and Use Remote Gateways (spoke side). This lets spokes reach on-premises without their own gateway.
Hub-Spoke Implications
- Spoke-to-spoke traffic: Does NOT flow through peering alone. Requires an NVA or Azure Firewall in the hub + UDRs on each spoke pointing 0.0.0.0/0 or specific CIDRs to the NVA.
- Gateway transit is one-hop only: A spoke cannot use gateway transit through a peered hub to reach another hub's gateway (no chaining).
- Peering is non-overlapping: Address spaces of peered VNets must not overlap. Plan CIDR carefully.
- Cross-region peering (global): Works identically but incurs inter-region bandwidth charges and slightly higher latency.
Traditional hub-spoke: spoke-to-spoke traffic must traverse the firewall/NVA. Gateway transit allows spokes to reach on-premises through the hub gateway.
2. VPN Gateway vs ExpressRoute — Decision Matrix
| Criterion | VPN Gateway (S2S/P2S) | ExpressRoute | Virtual WAN |
|---|---|---|---|
| Bandwidth | Up to ~10 Gbps (VpnGw5) | Up to 100 Gbps (Direct) | Up to 20 Gbps per hub (aggregated) |
| Latency | Variable (internet path) | Predictable, low (private path) | Low (MS backbone) |
| Encryption | IPsec always on | Not encrypted by default (MACsec for Direct) | IPsec for VPN; ER not encrypted |
| Compliance | Adequate for most; encrypted | Required for some regs (data never on public internet) | Meets both; depends on connection type |
| Cost | $$ (gateway + egress) | $$$$ (port fee + circuit + provider) | $$$ (hub hourly + connection units) |
| Redundancy | Active-active; zone-redundant SKUs | Dual circuits recommended; zone-redundant GW | Built-in multi-hub; auto-failover |
| Setup Complexity | Low — self-service | High — provider involvement, cross-connects | Medium — managed by Azure, less UDR work |
| Best For | Dev/test, small offices, quick hybrid | Production workloads, large data transfers, regulated industries | Multi-branch, global orgs needing any-to-any |
🔑 When ExpressRoute Beats VPN
- Bandwidth: You need >1 Gbps sustained throughput
- Latency SLAs: Real-time workloads (SAP HANA replication, financial trading)
- Compliance: Regulations prohibit data traversal over public internet
- Cost at scale: Egress-heavy workloads — ER Unlimited can be cheaper than metered internet egress
- Reliability: 99.95% SLA with redundant circuits vs best-effort internet
3. ExpressRoute: Global Reach, FastPath & Peering Types
Private Peering vs Microsoft Peering
- Private peering: Connects to your Azure VNets (10.x, 172.x address spaces). This is what most people think of as "ExpressRoute."
- Microsoft peering: Connects to Microsoft 365, Dynamics 365, Azure PaaS public endpoints (Storage, SQL). Replaces the deprecated "public peering."
Global Reach
Connects two ExpressRoute circuits together so on-premises sites can communicate through the Microsoft backbone — without hairpinning through Azure VNets. Example: London office ↔ Sydney office via ER Global Reach, bypassing VPN over internet.
FastPath
Bypasses the ExpressRoute gateway for data-plane traffic, sending packets directly to VMs. Reduces latency for high-throughput scenarios.
- Requires Ultra Performance or ErGw3AZ gateway SKU
- Does NOT support VNet peering — only works for VMs in the gateway VNet itself (or the directly connected VNet in newer preview)
- Does not support UDRs on the GatewaySubnet for FastPath traffic
ExpressRoute + VPN Coexistence
You can deploy both on the same VNet for redundancy: ER as primary, S2S VPN as failover. BGP ensures automatic failover. This is a common exam scenario.
4. Virtual WAN: When It Replaces Custom Hub-Spoke
Azure Virtual WAN is a Microsoft-managed networking service that provides any-to-any transit connectivity. It replaces the need to manually build hub VNets, NVAs for routing, and UDRs for spoke-to-spoke traffic.
Key Capabilities
- Any-to-any connectivity: Spokes, branches (VPN), and ER circuits auto-route to each other
- Hub auto-mesh: Multiple hubs in different regions automatically route between each other over the MS backbone
- Integrated SD-WAN: Partners (Barracuda, Cisco, etc.) can inject branch CPE config automatically
- Scale: Supports hundreds of branches, thousands of spokes per hub
- Routing intent: Simplifies security by routing all traffic (internet + private) through a hub firewall/NVA
Virtual WAN: multi-hub topology with auto-mesh. Branches, ER circuits, and VNet spokes all achieve any-to-any connectivity without custom UDRs.
5. Virtual WAN vs Traditional Hub-Spoke Trade-offs
| Aspect | Traditional Hub-Spoke | Virtual WAN |
|---|---|---|
| Routing control | Full control via UDRs, NVAs, BGP | Managed routing; less granular (routing intent helps) |
| NVA flexibility | Any NVA from marketplace | Limited NVA partners in hub; or use spoke NVA with routing intent |
| Spoke-to-spoke | Manual UDRs + NVA required | Automatic — built-in transit |
| Multi-region | Manual hub-to-hub peering + routing | Auto-mesh between hubs |
| Scale | Limited by NVA throughput, UDR limits (400 routes) | Managed scale — thousands of connections |
| Cost | Pay for NVA VMs, gateway SKU | Pay per hub-hour + connection unit + data processed |
| Complexity | High — many moving parts to maintain | Lower — Microsoft manages gateway lifecycle |
| Best for | Small-medium orgs; need deep NVA customization | Large enterprises; many branches; global footprint |
🔑 Choose Virtual WAN When…
- You have >10 branch sites needing automated connectivity
- You want any-to-any transit without managing UDR tables
- You're deploying multi-region and need hub-to-hub auto-mesh
- You use SD-WAN partners and want integrated provisioning
🔑 Stick with Traditional Hub-Spoke When…
- You need specific NVA vendors not supported in vWAN hubs
- You require granular UDR control (e.g., traffic engineering per subnet)
- You have a simple topology (1 hub, 3–5 spokes, 1 VPN connection)
- Budget constraints — vWAN per-hub cost may exceed a single NVA for small deployments
6. Hybrid DNS: Conditional Forwarding Across VPN/ER
In hybrid networks, DNS resolution must work bidirectionally:
Azure → On-Premises
- Deploy Azure DNS Private Resolver (or DNS forwarder VMs) in the hub VNet
- Configure DNS forwarding rulesets to forward on-prem domains (e.g.,
corp.contoso.com) to on-prem DNS servers (reachable via VPN/ER) - Link rulesets to spoke VNets so all workloads resolve on-prem names
On-Premises → Azure Private Endpoints
- On-prem DNS servers need conditional forwarders for Azure private DNS zones (e.g.,
privatelink.blob.core.windows.net) - Forward to the Azure DNS Private Resolver's inbound endpoint IP (in hub VNet)
- Ensure the inbound endpoint is reachable from on-prem via VPN/ER
Architecture Pattern
7. Real-World: Multi-Region Enterprise with DR
📋 Scenario
Contoso Financial has 3 offices (New York, London, Singapore), a primary data center (New Jersey), and needs Azure connectivity with DR in a secondary region.
Requirements
- NJ data center → Azure (high bandwidth, <10ms latency for SAP replication)
- All offices need access to Azure workloads and each other
- Regulatory: financial data must not traverse public internet
- DR: active-passive in East US 2, failover <15 min RTO
- Budget: optimize for reliability, not lowest cost
Solution Design
- ExpressRoute (NJ DC → East US): 10 Gbps circuit with redundant connections (two different peering locations). Private peering for VNet access. ErGw3AZ gateway (zone-redundant, FastPath-capable).
- Virtual WAN Standard: Two hubs — East US (primary) and East US 2 (DR). Auto-mesh gives inter-hub routing.
- Branch connectivity: NY office → S2S VPN to East US hub. London → ExpressRoute via Equinix London to East US hub. Singapore → S2S VPN to East US hub (consider ER if latency matters).
- Global Reach: NJ DC ↔ London office communicate via ER Global Reach (backbone-to-backbone, no Azure transit needed for inter-office traffic).
- DR: Spoke VNets replicated in East US 2 hub. ASR for VM replication. ER circuit has connection to both hubs. DNS failover via Traffic Manager + Private DNS zone auto-registration.
- DNS: Azure DNS Private Resolver in each hub. On-prem DNS forwards privatelink.* zones to resolver inbound endpoint. Resolver outbound rules forward corp.contoso.com to NJ DC DNS.
Why Not Traditional Hub-Spoke?
With 3+ branches, 2 regions, and any-to-any requirements, manually managing UDRs and NVA HA across regions is error-prone. Virtual WAN's auto-mesh and integrated ER/VPN gateways reduce operational overhead significantly.
Knowledge Check
Q1: Spoke VNet A is peered to Hub, and Spoke VNet B is peered to Hub. What's needed for A↔B communication?
Reveal Answer
An NVA or Azure Firewall in the Hub + UDRs on both spokes pointing each other's address space to the NVA IP. Peering alone is non-transitive — traffic from A to B won't traverse the hub without explicit routing. Alternatively, use Virtual WAN which provides this transit automatically.
Q2: A company needs 5 Gbps sustained throughput between their DC and Azure, with data that cannot traverse the public internet. Which connectivity option?
Reveal Answer
ExpressRoute — provides private connectivity (never public internet), supports up to 100 Gbps (Direct), and meets compliance requirements. VPN Gateway max is ~10 Gbps and always uses internet paths.
Q3: Two on-premises sites (London and Tokyo) each have their own ExpressRoute circuit to Azure. How can they communicate directly without routing through an Azure VNet?
Reveal Answer
ExpressRoute Global Reach — connects the two ER circuits so on-prem traffic flows over the Microsoft backbone directly between sites. No need to hairpin through Azure VNets or deploy VPN between sites.
Q4: An enterprise has 50 branch offices, 3 Azure regions, and wants automated any-to-any connectivity. Traditional hub-spoke or Virtual WAN?
Reveal Answer
Virtual WAN — at this scale, managing UDRs, NVA HA, and hub-to-hub routing manually is unsustainable. Virtual WAN provides auto-mesh between hubs, integrated VPN/ER gateways, SD-WAN partner integration, and automatic any-to-any routing.