Recommend a Connectivity Solution that Connects Azure Resources to On-Premises Networks — Lesson

A large international retailer's IT team negotiates two complementary contracts in the same quarter. The first contract is for a 1 Gbps ExpressRoute circuit from their primary datacenter to Azure West Europe — 24-month commit at several thousand dollars per month from a chosen carrier partner. The second is a fallback Site-to-Site VPN over the public internet — pennies per month relative to the carrier circuit, configurable for up to roughly 1 Gbps of throughput per tunnel. Both contracts go live in the same week. Three months later, fibre work near the datacenter accidentally cuts the ExpressRoute circuit for roughly 6 hours. Traffic fails over to the VPN automatically via BGP route withdrawal; end users barely notice anything. The double-pipe was the architect's most-important hybrid-connectivity decision: ExpressRoute for the primary path's reliability and SLA, VPN for cheap insurance against the inevitable circuit interruption. This lesson is about choosing the right hybrid connectivity — VPN Gateway, ExpressRoute, Azure Virtual WAN, Azure Route Server, plus the redundancy pattern around each one — for every on-prem-to-Azure path the architecture needs.

We will work through Azure's hybrid-connectivity story the way the AZ-305 exam expects you to: choosing between site-to-site VPN, point-to-site VPN, ExpressRoute (Local / Standard / Premium / Direct / Metro), Virtual WAN topologies, and BGP / Route Server patterns. Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill $4.4 on network solutions, plus Microsoft Learn's hybrid-connectivity articles.

Why This Matters

Hybrid connectivity is the foundation of any non-greenfield Azure adoption — and a quiet majority of Azure customers are non-greenfield. Picking the wrong service or sizing the wrong tier creates rolling operational pain: a VPN that can't handle peak load, an ExpressRoute circuit that overruns the budget, a single-tunnel topology that fails completely with one fibre cut, a circuit provisioned in the wrong metro for the workload. The AZ-305 exam tests this LO because the choices made early — circuit sizing, peering type, redundancy approach, hub-spoke vs Virtual WAN, BGP configuration — are operationally expensive to change later, sometimes requiring multi-week disruption windows to fix.

The career payoff is concrete: every hybrid migration project, every "we need on-prem to talk to Azure" requirement, every "our VPN keeps dropping" complaint, every regulated workload that requires private connectivity touches this LO. If you can match the connectivity requirement (bandwidth, latency, SLA, geography, partner WAN integration, DNS hybridisation needs) to the right service and design redundancy correctly with active-active VPN or dual-circuit ExpressRoute, you will pass this slice of the exam and design hybrid topologies like a senior architect.

Prerequisites

• BGP basics. Can you describe how BGP advertises routes between peers? — Self-check: what is an AS number?
• IPsec / IKE. Are you familiar with site-to-site VPN protocols? — Self-check: what's the difference between IKEv1 and IKEv2?
• Azure VNet basics. Do you know subnet and gateway-subnet roles? — Self-check: what's the special subnet name for VPN/ExpressRoute gateways?
• WAN MPLS / private circuits. Have you encountered carrier MPLS? — Self-check: what does an L3 MPLS service provide?
• Hub-spoke topology. Are you familiar with it? — Self-check: which VNet typically hosts the gateway?

If any of these feels shaky, pause and review the hybrid-networking primer in Unit 4 of the AZ-305 guide before continuing — hybrid connectivity is the prerequisite layer that most other LOs depend on once any on-prem element is involved.

Learning Objectives

1. Analyse a hybrid-connectivity requirement (bandwidth, latency, SLA, geography, security, DNS hybridisation, identity integration) and translate it to the right Azure service.
2. Evaluate trade-offs between site-to-site VPN, point-to-site VPN, the five ExpressRoute SKUs (Local, Standard, Premium, Direct, Metro), and Virtual WAN topologies.
3. Design a resilient hybrid topology with active-active VPN tunnels and ExpressRoute redundancy across multiple metros.
4. Recommend between hub-spoke + VPN/ExpressRoute Gateway vs Azure Virtual WAN for a given branch-count + region-count combination.
5. Configure Azure Route Server for dynamic-routing scenarios (NVAs, SD-WAN) and integrate with on-prem BGP peers.
6. Recognise anti-patterns — single-tunnel VPN for tier-1 workloads, Basic SKU gateways in production, missing zone-redundancy, ExpressRoute without VPN backup — and rewrite them.

Building Blocks

Site-to-Site (S2S) VPN — IPsec tunnel between an on-prem VPN device and Azure VPN Gateway. Formally, Microsoft.Network/virtualNetworkGateways of type Vpn. Traffic over the public internet, encrypted. Tiers Basic / VpnGw$1{-}5$ / VpnGw$1{-}5$AZ (zone-redundant). It matters as the cheap, internet-based hybrid path.

Point-to-Site (P2S) VPN — Single-client VPN from a user's device to Azure (OpenVPN, IKEv2, or SSTP). Useful for remote developers. Same gateway as S2S can also serve P2S.

ExpressRoute — Private, dedicated connectivity from on-prem to Azure via a connectivity provider. Formally, Microsoft.Network/expressRouteCircuits plus expressRouteGateways in Azure VNets. Bandwidth 50 Mbps to 100 Gbps. SLA 99.95%. It matters because ExpressRoute is the canonical low-latency, high-SLA, predictable-bandwidth hybrid path.

ExpressRoute peering — Two types: private peering (to your VNets), Microsoft peering (to Microsoft public services like Office 365 — though use of MS peering for these is now mostly discouraged). It matters because the peering choice determines what ExpressRoute carries.

ExpressRoute SKUs — Local (paired-region only, cheaper), Standard (regional + global Reach for inter-region), Premium (global reach to any region, more route entries, increased connections), Direct (10 / 100 Gbps physical ports for the largest customers), Metro (newer, supplies redundant peering points within a metro area for higher resilience).

Azure Virtual WAN — A managed hub-and-spoke WAN service. Formally, Microsoft.Network/virtualWans with virtualHubs, each containing VPN / ExpressRoute / firewall components. Multi-region by design. It matters because Virtual WAN replaces hand-built hub-spoke with VPN + ExpressRoute attached, especially for global customers with many branches.

Azure Route Server — A managed BGP-route-exchange endpoint inside a VNet. Formally, Microsoft.Network/virtualHubs (for VWAN) or Microsoft.Network/virtualNetworks/virtualHubs (in classic VNets). Lets NVAs / SD-WAN appliances inject and learn routes via BGP without managing UDRs. It matters when third-party NVAs are part of the hybrid path.

Global Reach — An ExpressRoute feature that connects two on-prem sites via Microsoft's backbone. Formally, an ExpressRouteCircuitConnection between two circuits in different metros. It matters because Global Reach turns ExpressRoute into a private WAN between branches at lower cost than dedicated carrier links.

FastPath — An ExpressRoute feature that bypasses the VNet gateway in the data path, reducing latency by $\\sim 10\\times$ for high-throughput workloads. Requires Premium / Ultra SKU and Direct port. It matters for HPC / SAP HANA / heavy data egress.

Deep Dive

1. VPN vs ExpressRoute — pick by SLA + bandwidth needs

[!TIP] The defence-in-depth pattern is ExpressRoute primary + S2S VPN backup. ExpressRoute provides daily-driver SLA + bandwidth; VPN provides cheap fallback for fibre cuts and provider outages.

2. ExpressRoute SKU ladder

[!IMPORTANT] Premium adds global reach to any region and lifts limits on route entries ($4{,}000$ vs $10{,}000$ IPv4) and VNet connections (10 vs 100). Multi-region enterprises typically need Premium.

3. VPN Gateway SKUs

[!WARNING] Basic SKU is being retired (alongside Basic Public IP). Production VPN must be VpnGw1AZ or higher.

4. Azure Virtual WAN — when to skip hand-built hub-spoke

Virtual WAN gives you a managed hub-and-spoke WAN: each region has a virtual hub with VPN / ExpressRoute / firewall components; spoke VNets attach to hubs; hubs interconnect over Microsoft's backbone.

5. Redundancy patterns

Hybrid connectivity is a frequent single point of failure. Best practices:

[!TIP] The most-tested AZ-305 recommendation: dual ExpressRoute circuits at two MSEE locations + VPN backup. The triple-pipe pattern survives any single failure including a regional MSEE.

6. Azure Route Server — BGP injection for NVAs

When you deploy a third-party NVA (e.g., Cisco Catalyst 8000v, Palo Alto VM-Series) in Azure, it needs to inject routes into the Azure SDN. Without Route Server you manage routes manually via UDRs. With Route Server the NVA peers via BGP and Azure SDN learns routes dynamically.

[!NOTE] Route Server is the supported way to integrate SD-WAN appliances with Azure VNets. Without it, manual UDR management becomes brittle as topology grows.

7. ExpressRoute Direct and FastPath

For customers needing $\\ge 10$ Gbps, ExpressRoute Direct provides 10 Gbps or 100 Gbps physical ports at Microsoft Enterprise Edge sites. Combined with FastPath, packets bypass the VNet gateway in the data path, achieving wire-speed throughput.

8. Cost — VPN vs ExpressRoute

[!IMPORTANT] ExpressRoute always has a separate provider charge (carrier port + transport). Plan budget with that in mind — the Microsoft fee is only half the picture.

Worked Examples

Easy — pick the path

Problem. A small office needs 50 Mbps connection to Azure with 99.9% availability. Cost matters. Recommend.

Solution. Active-active S2S VPN with VpnGw1AZ (650 Mbps headroom). Cheap and quick to deploy; the active-active configuration meets 99.95% SLA per Microsoft.

Medium — global enterprise

Problem. A multinational has datacenters in Frankfurt, New York, and Singapore. Needs predictable bandwidth, regional connectivity, and inter-branch communication. Recommend.

Solution. Azure Virtual WAN with three virtual hubs (Frankfurt, New York, Singapore region). ExpressRoute Premium circuits from each on-prem DC to the local Virtual Hub. Hubs interconnect via Microsoft backbone (built-in). Optional S2S VPN backup per region.

Hard — high-bandwidth analytics workload

Problem. An HPC workload needs $\\ge 20$ Gbps from on-prem to Azure with sub-millisecond added latency. Recommend.

Solution. ExpressRoute Direct 100 Gbps port at a Microsoft Enterprise Edge site near the on-prem facility. Allocate 20 Gbps sub-circuit. Enable FastPath (Premium/Ultra SKU) to bypass the gateway in the data path. Place Azure-side compute in the same region as the MSEE to minimise added latency.

9. DNS in hybrid topologies

Hybrid connectivity is only half done until DNS works in both directions. Azure private DNS zones link to VNets; on-prem DNS resolvers need conditional forwarders for *.privatelink.*.azure.com and other Azure-specific zones. Azure Private Resolver (a managed Azure-side DNS service) provides inbound and outbound endpoints so on-prem DNS can query Azure-private records and vice versa.

Without DNS hybrid, applications can reach hosts by IP but not by name — fragile and operationally painful.

10. Identity and on-prem integration

Hybrid connectivity often pairs with hybrid identity. Common patterns:

Place the cross-realm trust where it makes the fewest hops: Entra ID and Entra Domain Services in Azure when possible, with on-prem AD as the source of truth for legacy applications.

11. Routing and BGP fundamentals for hybrid

Azure-side routing in hybrid topologies has three sources of truth:

If a UDR conflicts with a BGP route, the UDR wins. This is a frequent source of confusion when an architect inherits a topology with both UDRs and BGP — the UDR overrides the carefully-tuned BGP routing decisions.

[!WARNING] When BGP is enabled on ExpressRoute / VPN, prefer letting BGP propagate routes and remove conflicting UDRs. Mixing the two only when absolutely necessary (e.g., to force traffic through an NVA) and document the override clearly.

12. ExpressRoute Direct port allocation

For very large customers, ExpressRoute Direct provides physical ports at Microsoft Enterprise Edge sites. Once a Direct port is provisioned, the customer can carve sub-circuits out of it:

Sub-circuits can be allocated to different subscriptions / departments — useful for chargeback in large enterprises. The Direct port itself is a Microsoft-billed asset; the sub-circuit bandwidth is metered separately.

Visual Explanations

Figure 1 — Hybrid decision flow

Figure 2 — Multi-region Virtual WAN

Figure 3 — Quick chooser

Figure 4 — Site-to-Site VPN topology with active-active

A typical active-active VPN deployment has two public IPs on the gateway, two tunnels to the on-prem VPN device (which itself must support two IPsec endpoints), and BGP enabled for dynamic failover. Each tunnel carries half the traffic during normal operation; on a single-tunnel failure, the surviving tunnel absorbs full load without operator intervention. The architecture costs slightly more (two public IPs, more compute) but increases the per-circuit SLA from 99.9% to 99.95%.

Figure 5 — Multi-region hybrid with ExpressRoute Global Reach

For an enterprise with two on-prem datacenters and Azure regions in each metro, the production pattern combines four ExpressRoute circuits: one per DC-to-Azure-region (total 2), and Global Reach connections between the two on-prem circuits over Microsoft's backbone. The Global Reach link replaces a dedicated WAN circuit between the two on-prem sites — at typically $\frac{1}{3}$ to $\frac{1}{2}$ the cost — and gives sub-50-ms inter-DC latency in many regions.

This pattern also delivers high availability: a fibre cut between DC1 and Azure Region 1 doesn't isolate DC1 from anywhere, because traffic re-routes via DC2 $\to$ Azure Region 2 $\to$ Microsoft backbone $\to$ Azure Region 1.

Figure 6 — Virtual WAN secured-hub option

Virtual WAN supports a secured virtual hub where Azure Firewall (Standard or Premium) is deployed natively into the hub. All VNet-to-VNet, VNet-to-internet, and branch-to-VNet traffic can be policy-inspected by the hub firewall. The secured hub option simplifies the security architecture for VWAN customers — no separate hub VNet needed, no UDR plumbing to force traffic through the firewall.

Figure 7 — ExpressRoute monitoring metrics

Key metrics on an ExpressRoute circuit and the corresponding alerting thresholds:

When BitsInPerSecond regularly exceeds 80% of provisioned bandwidth, plan to upgrade the circuit before users start noticing congestion symptoms.

Common Mistakes

❌ Myth: "One VPN tunnel is fine." ✅ Reality: A single tunnel is a single failure. Active-active is the production minimum.

❌ Myth: "ExpressRoute alone is enough." ✅ Reality: Even ExpressRoute fails (fibre cuts, carrier issues). Pair with VPN backup or dual-metro ER circuits.

❌ Myth: "Basic VPN Gateway is OK for low-volume." ✅ Reality: Basic is retiring and lacks BGP / active-active. Use VpnGw1AZ minimum.

❌ Myth: "ExpressRoute Local is cheaper, so default to it." ✅ Reality: Local is paired-region only. Multi-region customers need Standard or Premium for global reach.

Practice Exercises

🟢 Exercise 1. A branch office needs 100 Mbps Azure connectivity. Recommend.

▶✅ Solution

S2S VPN with VpnGw1AZ active-active. Cost-effective and meets bandwidth.

🟡 Exercise 2. A global enterprise with 40 branches needs interconnect. Recommend.

▶✅ Solution

Azure Virtual WAN with regional hubs; ExpressRoute Premium from major sites, VPN from smaller branches.

🟡 Exercise 3. A workload needs 25 Gbps + low latency. Recommend.

▶✅ Solution

ExpressRoute Direct with Premium SKU and FastPath enabled.

🔴 Exercise 4. A team needs ExpressRoute to survive an MSEE outage in their primary metro. Recommend.

▶✅ Solution

ExpressRoute Metro SKU — provides dual-MSEE peering within the metro. Alternative: dual circuits at two different metros, which is more redundant but more expensive.

🔴 Exercise 5. A team deploys a Palo Alto NVA in the hub VNet. Routes need to be advertised to all spokes dynamically. Recommend.

▶✅ Solution

Azure Route Server. Peer the NVA via BGP; routes propagate to attached VNets automatically.

🟢 Exercise 6. True or false: ExpressRoute Premium is required to reach a region outside your circuit's metro pair.

▶✅ Solution

True (with Global Reach nuance). Premium adds global reach to any region; Local is restricted to paired-region only; Standard supports Global Reach to specific regions but Premium is the simplest answer for any-region.

🟡 Exercise 7. Sketch Bicep for active-active VpnGw2AZ.

▶✅ Solution

bicepCopy

resource pip1 'Microsoft.Network/publicIPAddresses@2024-03-01' = { name: 'pip-vpngw1' location: location sku: { name: 'Standard' } zones: ['1','2','3'] properties: { publicIPAllocationMethod: 'Static' } } resource vpngw 'Microsoft.Network/virtualNetworkGateways@2024-03-01' = { name: 'vpngw-prod' location: location properties: { gatewayType: 'Vpn' vpnType: 'RouteBased' sku: { name: 'VpnGw2AZ', tier: 'VpnGw2AZ' } activeActive: true enableBgp: true ipConfigurations: [ /* two ipConfigurations referencing pip1 and pip2 */ ] } }

Figure 8 — Subnet sizing for gateway subnets

Both VPN Gateway and ExpressRoute Gateway require a dedicated subnet named GatewaySubnet. The minimum size is /29 (8 addresses) but Microsoft strongly recommends /27 (32 addresses) or larger to allow future SKU upgrades that require more underlying IPs. The exam tests this subnet-sizing rule:

Naming is exact and case-sensitive. Deviating produces deployment failures with cryptic errors.

Figure 9 — When to choose Virtual WAN over hub-spoke

Virtual WAN's strengths shine when the architecture has many branches or regions. For single-region single-DC customers, classic hub-spoke with a VPN/ExpressRoute Gateway is simpler and cheaper. The decision boundary roughly:

Summary & Concept Map

• VPN for cheap / fallback; ExpressRoute for SLA + bandwidth. Combine for resilience.
• Active-active is the production VPN minimum. Basic SKU is retiring.
• Virtual WAN replaces hand-built hub-spoke for global / multi-branch enterprises.
• ExpressRoute Premium gives global reach and higher limits. Direct gives $\\ge 10$ Gbps + FastPath.
• Route Server handles BGP for NVAs / SD-WAN.
• Triple-pipe (dual-ER + VPN) is the most-tested resilient pattern.