ExpressRoute Global Reach

運用前提: hybrid connectivityはAzure resourceだけで完結しません。Azure / Microsoft edge、connectivity provider・Internet、customer edge、BGP route、VNet effective route、stateful security device、applicationを別failure domainとして観測し、control-planeのSucceededをdata-plane成功の代わりにしません。SKU・limit・availability・preview statusは変わるため、導入時は末尾のcurrent Microsoft Learnも再確認してください。

ExpressRoute Global Reachを理解するための前提

Global Reachは既存ExpressRoute circuitsをlinkし、on-premises site同士をMicrosoft global network経由でprivateに接続する機能。Azure VNet transitそのものではない。 Global Reach connectionはAzure private peeringに関連付けて作成し、site間prefixがBGPを通じて相互到達可能になる。

異なるgeopolitical region間で利用する場合はPremium SKU requirementなどcurrent availability条件を確認する。既存WAN/MPLS/SD-WANとparallel pathになる場合、site-to-site trafficのpreferred pathとreturn pathを明示し、routing loop/asymmetryを避ける。

Global Reachのfailureは元circuitのprovider/location failureと依存する。2 sitesを繋いだだけで各siteのlast-mileが冗長になるわけではない。 advertised prefixesがsite間で重複する環境ではGlobal Reach追加前にaddress plan/NAT/route policyを解決する。

通信や判断の流れを追う

On-premisesVPN / ProviderGateway / HubVNetWorkload

Control plane と data plane

Control planeControl planeは各ExpressRoute circuit/private peeringとpeering connection(Global Reach) resource。両circuitが正常provisionedでもGlobal Reach connection/prefix exchangeが別に成立する必要がある。

Data planeData planeではSite A CE→Circuit A→Microsoft global network→Circuit B→Site B CEへprivateに転送される。Azure VNet gatewayをsite間data pathとして必須にする構成ではなく、circuit peering間の接続として考える。

Provider / responsibility boundary

Azure / Microsoft

ExpressRoute circuit、peering、MSEE側BGP、VNet gateway / FastPath、Azure route propagationを管理する。

Connectivity provider

customer edgeからMicrosoft edgeまでのL2/L3 service、cross-connect、VLAN等を担当する。provider provisioningはAzure resource stateと別に追う。

Customer edge

CE routerのBGP policy、local preference / AS path、prefix filter、冗長回線を管理する。片系だけ正常でもend-to-end冗長性は成立しない。

仕組み

Global Reachはbranch-to-Azure目的のExpressRouteをbranch-to-branchにも拡張するが、企業WANの全feature/QoS/security serviceを自動代替するわけではない。

各siteがMicrosoftへ広告するprefixをGlobal Reachで相手siteが学習するため、route leak範囲とsummaryを明示する。

既存WANと同一prefixへのparallel routeを持つ場合、CEのlocal preference/AS path/IGP redistribution等でnormal/backup pathを決める。

stateful firewallをsite edge/central siteに置く場合、Global Reachでshortcut pathが生まれてinspectionを迂回しないか確認する。

Global Reach対応location/SKUは変更されるため、設計時点のcurrent Microsoft availabilityを確認する。

Packet / route path

同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。

Site AがSite B prefix宛packetをCEへ送り、CEがGlobal Reach経由routeをbestとして選ぶ。
Circuit A private peeringからMicrosoft networkへ入り、Global Reach connectionを通じCircuit B側へ転送される。
Circuit B private peeringからSite B CEへrouteされ、internal networkへ到達する。
replyはSite Bのroute policyによりCircuit B→Global Reach→Circuit Aへ戻る。
既存WANがbackup/parallelならfailure時にBGP/IGPがそちらへ収束する。
cutover/failoverではsite A/B双方のbest pathとFW/session pathを同時採取する。

BGP / route state の読み方

観測点	何を確認するか
Global Reach routes	各CEでremote site prefixのreceived route、next hop、AS pathを確認する。
Competing WAN	同prefixのMPLS/SD-WAN/Internet VPN routeとadministrative policyを比較し、意図したbest pathを確認する。
Azure VNet routes	site間trafficとAzure-bound trafficを分離し、Global Reach追加でAzure prefix policyが意図せず変わっていないか確認する。
Withdrawal	片circuit/Global Reach connection停止時にremote site prefixがwithdrawされbackupへ収束することを試験する。

判定ルールAdvertised ≠ Learned ≠ Installed/Effective ≠ Reachable。各段階を別証拠として採取し、どこでprefixが消えたかを特定します。

設計判断

判断点	推奨	理由
Use case	site-to-site private backboneをMicrosoft networkへ載せる要件がある場合に採用する。	単にAzure接続があるから有効化する機能ではない。
Route policy	既存WANとのprimary/backup関係をCE側で明示する。	parallel pathはasymmetry/loopを生み得る。
Security	inspection pointがGlobal Reach pathにも存在するか確認する。	WAN shortcutでcentral FWを迂回する可能性がある。
Resiliency	各siteのcircuit/location/last-mile diversityを別途設計する。	Global Reach connection自体はedge circuitのsingle pointを消さない。

確認手順

Azure Portal / provider / edge

Circuit → Private peering → Global Reach connectionsでconnection stateとremote circuitを確認する。
両site CEでremote site prefixのreceived/installed routeとbest pathを確認する。
既存WAN/backup routeを含むrouting tableを採取し、normal/failure時のpriorityを記録する。
site A↔Bのapplication/latency testをAzure-bound testと分離して実施する。

Verification discipline

subscription / resource group / resource ID / region / connection名を固定し、同名resourceの取り違えを防ぐ。
control-planeのProvisioningStateだけで完了判定せず、peer/session/route/metricと実packetの結果を別々に保存する。
advertised route・learned route・effective routeを混同しない。各段階で「誰が誰へ何を広告し、最終的にどのFIBへ入ったか」を確認する。
変更前後で同一source/destination/protocolを再試験し、既存sessionの継続を新規flowの成功と誤認しない。

Azure CLI — read-only first

az network express-route peering connection list -g <rg> --circuit-name <circuit> --peering-name AzurePrivatePeering -o table
az network express-route peering connection show -g <rg> --circuit-name <circuit> --peering-name AzurePrivatePeering -n <global-reach-connection> -o jsonc

PowerShell / endpoint — read-only first

Get-AzExpressRouteCircuit -ResourceGroupName <rg> -Name <circuit>
# Global Reach connectionはcurrent Az.Network cmdlet/referenceで対象circuit/peeringと合わせて確認する。

障害切り分け

症状	疑う点	証拠	次の確認
Global Reach Connectedだがsite間不可	CE filter/best path/overlap/security	両CE received/FIB + FW log	Azure connection stateだけでなく両edge routeを見る
既存WANへ戻らない	backup route未install/priority不整合	CE BGP/IGP table	Global Reach withdrawal時のbackup convergenceを試験する
一方向だけ通信	site A/Bのroute preference差、stateful FW	両方向best path + session log	asymmetryを最優先で確認する
remote prefixが想定以上に見える	route leak/summary policy	advertised routes + route filters	allowed site prefixesを明示的に絞る

変更時の確認と rollback

追加前に両siteのadvertised/received routeと既存WAN best pathを保存する。
cutoverは限定prefixから始め、site間security/latency/return pathを確認して拡大する。
rollbackはGlobal Reach route withdrawal後、既存WAN routeがFIBへ戻ったことを両siteで確認する。
connection削除前にbusiness trafficが代替pathへ移ったことをapplication evidenceで確認する。

What changed recently

2026-09-10時点

Global Reach availabilityは2026-06-24時点のcurrent listでJapanを含む複数locationに提供されています。geopolitical regionを跨ぐ接続ではPremium SKU requirementを含めcurrent availabilityを確認します。

ExpressRoute Global Reach