Azure ExpressRoute Direct: Field Notes from the Enterprise Trenches

Blog ENG - MS Azure - Post 5 2025

When a regulated customer asks for “deterministic latency, physical isolation, and enough headroom that we stop talking about bandwidth,” I don’t reach for another VPN. I reach for Azure ExpressRoute Direct, a design choice that trades complexity for control, and delivers a private on‑ramp straight into Microsoft’s global backbone.

What ExpressRoute Direct really is (and why it’s different)
Most teams first meet ExpressRoute via a service provider: the carrier stands up the physical path to a Microsoft peering location and you create circuits on top. ExpressRoute Direct skips that intermediary: you reserve dual 10‑Gbps or 100‑Gbps ports on Microsoft edge (MSEE) routers at a peering location and lay your own cross‑connects. That gives you active‑active links and the ability to carve multiple circuits from the same port pair for different business units or workloads. This model shines when you need large data ingestion (think storage or analytics), tight regulatory isolation, or granular circuit distribution across teams (all common asks in financial services, healthcare, and large retailers).

The “why now” moment: cost and locality
An underrated advantage in the current architecture playbook is ExpressRoute Local. When your workloads and peering location sit in the same metro, Local keeps traffic within the area, avoiding backbone traversal and packing a cost‑efficiency punch (Local SKU includes an Unlimited data plan by design, and egress within the metro is part of that plan). In practice, I’ve used Local with Direct to cut predictable costs for region‑bound workloads while keeping performance rock‑solid.

How you get in (without getting stuck)
There are a few steps that separate an architectural sketch from light hitting fiber:
– Enroll the subscription for Direct (“AllowExpressRoutePorts”) and verify the “Microsoft.Network” provider registration (no enrollment, no ports).
– Create the ExpressRoute Direct resource in the Azure portal (choose peering location, 10/100‑Gbps port pair, encapsulation: Dot1Q or QinQ).
– Generate the LOA/CFA from Azure and work with the facility to pull dual single‑mode fiber cross‑connects to Microsoft’s routers.
– Bring the links up in active‑active, then layer your ExpressRoute circuits on top (each with its own bandwidth and BGP sessions).

Tip from the field: encapsulation choice matters. QinQ gives you clean circuit separation with S‑Tags assigned per circuit (useful when you expect high circuit density on a single port pair).

Security you can actually prove: MACsec on Direct ports
Even though ExpressRoute traffic is private, many CISOs (rightly) ask for encryption on the wire. With Direct, enable MACsec on the physical links to Microsoft, store keys in Azure Key Vault, and automate rotation. It’s straightforward and auditable, two qualities that make conversations with auditors a lot shorter.

Routing domains, peering, and the stuff that breaks if you rush it
ExpressRoute is Layer‑3 BGP end‑to‑end. You’ll typically enable:
– Private peering to reach VNets and IaaS resources; plan IPv4 /30 peering subnets per path (and optionally IPv6 /126). Keeping your peering VLANs unique avoids asymmetric routing later.
– Microsoft peering for public Microsoft services (Azure PaaS, M365). Use route filters and a dedicated edge to avoid sneaky asymmetry with your Internet egress.

Redundancy is not optional: Microsoft provides dual connections to dual MSEE routers at every peering location; run them active‑active so the backbone can distribute flows and you actually use the resilience you’re paying for.

Going global without cobbling a WAN: ExpressRoute Global Reach
When you operate multiple sites with their own ExpressRoute circuits, Global Reach links those circuits together so your branches talk privately through Microsoft’s backbone (no DIY transit in Azure VNets, no backhaul over your MPLS). If the circuits span different geopolitical regions, you’ll need Premium SKU on both. I’ve used Global Reach for M&A scenarios to stitch networks quickly while the long‑term WAN strategy is still being negotiated.

Design patterns I recommend (and deploy)
– Multi‑facility diversity in the same metro. Place each Direct port pair in separate colocation sites when the city supports it; you get protection against facility‑level incidents (power, fiber cuts). I’ve seen this design keep RTOs honest during city‑wide hiccups.
– Two circuits, two peering locations for tier‑1 workloads. It’s the simplest way to buy latency and failure domain isolation. Connect your ExpressRoute gateway to both circuits.
– BFD on edge routers and site‑to‑site VPN as interim backup during maintenance events or single‑circuit phases. Pragmatic resilience beats theoretical HA.

Monitoring that catches problems before people do
Enable Network insights for ExpressRoute and wire up Connection Monitor to track latency, loss, and path health across private and Microsoft peering. It’s the quickest way to pinpoint whether drops live on your side, the provider, or Microsoft’s edge (useful when multiple teams share accountability).

Pricing and SKUs: architect with a calculator, not a guess
ExpressRoute circuits come in Local, Standard, and Premium SKUs:
– Local: Unlimited data plan by default; ideal for metro‑bound workloads.
– Standard/Premium: Choose Metered or Unlimited. Ingress is free (except when you enable Global Reach); Outbound included on Unlimited, charged per GB on Metered. Factor provider fees and gateway costs into your total TCO model.

For Direct, remember you pay a monthly port fee in addition to circuit charges; design the circuit mix (bandwidths, SKUs) around workload profiles rather than a single “big pipe”.

A compact checklist (my go‑to pre‑deployment steps)
– Subscription & provider registration (“AllowExpressRoutePorts”, “Microsoft.Network”).
– Peering location selection based on latency and facility diversity.
– Encapsulation: Dot1Q vs QinQ, decide early.
– LOA/CFA & cross‑connect logistics: book fiber early, verify optics and single‑mode requirements.
– Circuit SKUs & data plans aligned to traffic patterns; model with the Azure pricing calculator.
– Private/Microsoft peering details: VLAN IDs, ASNs, IPv4/IPv6 peering subnets, route filters.
– Resiliency: multiple circuits/locations, active‑active, BFD, interim VPN.
– Security: MACsec on Direct ports; Key Vault for secrets; rotation cadence.
– Monitoring: Network insights + Connection Monitor; alerts on loss/latency.

Final thoughts
As an architect, I treat ExpressRoute Direct as a deliberate commitment: you’re choosing to own the physical path and the logical segmentation because your workloads, regulators, or scale justify it. The payoff is tangible: predictable performance, audit‑friendly isolation, and design flexibility that’s hard to match with a pure provider model. If that’s the hill your business stands on, Direct isn’t just a networking feature; it’s part of your operating model.