Skip to main content
When planning an Azure ExpressRoute deployment, evaluate the key design factors that affect availability, performance, and cost. This guide walks through the considerations in the same logical sequence used in operational design reviews so you can make consistent, production-ready choices.

​
1) ExpressRoute gateway SKU

Choose an ExpressRoute gateway SKU that matches your required throughput, resiliency, and feature set. Considerations:
  • Throughput: select a SKU capable of your sustained and peak bandwidth needs (include headroom for growth).
  • Resiliency: check whether the SKU supports availability zones, active/active configurations, or other HA capabilities.
  • Features and connections: ensure the SKU supports the number and type of BGP sessions, VPN fallback, and any cross-region connectivity required.
Tip: For business-critical applications choose higher-capacity SKUs to avoid mid-life migrations. Validate the gateway SKU’s documented maximum tunnels, throughput, and HA behavior in the official Azure docs.

​
2) Metered vs Unlimited data plans and circuit bandwidth

Pick the billing model (metered or unlimited) and the circuit bandwidth that fit your traffic profile. Recommended bandwidth guidance:
Workload profileTypical circuit sizing
Small business, light usage50 Mbps – a few hundred Mbps
Medium workloads, mixed traffic100 Mbps – multi-Gbps
Large enterprise / heavy data or backup/DRMulti-Gbps (10 G and above)
High-throughput, direct-cloud interconnect10 G / 100 G (ExpressRoute Direct)
Factors to consider:
  • Growth and burst capacity to avoid frequent resizing.
  • Metered vs unlimited: choose metered for predictable low-volume transfers; unlimited if you expect heavy or unpredictable outbound traffic.
  • Regional availability of ExpressRoute Direct (10 G / 100 G) and provider support.

​
3) Routing and peering

Define your peering and BGP strategy early — it determines what services you can reach and how traffic flows. Peering summary:
Peering typePurposeTypical use cases
Private PeeringLayer-3 connectivity to virtual networksVNet access, private services hosted in VNets
Microsoft PeeringAccess to Microsoft public servicesMicrosoft 365, Azure PaaS endpoints, Office, Dynamics
BGP design checklist:
  • ASN plan: choose private/public ASNs and ensure they align with provider requirements.
  • Prefix limits and route filters: define maximum prefixes and apply inbound/outbound filters.
  • Community tagging: use BGP communities where supported for traffic engineering and filtering.
  • Authentication and timers: consider BGP MD5 and sensible BGP timers for stabilization.
Sample BGP neighbor configuration (template — replace placeholders with your values): 
! On your edge router (example)
router bgp <YOUR_ASN>
  neighbor <MICROSOFT_EDGE_IP> remote-as <MICROSOFT_ASN>
  neighbor <MICROSOFT_EDGE_IP> description ExpressRoute-private
  neighbor <MICROSOFT_EDGE_IP> timers 30 90
  neighbor <MICROSOFT_EDGE_IP> password <BGP_MD5_PASSWORD>
Always verify exact timer and ASN requirements with your connectivity provider and Azure documentation.

​
4) High availability and redundancy

Design for resilience across both the provider and your own edge infrastructure. Best practices:
  • Use redundant ExpressRoute circuits where possible, ideally via physically diverse paths and different providers.
  • Avoid single points of failure: deploy redundant edge routers and duplicate physical links.
  • Implement failover testing and document runbooks for circuit/provider outages.
  • Consider dual-region VNets or paired-region designs for application-level resilience when appropriate.
Example architectures:
  • Dual circuits from different carriers into the same colocation facility.
  • Dual circuits routed via separate path providers/POP locations to protect against facility failures.

​
5) Connection model choice

Choose the connection model that suits your geography, operations, and provider landscape. Connection options:
ModelDescriptionWhen to use
Cloud Exchange / Co-locationCross-connect from your equipment into an exchangeIf you have colocated equipment and need low-latency, high-control interconnect
Point-to-point EthernetProvider-owned dedicated Ethernet linksFor simple site-to-Microsoft connectivity without co-lo
Provider-mediated IP VPNProvider’s IP VPN offering to reach MicrosoftWhen you prefer provider-managed WAN services
ExpressRoute Direct10 G / 100 G direct physical ports with MicrosoftFor very high throughput or direct peering at scale
Operational concerns:
  • Lead times for circuit provisioning and cross-connects.
  • Who manages the physical cross-connect and the support SLAs.
  • Provider availability in your region and any extra costs for diversity.

​
6) Bidirectional Forwarding Detection (BFD)

BFD provides fast detection of path failure and complements BGP for rapid failover on ExpressRoute. What BFD provides:
  • Sub-second to low-millisecond detection of path troubles (depending on your timers).
  • Quicker switchovers to backup paths compared to relying on BGP timer convergence alone.
  • Reduced application disruption by accelerating failover.
How BFD is used with ExpressRoute:
  • Microsoft’s edge routers have BFD enabled for supported peering types; you must enable and configure BFD on your on-premises routers and bind it to the specific BGP sessions.
  • Apply consistent BFD timers on both primary and secondary routers and validate behavior under failure conditions.
BFD is enabled by default on Microsoft’s edge routers for supported peering types. You must explicitly configure BFD on your on-premises devices and bind it to the corresponding BGP sessions to obtain the rapid failover benefits.
Implementation notes and examples:
  • Align BFD interval and detection multiplier to balance rapid detection and false positives.
  • Test different failure scenarios (link down, interface flap, route withdrawal) to confirm expected behavior.
  • Monitor both BFD and BGP session states and alert on state changes.
Example BFD configuration templates (replace placeholders): Cisco IOS example: 
bfd interval 50 min_rx 50 multiplier 3
!
router bgp <YOUR_ASN>
  neighbor <MICROSOFT_EDGE_IP> remote-as <MICROSOFT_ASN>
  neighbor <MICROSOFT_EDGE_IP> bfd
Juniper (Junos) example: 
set interfaces ge-0/0/0 unit 0 family inet address <LOCAL_IP>/30 bfd-liveness-detection minimum-interval 50 multiplier 3
set protocols bgp group expressroute neighbor <MICROSOFT_EDGE_IP> bfd-liveness-detection
Always check vendor documentation for the exact commands and verify they map to your platform’s capability set.

​
7) Practical pre-deployment checklist

Validate these items before going live.
CheckWhy it mattersAction
Gateway SKUEnsures throughput & HAConfirm SKU supports throughput, HA and features
Circuit bandwidth & billingAvoid performance or billing surprisesChoose metered vs unlimited and circuit size
Peering typesAllows access to required servicesConfigure private and/or Microsoft peering
Redundancy planReduces single-point failuresContract diverse paths/providers, redundant routers
BFD configured & testedEnsures fast failoverEnable BFD on on-prem and run failover tests
Monitoring & runbooksSpeeds incident responseImplement alerts, logging, and recovery procedures

​
Summary

A resilient ExpressRoute deployment balances the right gateway SKU, circuit bandwidth and billing model, peering choices, diverse connectivity, and rapid failover via BFD. Plan BGP and route policies carefully, validate redundancy end-to-end, and document operational procedures. These steps help deliver a highly available, high-performance private connection between your on-premises infrastructure and Azure.

Watch Video