ExpressRoute at Scale: What Happens When One Circuit Isn't Enough

Most ExpressRoute deployments start with a single circuit. It's sufficient for the initial workload, the bandwidth fits, and the redundancy model — primary and secondary connections built into every circuit — feels like it covers the failure scenarios that matter. Then the environment grows. More workloads move to Azure, bandwidth demands increase, a second region comes online, or a peering location maintenance window causes an outage that the "redundant" circuit didn't protect against.

That's when teams discover that one circuit was never really enough — and that scaling ExpressRoute introduces routing complexity that requires deliberate design, not incremental patching.

The Redundancy Misconception

Every ExpressRoute circuit includes a primary and secondary connection — two BGP sessions, two physical paths to the Microsoft edge. Most architects treat this as full redundancy. It isn't.

Both connections terminate at the same peering location. A facility outage, a provider maintenance window, or a misconfigured BGP session at that location takes both connections down simultaneously. The primary/secondary model protects against link failures and single-path disruptions — it does not protect against peering location failures or provider-level incidents that affect both paths.

If your architecture depends on ExpressRoute for critical workloads, single-location redundancy is a design gap, not a design choice.

When One Circuit Stops Being Enough

These are the conditions that force the conversation:

• Bandwidth saturation — A single circuit's throughput ceiling is fixed. As workloads migrate and data transfer volumes grow, a saturated circuit creates latency and packet loss that no gateway configuration can resolve. The circuit itself is the bottleneck.

• Single peering location risk — One facility, one provider, one logical failure domain. Any disruption at the peering location — power, hardware, provider incident — eliminates connectivity regardless of the primary/secondary configuration.

• Multi-region Azure footprint — A single circuit can connect to VNets in multiple regions, but traffic destined for a distant region backhauled through one circuit creates latency that violates application SLOs. Regional proximity matters at scale.

• Gateway throughput limits — The ExpressRoute gateway, not the circuit, is often the actual bottleneck. Standard gateway SKUs top out at 1 Gbps. Ultra Performance reaches 10 Gbps. When your circuit has capacity your gateway can't use, the circuit investment is wasted.

• Compliance and SLA requirements — Some regulatory frameworks require geographic diversity in connectivity paths. A single peering location doesn't satisfy those requirements regardless of how many connections terminate there.

Multi-Circuit Design Options

Standard Circuit — Primary/Secondary the baseline. Every ExpressRoute circuit includes two connections to the Microsoft edge at the same peering location. Protects against link failures and single-path disruptions. Does not protect against peering location failures. This is the right starting point — not a finished redundancy design for critical workloads.

ExpressRoute Metro closes the single peering location gap without requiring two fully separate circuits. A single Metro circuit connects to two different peering locations within the same metropolitan area — geographic diversity at the metro level on one logical circuit.

• Single circuit, two diverse paths — One circuit, one billing relationship, one set of BGP sessions. The diversity is built into the circuit design itself rather than managed across two independent circuits.

• Active/active by default — Both peering locations carry traffic simultaneously. No passive standby wasting capacity — aggregate bandwidth across both paths is fully usable.

• Metro-level protection, not regional — Protects against facility and provider incidents within the metro. Does not protect against a provider outage spanning the entire metropolitan area or against regional Azure incidents. For environments requiring regional diversity, Metro complements a multi-region circuit strategy rather than replacing it.

• Availability is limited — ExpressRoute Metro is available in select cities only. Verify availability for your specific peering locations before designing around it.

• Ideal fit — Organizations that need peering location diversity without the cost and operational complexity of managing two independent circuits. A meaningful step up from standard dual-connection redundancy.

Dual Circuits, Same Provider, Different Peering Locations

Two circuits from the same provider, each terminating at a geographically separate peering locations, is the most common scaling pattern for environments that have outgrown single-circuit redundancy. Both circuits are active simultaneously, with BGP path manipulation controlling how traffic is distributed across them. This design protects against facility-level outages and provides additional aggregate bandwidth that a single circuit can't deliver.

• Active/active configuration uses full capacity of both circuits

• Active/passive configuration keeps one as standby — simpler to reason about but wastes capacity

• AS path prepending on the passive circuit steers inbound traffic to the preferred path without manual failover

Dual Circuits, Different Providers

Two circuits from separate providers at separate locations. Maximum resilience — a provider-level incident that takes down one circuit leaves the other unaffected. The trade-off is operational complexity: two provider relationships, two billing models, and two sets of BGP sessions to manage. Justified for environments where connectivity loss carries significant financial or compliance impact.

ExpressRoute + VPN Coexistence

A secondary S2S VPN as a failover path for ExpressRoute. Lower cost than a second ExpressRoute circuit, but with meaningful limitations:

• VPN throughput is capped at 1.25 Gbps per tunnel for the highest SKU — insufficient as a full failover path for high-bandwidth environments

• Latency is higher over VPN than ExpressRoute — applications with strict latency requirements will degrade during failover

• BGP route preferences must be configured carefully to ensure VPN only activates on ExpressRoute failure, not alongside it

• Useful as a cost-effective failover for non-latency-sensitive workloads — not a substitute for a second ExpressRoute circuit for critical paths

  
  

ExpressRoute Direct

Dedicated physical ports on the Microsoft global network — 10 Gbps or 100 Gbps — without a provider intermediary. Eliminates the provider as a failure domain and removes bandwidth constraints for high-throughput workloads. The trade-off is cost and operational ownership: you're responsible for the physical cross-connect and port management that a provider otherwise handles.

Choosing the Right Option

Scenario	Recommended Approach
Single location, basic redundancy	Standard circuit — primary/secondary
Metro-level facility diversity, single provider	ExpressRoute Metro
Full provider diversity or regional separation	Dual circuits, separate providers/locations
On-premises multi-site connectivity	Global Reach
High throughput, no provider intermediary	ExpressRoute Direct
Non-critical failover at lower cost	ExpressRoute + VPN coexistence

Global Reach: Connecting On-Premises Sites Through Microsoft

ExpressRoute Global Reach allows two on-premises networks — each connected to Azure via their own ExpressRoute circuit — to communicate through the Microsoft backbone without backhauling traffic through your Azure VNets.

When it earns its place:

• Multi-site on-premises environments where site-to-site traffic currently traverses Azure as transit

• Replacing expensive MPLS links between geographically distributed offices with Microsoft backbone connectivity

• Reducing latency for on-premises-to-on-premises traffic by routing through Microsoft's network rather than the public internet

• 
  

What to know before you enable it:

• Not available at all peering locations — verify availability for your specific circuit locations before designing around it

• Adds per-GB data transfer cost on top of existing circuit costs

• Traffic flows between the two circuits at the peering location level — routing visibility into that path is limited compared to traffic you manage directly

• Not a substitute for direct on-premises connectivity where low latency is critical — Global Reach adds hops that direct links don't

ExpressRoute FastPath

FastPath bypasses the ExpressRoute gateway for the data path — traffic flows directly from the Microsoft edge to the destination VM without traversing the gateway. The gateway still handles the control plane (BGP, route management) but is removed from the data path entirely.

When it matters:

• High-throughput workloads where gateway bandwidth limits are the bottleneck

• Latency-sensitive applications where the extra hop through the gateway is measurable

• Environments running UltraPerformance or ErGW3AZ gateway SKUs — FastPath is only supported on these

  
  

What it doesn't solve:

• FastPath doesn't support traffic to VMs behind a Standard Internal Load Balancer in some configurations — validate your topology before designing for it

• UDRs on the GatewaySubnet are not supported with FastPath — if your design routes gateway traffic through an NVA, FastPath breaks that pattern

• VNet peering traffic doesn't benefit from FastPath — only traffic destined for VMs in the directly connected VNet

  
  

BGP Route Management at Scale

Multi-circuit ExpressRoute environments require deliberate BGP configuration to control traffic distribution. These are the key levers:

• AS path prepending — Artificially lengthens the AS path on one circuit to make it less preferred for inbound traffic. The standard mechanism for active/passive steering without manual failover intervention.

• BGP community tagging — Microsoft advertises Azure prefixes with well-known BGP communities you can use to filter routes by region. Allows you to accept only the routes relevant to your regional footprint rather than the full Azure prefix table — important for keeping route tables manageable across multiple circuits.

• Local preference — Controls outbound traffic path preference when both circuits are active. Higher local preference on one circuit steers outbound traffic to that path. Combined with AS path prepending on the inbound side, this gives you full control over traffic distribution in both directions.

• Route filters for Microsoft peering — If you're using Microsoft peering for Office 365 and other Microsoft services, route filters control which service prefixes are advertised to your network. Without them, you receive the full Microsoft service prefix table — operationally unmanageable at scale.

Gateway Sizing: The Bottleneck You Don't Expect

The circuit gets the attention, but the gateway is often where scale problems actually surface. Microsoft has introduced a new ErGwScale SKU that replaces the older fixed-tier SKUs with an autoscaling model. If you're still running Standard, High Performance, or Ultra Performance gateways, Microsoft now requires migration to ErGwScale through a dedicated migration tool.

Gateway SKU	Max Throughput	Zone Redundant	FastPath	Notes
Standard	1 Gbps	No	No	Legacy — migrate to ErGwScale
High Performance	2 Gbps	No	No	Legacy — migrate to ErGwScale
Ultra Performance	10 Gbps	No	Yes	Legacy — migrate to ErGwScale
ErGW1AZ	1 Gbps	Yes	No	Zone-redundant fixed tier
ErGW2AZ	2 Gbps	Yes	No	Zone-redundant fixed tier
ErGW3AZ	10 Gbps	Yes	Yes	Zone-redundant fixed tier
ErGwScale	Up to 40 Gbps	Yes	Yes	Latest — autoscaling, recommended

ErGwScale is the SKU to design around for any new deployment if available within your region:

• Autoscaling via scale units — Scales from a minimum of 1 unit to a maximum of 40, with each unit providing incremental throughput capacity. You pay for what you use rather than provisioning a fixed tier for peak demand.

• Up to 40 Gbps — Significantly higher ceiling than any previous fixed-tier SKU, accommodating high-throughput workloads without needing ExpressRoute Direct.

• Zone-redundant by default — Built-in AZ resilience without selecting a separate AZ-specific SKU.

• FastPath supported — Bypasses the gateway data path for qualifying traffic, reducing latency for high-throughput workloads.

• Cost scales with scale units — The autoscaling model is an advantage for variable workloads but requires active monitoring. Scale units that ramp up under peak load and don't scale back down translate directly into unexpected cost. Set scaling boundaries that reflect your actual traffic patterns and review them regularly — don't treat the 40-unit ceiling as a safe default. For environments with predictable, stable throughput, compare the ErGwScale cost at your expected scale unit range against the equivalent fixed-tier SKU before committing. The flexibility is valuable, but unmanaged autoscaling is a FinOps risk.

Common Design Mistakes

• Treating primary/secondary as geographic redundancy — Both paths terminate at the same peering location. Geographic redundancy requires circuits — or a Metro circuit — at separate locations.

• Not testing BGP failover — BGP convergence takes time, and failover behavior under real conditions is often different from what was designed. Test deliberately, not during an incident.

• Overlooking the GatewaySubnet UDR restriction — UDRs on the GatewaySubnet are not supported in most configurations and cause routing failures. A well-known limitation that still catches teams during NVA integration designs.

• Single peering location for compliance workloads — Regulatory frameworks requiring geographic diversity need circuits at geographically separate peering locations. ExpressRoute Metro is the lowest-friction way to satisfy this requirement without managing two independent circuits.

• Adding circuits without reviewing BGP route tables — Each additional circuit adds BGP routes that need to be managed. Without route filters and community-based policies, route tables grow to a scale that becomes difficult to reason about.

• Sizing the gateway after the circuit — Gateway throughput limits are the actual ceiling in many environments. Size the gateway first, then the circuit.

Bottom Line

A single ExpressRoute circuit with primary and secondary connections is a good starting point, not a finished design. The scenarios that expose its limits — facility outages, bandwidth saturation, multi-region footprints, gateway bottlenecks — are predictable, and so are the costs of addressing them. A second circuit, a Metro upgrade, or an ErGwScale gateway all carry real price tags that compound quickly if chosen without a clear traffic and redundancy model. The right architecture isn't just the one that meets your resilience requirements — it's the one that meets them without over-provisioning capacity you won't use. Size the gateway before the circuit, design the redundancy model before selecting the SKU, and let actual traffic patterns drive scale decisions rather than worst-case assumptions.