Skip to main content
ExpressRoute Global Reach lets you link multiple ExpressRoute circuits across regions to create a private, global WAN overlay on the Microsoft backbone. This capability enables on-premises sites in different geographic areas to communicate privately via Microsoft’s network — avoiding the public internet and improving predictability, security, and performance. Key benefits:
  • Private, low-latency connectivity between on-premises sites across regions or countries.
  • Centralized control of global traffic even when different local carriers are used at each site.
  • Extended reach with Premium or add-on SKUs for multi-region and cross-continental connectivity. Local SKUs are limited to metro or same-region routing.
  • Option to use ExpressRoute Direct for dedicated physical connections into Microsoft’s backbone when maximum control and availability are required.
A network diagram titled "Using Cross-Region Connectivity to Link Multiple ExpressRoutes" showing ExpressRoute Global Reach linking two Azure regions (US West and UK South) and their VNets to on-premises sites. It shows San Francisco (10.0.1.0/24) and London (10.0.2.0/24) connected via regional circuits to VNets (10.0.3.0/24 and 10.0.4.0/24).

​
How Global Reach works (real-world behavior)

ExpressRoute Global Reach creates a private WAN overlay by linking the private peerings of two or more ExpressRoute circuits. Traffic from your on-premises networks is carried across Microsoft’s global network between those circuits rather than traversing the public internet. Example:
  • Circuits in Tokyo and Silicon Valley can be linked so the offices communicate privately across Microsoft’s backbone.
  • Different local carriers may peer with Microsoft at each location; Global Reach keeps the inter-site traffic private and centrally managed.
A diagram titled "ExpressRoute Global Reach" showing Microsoft Global Network connected via ExpressRoute sites (Tokyo, Hong Kong, Silicon Valley) to local service providers and a US service provider. The graphic also shows example IP subnets (e.g., 192.168.11.24/29, 192.168.11.16/30, 192.168.11.20/30).

​
Important considerations

Global Reach is not available in every region. Confirm regional availability and SKU requirements (Local vs. Standard vs. Premium) in Microsoft’s documentation before designing your deployment: https://learn.microsoft.com/en-us/azure/expressroute/expressroute-global-reach
When designing Global Reach, keep these factors in mind:
  • SKU and licensing: Premium/add-on SKUs enable cross-continent and multi-region routing; Local SKUs restrict routing scope.
  • Private peering configuration: ASN, VLAN IDs, and IPv4 primary/secondary subnets must be configured correctly on each circuit.
  • IP addressing for the Global Reach interconnect: choose a dedicated subnet for the Global Reach peer to avoid overlap with existing networks.
  • Security and isolation: you can optionally configure a shared key for the Global Reach pairing for additional validation.

​
ExpressRoute SKU comparison

SKUTypical Use CaseRouting Scope
LocalSingle metro or regional connectivityLimited to same metro/region
StandardRegional connectivity with more featuresMultiple regions within same geography
Premium / Add-onGlobal multi-region and cross-continent connectivityBroad global routing across Microsoft backbone

​
Configuring ExpressRoute Global Reach (high level)

  1. Verify private peering on each ExpressRoute circuit:
    • Confirm peer ASN, VLAN ID, and primary/secondary IPv4 subnets.
  2. In the Azure portal, open the ExpressRoute circuit you want to enable Global Reach for.
  3. Navigate to Private Peering or the Global Reach configuration area.
  4. Click Add Global Reach. In the dialog:
    • Enter a Global Reach name.
    • Select the peer ExpressRoute circuit to link (the circuit in the other office/region).
    • Specify the Global Reach subnet for the interconnect.
    • Optionally enter a shared key for additional security.
  5. Repeat Add Global Reach for each pairing you require.
  6. Save and validate connectivity. After configuration, on-premises networks connected to the paired circuits will route across Microsoft’s backbone.
The portal UI below shows the Private Peering panel and the Add Global Reach dialog where you choose the peer circuit and configure the Global Reach subnet.
A screenshot of the Azure portal showing configuration screens for ExpressRoute Global Reach: the Private Peering panel with fields like Peer ASN, IPv4 primary/secondary subnets, VLAN ID and an "Add Global Reach" button. The right side shows the "Add Global Reach" dialog with Global Reach name, ExpressRoute circuit selection, Global Reach subnet and an "Add" button.
Best practices:
  • Use a non-overlapping, small subnet (for example, /30 or /29) for the Global Reach interconnect to simplify routing.
  • Validate end-to-end routing with BGP route tables after enabling Global Reach.
  • Document carrier and circuit details for each location to aid troubleshooting.

​
Validation and troubleshooting checklist

  • Confirm BGP sessions for private peering are established on all circuits.
  • Check route tables and BGP advertisements to ensure on-premises prefixes are visible across the linked circuits.
  • Verify ACLs and firewall rules allow the expected traffic between sites.
  • If traffic does not flow, check SKU limitations, regional availability, and whether Global Reach pairing has been accepted on both circuits.

​
Summary

ExpressRoute Global Reach turns separate ExpressRoute circuits into a secure, private global network overlay on Microsoft’s backbone, enabling predictable, lower-latency inter-site connectivity without traversing the public internet. Plan for SKU limits and regional availability, configure private peering carefully, and validate BGP routes after pairing circuits. Other ExpressRoute features include ExpressRoute Direct, ExpressRoute FastPath, and link redundancy options. For more details, see:

Watch Video