Azure ExpressRoute: Private Dedicated Connectivity

ExpressRoute vs VPN: the fundamental difference

A VPN Gateway encrypts your traffic and sends it over the public internet. The encryption is strong, but you still depend on ISPs, public routing infrastructure, and internet congestion for delivery. Latency varies, packet loss happens, and path changes occur silently.

ExpressRoute bypasses the public internet entirely. Your traffic enters a connectivity provider’s network at a physical location (a colocation facility, your data center, or a provider’s edge POP), traverses the provider’s infrastructure to a Microsoft peering location, and then rides Microsoft’s private global backbone to the Azure region hosting your workload. No ISP handoffs, no public routing decisions, no shared infrastructure with internet traffic.

The practical consequences: ExpressRoute delivers consistent latency (often under 5 ms to nearby regions), predictable bandwidth, and the ability to certify that regulated data never transits internet infrastructure — a hard requirement for some financial, healthcare, and government workloads.

Connectivity models

How your network physically reaches the Microsoft peering location depends on which connectivity model you use:

Co-location at a cloud exchange. If your equipment is in a colocation facility that also houses a Microsoft peering location (Equinix, Digital Realty, CoreSite, and others), a physical cross-connect is ordered between your cage and Microsoft’s edge router. This is the fastest to provision and often the lowest cost per Mbps.

Point-to-point Ethernet. A telco or network provider runs a dedicated Ethernet link from your office or data center to a Microsoft peering location. You do not need to be in the same building as the peering location. The provider handles the physical infrastructure between the two points.

Any-to-any (IPVPN / MPLS). Your existing MPLS WAN provider extends your corporate WAN to include Azure sites as additional nodes on the WAN. This is the simplest option for organisations that already operate a large MPLS network — the Azure connection looks like another WAN site.

ExpressRoute Direct. A direct 10 Gbps or 100 Gbps physical port on Microsoft’s edge router at a peering location. You bring your own routers to the colocation facility. This is for extremely high-bandwidth requirements (media ingest, large-scale data migration, financial market data) and for organisations that need MACsec layer-2 encryption.

Circuit SKUs: Local, Standard, and Premium

Local SKU is compelling if you only need to reach Azure resources in one region and your data transfer costs would be high with metered billing. Standard is the right choice for most enterprises. Premium is required only if you need global reach to Azure regions across geopolitical boundaries (e.g., accessing US Azure from a European ExpressRoute circuit).

Peering types

An ExpressRoute circuit can carry two different types of peering, each serving a different traffic type:

Azure private peering connects your on-premises network to your Azure VNets using private IP addresses. VMs, databases, and private endpoints in your VNets are reachable through private peering. This is the peering type that most organisations configure first. It works in conjunction with an ExpressRoute Gateway deployed in your hub VNet.

Microsoft peering connects to Microsoft’s public services — Azure Storage public endpoints, Azure SQL public endpoints, and Microsoft 365 services — but routes traffic over the ExpressRoute circuit instead of the internet. The traffic uses public IP addresses (yours and Microsoft’s), but it does not traverse the public internet. Required if you want Office 365, Exchange Online, or SharePoint Online traffic to use the private circuit.

Provisioning flow

ExpressRoute provisioning is a multi-party process. The steps cannot be done entirely in the Azure portal — your connectivity provider must complete their side before the circuit becomes operational.

Step 1: Create the circuit in Azure. In the Azure portal, navigate to ExpressRoute circuits and create a new circuit. Select your provider, the peering location (the physical facility where the Microsoft edge is), circuit bandwidth, and SKU. Azure creates the circuit object and generates a service key.

Step 2: Provide the service key to your provider. Share the service key with your connectivity provider. This key identifies your circuit in Microsoft’s provisioning system. The provider uses it to complete their provisioning — this may involve ordering physical cross-connects, allocating port capacity, and configuring VLAN trunking.

Step 3: Wait for provider provisioning. The circuit’s provider status changes from “Not Provisioned” to “Provisioning” to “Provisioned.” This step takes days to weeks depending on the provider and the physical work required.

Step 4: Configure BGP peering. Once the provider side is provisioned, configure Azure private peering in the Azure portal. Specify a /30 subnet for the primary BGP session and another /30 for the secondary, your router’s ASN, and a VLAN ID.

Step 5: Connect a VNet. Deploy an ExpressRoute Gateway (use a zone-redundant AZ SKU) in the hub VNet’s GatewaySubnet, then create a connection from the gateway to the circuit.

Global Reach: connecting offices via Microsoft backbone

Global Reach enables two ExpressRoute circuits to exchange routes through Microsoft’s backbone, effectively creating a private WAN link between your two locations without requiring a separate MPLS WAN or VPN.

Example: a bank with offices in London and New York, each with an ExpressRoute circuit connecting to Azure. With Global Reach, traders in London can reach trading systems in New York over the Microsoft backbone — consistent latency, private path, no separate WAN circuit needed. Both offices still connect to Azure as normal; Global Reach adds the inter-office routing on top.

Global Reach requires Premium SKU circuits and is billed per GB of data transferred across the backbone between the two peering locations.

Cost model: what you are actually paying for

ExpressRoute has multiple cost components that are easy to underestimate:

Circuit fee: A fixed monthly charge based on bandwidth and SKU. A 1 Gbps Standard circuit might run $1,000–$2,000/month depending on the region and provider.

Connectivity provider cost: Your provider charges separately for the physical circuit and any colocation, cross-connect, or MPLS WAN fees. This is often as large as or larger than the Azure circuit fee.

Data transfer (metered): With MeteredData billing, you pay per GB of data transferred from Azure to on-premises. Inbound (on-premises to Azure) is free. UnlimitedData circuits include all egress at a higher flat monthly rate.

Gateway cost: The ExpressRoute Gateway runs continuously. ErGw1AZ costs roughly $400–$500/month. ErGw2AZ and ErGw3AZ are progressively higher.

Redundancy and SLA

Each ExpressRoute circuit has two physical paths — a primary and a secondary — that connect to two separate Microsoft edge routers at the peering location. BGP sessions run over both. Your on-premises router must connect to both paths for the circuit to qualify for Microsoft’s SLA.

For higher resilience, deploy two circuits: one in your primary location and one in a geographically separate location or using a different provider. Pair this with a zone-redundant ExpressRoute Gateway (ErGw1AZ or higher) to ensure the Azure-side gateway itself survives an availability zone failure.

The combination of VPN Gateway (as backup) + ExpressRoute (as primary) is common in enterprises. When ExpressRoute is healthy, all traffic uses the private circuit. If the circuit fails, BGP metrics cause traffic to fall back to the VPN tunnel automatically.