ExpressRoute Use Cases
ExpressRoute provides private connectivity between on-premises networks and Microsoft cloud services through a connectivity provider or ExpressRoute Direct. Use it for predictable private connectivity, high bandwidth, enterprise WAN integration, and workloads where internet VPN is not enough.
ExpressRoute Types: Local, Direct, Premium, and Standard
ExpressRoute Local is the cost-focused circuit SKU for reaching Azure regions in the same metro area as the selected peering location; use it when workloads are deliberately kept local and you want circuit traffic without separate data-transfer charges, but do not need cross-region reach. ExpressRoute Standard is the normal choice for most hybrid networks because a circuit can reach supported Azure regions within the same geopolitical region, such as all regions in Europe from a European peering location. ExpressRoute Premium is an add-on to a Standard circuit, not a separate physical connection: choose it when the circuit must connect across geopolitical boundaries or when you need higher limits for advertised routes and linked virtual networks. ExpressRoute Direct is different from the three circuit SKUs because it describes how you connect: instead of consuming a provider-managed circuit, you receive a dedicated, redundant 10-Gbps, 100-Gbps, or 400-Gbps port pair into the Microsoft global network and then provision Local, Standard, or Premium circuits on those ports. Direct is intended for very high data ingestion, physical isolation, multiple business units, or organizations that need direct control of the connectivity stack; it is usually excessive for an ordinary branch or datacenter connection. For the exam, remember the decision rule: choose Local for one metro and lower transfer cost, Standard for normal regional Azure reach, Premium for global reach or larger limits, and Direct for dedicated high-capacity physical ports. See Microsoft Learn for the circuit SKU distinctions and the ExpressRoute Direct architecture.
FastPath, Global Reach, Direct, and Local
These four ExpressRoute options are all current, but they are not alternatives at the same architectural layer. ExpressRoute FastPath optimizes traffic between an on-premises network and Azure virtual networks by sending supported data-plane traffic directly to virtual machines and other supported endpoints instead of through the ExpressRoute virtual network gateway. The gateway remains in the design for route exchange and control-plane functions, so choose FastPath when the requirement is lower latency, higher throughput, or reduced gateway data-path bottlenecks. ExpressRoute Global Reach connects on-premises networks that are attached to different ExpressRoute circuits, carrying site-to-site traffic across Microsoft's global backbone; choose it when two offices or datacenters must communicate privately through their circuits without building a separate WAN path between them. ExpressRoute Direct supplies dedicated redundant physical port pairs into Microsoft at a peering location and is appropriate for very high capacity, physical isolation, large-scale ingestion, or granular circuit control. ExpressRoute Local is a circuit SKU that restricts access to one or more Azure regions near the peering location and includes data transfer in the circuit plan, making it suitable when workloads remain in the local metro and global or geopolitical-region reach is unnecessary. A scenario about accelerating on-premises-to-VNet traffic points to FastPath; connecting two on-premises sites points to Global Reach; dedicated 10-Gbps, 100-Gbps, or 400-Gbps physical connectivity points to Direct; and localized Azure access with predictable transfer cost points to Local.
| Option | Architectural purpose | Scenario signal |
|---|---|---|
| FastPath | Bypasses the ExpressRoute gateway for supported VNet data-plane traffic. | Improve on-premises-to-Azure workload latency or throughput. |
| Global Reach | Links on-premises networks through separate ExpressRoute circuits over the Microsoft backbone. | Connect branch or datacenter sites to each other. |
| Direct | Provides dedicated redundant physical ports into the Microsoft network. | Require extreme capacity, isolation, or direct port and circuit control. |
| Local | Limits a circuit to nearby Azure regions with an included-data billing model. | Keep Azure connectivity local and avoid broader regional or global reach. |
Microsoft references: ExpressRoute FastPath, ExpressRoute Global Reach, ExpressRoute Direct, and ExpressRoute Local.
ExpressRoute Components
| Component | Purpose |
|---|---|
| Circuit | Logical connection ordered in a peering location with a bandwidth and SKU. |
| Private peering | Connectivity to Azure VNets through private IP addresses. |
| Microsoft peering | Connectivity to Microsoft public services through public prefixes and route filters. |
| ExpressRoute gateway | Connects a VNet to an ExpressRoute circuit. |
| FastPath | Optimizes data path so traffic bypasses the gateway for supported scenarios. |
| Global Reach | Connects on-premises sites through ExpressRoute circuits. |
Circuit Sharing, Subscriptions, and VNet Connections
An ExpressRoute circuit is not tied to one department or one Azure subscription. A single circuit can connect multiple VNets, including VNets in different subscriptions, provided the circuit SKU can reach their regions and the circuit's connection limits and bandwidth meet the design. Count circuits from connectivity, resiliency, geography, capacity, and administrative requirements, not from the number of subscriptions.
For a VNet in another subscription, the circuit owner creates an authorization and gives its authorization key and circuit resource ID to the VNet owner. The VNet owner creates the connection from its ExpressRoute gateway to the circuit. The authorization delegates the right to create that connection; it does not transfer ownership of the circuit. Each VNet still needs an ExpressRoute gateway unless it consumes a gateway through a supported hub-and-spoke gateway-transit design.
All VNet connections share the circuit's provisioned bandwidth. Standard circuits provide reach within their geopolitical region, Local circuits only reach the associated local Azure region or regions, and Premium extends global reach and raises several limits. Verify current limits before consolidating many VNets onto one circuit. See linking VNets to ExpressRoute circuits.
Configuration Topics
- Select provider model, bandwidth, SKU, billing model, and peering location.
- Configure private peering with VLAN, peer ASN, primary and secondary subnets, and advertised prefixes.
- Configure Microsoft peering and route filters where required.
- Create an ExpressRoute gateway and connect VNets to circuits.
- Recommend route advertisement configuration and avoid overlapping prefixes.
- Configure encryption over ExpressRoute when private connectivity alone is not sufficient.
- Implement Bidirectional Forwarding Detection for faster failure detection.
ExpressRoute and Site-to-Site VPN Coexistence
A VNet can use ExpressRoute as its primary hybrid path and a site-to-site VPN as a backup. This requires two Azure gateway resources in the VNet: an ExpressRoute virtual network gateway and a route-based VPN virtual network gateway. They coexist in the gateway subnet, whose address space must be large enough for both gateway deployments and future upgrades. Policy-based VPN is not the coexistence design.
Both connections can advertise the same on-premises prefixes, but Azure normally prefers an ExpressRoute-learned route over a VPN-learned route for the same prefix. When the ExpressRoute BGP path is withdrawn, the VPN path can become active. Design and test the reverse path as well: the on-premises routers must also prefer ExpressRoute during normal operation and fail to VPN without creating asymmetric routing.
Coexistence is path redundancy, not automatic end-to-end disaster recovery. Use redundant provider paths and ExpressRoute connections, zone-redundant gateways where required, redundant on-premises VPN devices, BGP, health monitoring, and documented failback behavior. See ExpressRoute and VPN coexistence.
Troubleshooting ExpressRoute
- Check provider status and circuit provisioning state.
- Verify BGP sessions on primary and secondary paths.
- Review advertised routes and learned routes.
- Check route filters for Microsoft peering.
- Check VNet gateway health, SKU, and connection status.
- Watch for asymmetric routing when VPN, ExpressRoute, and internet paths coexist.
Azure Virtual WAN
Virtual WAN is a managed global network architecture for branch, user, VNet, VPN, and ExpressRoute connectivity. It is a good answer when the scenario has many branches, many hubs, centralized routing, secured hubs, or simplified large-scale connectivity operations.
Virtual WAN Design Points
- Select Basic or Standard Virtual WAN. Standard is needed for advanced routing and hub connectivity scenarios.
- Create virtual hubs in regions close to workloads and branches.
- Choose scale units for VPN, ExpressRoute, and point-to-site gateways.
- Configure virtual hub route tables, labels, propagation, and association.
- Deploy Azure Firewall into a secured virtual hub where centralized inspection is required.
- Integrate third-party NVAs where vendor-specific SD-WAN or security features are required.
Decision Table
| Requirement | Likely answer |
|---|---|
| Private, predictable connection to Azure VNets | ExpressRoute private peering |
| Many branches with managed hub routing | Azure Virtual WAN |
| Need VPN backup for private circuit | ExpressRoute plus site-to-site VPN failover design |
| Need Microsoft SaaS public service routes | Microsoft peering with route filters |
Feature Deep Dive
Private Peering
Private peering connects on-premises networks to Azure VNets using private IP addresses. This is the main ExpressRoute pattern for IaaS and private Azure workloads. The VNet still needs an ExpressRoute gateway unless FastPath applies for supported traffic optimization.
Microsoft Peering
Microsoft peering is for Microsoft public services. It requires public IP addressing and route filters for service route control. Do not confuse it with private endpoint access. Private endpoints are reached through private peering because they live as private IPs in VNets.
FastPath
FastPath improves data-plane performance by bypassing the ExpressRoute gateway for supported traffic. The gateway is still required for route exchange and control-plane operations. In exam wording, FastPath usually appears with high-throughput or latency-sensitive private connectivity.
Virtual WAN Routing
Virtual WAN abstracts many of the pieces you would otherwise build manually in a hub-spoke architecture. Its route tables, labels, propagation, and associations decide which connections learn which routes. In secured hubs, routing intent can steer private and internet traffic through Azure Firewall.
ExpressRoute vs VPN vs Virtual WAN
| Service | Strength | Tradeoff |
|---|---|---|
| Site-to-site VPN | Fast to deploy, encrypted over internet, cost-effective | Internet dependency and less predictable performance. |
| ExpressRoute | Private predictable connectivity and higher bandwidth | Provider dependency, more planning, usually higher cost. |
| Virtual WAN | Managed scale for many branches, hubs, and connectivity types | Less like hand-built peering; you must understand hub routing model. |
Scenario Workshop: ExpressRoute With Internet Backup
Scenario: A company uses ExpressRoute for production traffic but wants a site-to-site VPN as backup. The risk is asymmetric routing: traffic leaves Azure over ExpressRoute but returns over VPN, or the opposite. The fix is route design, BGP preference, and clear failover behavior.
| Design topic | What to decide |
|---|---|
| Primary path | ExpressRoute should normally advertise preferred routes. |
| Backup path | VPN routes should be less preferred until ExpressRoute fails. |
| Detection | BGP session state and route withdrawal should drive failover. |
| Security | If encryption is required over ExpressRoute, add IPsec or MACsec options depending on design. |
Virtual WAN Routing Mental Model
Virtual WAN is not just "a hub VNet managed by Microsoft." A virtual hub has its own routing model. Connections associate to route tables and propagate routes to route tables. Labels help group route tables. Secured hubs add firewall inspection and routing intent. When troubleshooting Virtual WAN, inspect effective routes on hub connections and confirm route table association and propagation.
When ExpressRoute Is Not The Answer
- The requirement is quick temporary connectivity. VPN may be enough.
- The requirement is individual user remote access. Use point-to-site VPN.
- The requirement is global HTTP application acceleration. Use Front Door.
- The requirement is private PaaS access inside Azure. Use Private Endpoint; ExpressRoute only carries the hybrid path to that private IP.