ExpressRoute Circuit Lifecycleを理解するための前提
Circuit作成時に発行されるservice keyはconnectivity providerがcustomer circuitをAzure resourceへ紐付けるために使う。秘密鍵ではないが運用上の識別情報として適切に扱う。 Azure circuitのCircuit statusとProvider statusは別状態。provider provisioningが未完ならAzure側だけでBGP/data pathを完成できない。
課金開始点やprovider側費用は契約/SKUで異なるため、resource作成を「無料の予約」と扱わずcurrent pricing/provider条件を確認する。 private peeringのprimary/secondary BGP sessionはcircuit lifecycleの次段で構成する。Circuit Enabledだけを接続完了条件にしない。
bandwidth/SKU/port/provider変更には再provisioningやprovider coordinationが必要な場合があり、change planはAzureとproviderの両ticketを紐付ける。 削除はpeerings/VNet connections/provider deprovisionの依存を考え、先にprovider側が解約済みか、課金/routeが残らないか確認する。
Control plane と data plane
Provider / responsibility boundary
ExpressRoute circuit、peering、MSEE側BGP、VNet gateway / FastPath、Azure route propagationを管理する。
customer edgeからMicrosoft edgeまでのL2/L3 service、cross-connect、VLAN等を担当する。provider provisioningはAzure resource stateと別に追う。
CE routerのBGP policy、local preference / AS path、prefix filter、冗長回線を管理する。片系だけ正常でもend-to-end冗長性は成立しない。
仕組み
Create circuit → service key取得 → providerへ発注/紐付け → provider provisioning完了 → private peering → VNet gateway connectionというdependency chainで管理する。
Peering locationはAzure regionとは別概念。customer/providerがMicrosoft networkへ接続する場所であり、resiliency設計では物理location diversityとして扱う。
Maximum resiliencyは異なるpeering locationsの複数circuits、High resiliencyはMetro等で同metro内の複数physical peering location、Standardは単一location内冗長というfailure-domain差を理解する。
service keyを別circuitと取り違えるとprovider provisioningが意図しないresourceに紐付くため、resource ID/provider/location/bandwidthとセットでchange recordへ保存する。
decommissionではAzure resource削除前にprovider側serviceの停止条件・課金終了条件を確認し、routing withdrawalを計画する。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- Azureでcircuit resourceを作成し、service keyとexpected provider/location/bandwidthを確定する。
- providerがservice keyを使いcircuitをprovisionし、Provider statusがProvisionedへ進む。
- customer/Microsoft間でAzure private peeringのprimary/secondary BGPを構成する。
- VNet gateway/connectionを作成し、Azure VNet prefixがBGP経由でCEへ見えるようになる。
- data flowはprovider path→MSEE→VNet attachmentを通る。各段階のstateを別evidenceとして保持する。
- 廃止時はroute/connection/peering/provider serviceを順序管理し、trafficが代替pathへ移ったことを確認してからresourceを削除する。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Provider state | Provider statusがNotProvisioned/Provisioning/Provisionedのどこかを記録し、Azure ticketとprovider ticketを相互参照する。 |
| Peering state | primary/secondary BGPが両方成立し、route tableがexpected prefixを持つまでconnection phaseへ進めない。 |
| VNet attachment | circuitが正常でも各VNet connectionは独立して検証する。gateway connection missingをprovider障害と誤認しない。 |
| Change state | bandwidth/SKU/provider action後はcontrol-plane Succeededに加えBGP flap、route count、traffic metricを確認する。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Location | business continuity要件からpeering location diversityを先に決める。 | Azure regionだけ分けても同じpeering location/provider pathならfailure domainが残る。 |
| Bandwidth | 95th/peak trafficとgrowth、gateway/FastPath bottleneckを含めて決める。 | circuit bandwidth単独ではend-to-end throughputを保証しない。 |
| SKU | Standard/Premiumやmetering modelを必要region/route scale/Global Reach等で選ぶ。 | 機能要件とcost modelを混在させず明示する。 |
| Ownership | Azure owner、provider contact、CE ownerをchange/runbookに固定する。 | 障害時に責任境界で調査が停滞するのを防ぐ。 |
確認手順
Azure Portal / provider / edge
- Circuit Overview/Propertiesでservice key、provider、peering location、bandwidth、SKU、Provider status/Circuit statusを確認する。
- Provider portal/ticketでservice key、cross-connect/VLAN、provisioning completionを確認する。
- Peeringsでprimary/secondary BGPとroute tableを確認し、両linkを平常時に監視する。
- VNet Connectionsとtraffic metricsを確認し、control-plane lifecycleと実traffic移行を一致させる。
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の成功と誤認しない。
az network express-route show -g <rg> -n <circuit> -o jsonc
az network express-route peering list -g <rg> --circuit-name <circuit> -o table
az network express-route list-service-providers -o tableGet-AzExpressRouteCircuit -ResourceGroupName <rg> -Name <circuit>
Get-AzExpressRouteServiceProvider障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| Provider statusがProvisioningから進まない | service key/provider order/cross-connect | Azure circuit JSON + provider order ID | provider boundaryへescalateしAzure resource再作成を急がない |
| Circuit Enabledだがpeering不可 | provider L2未完、peer subnet/VLAN/ASN誤り | ARP/BGP + provider completion evidence | primary/secondary linkを別々に確認する |
| bandwidth変更後に不一致 | Azure/provider片側だけ変更 | circuit property + provider contract/portal | 両systemのbandwidth/SKUを突合する |
| 廃止後も費用/routeが残る | provider deprovision未完、connection/peering残存 | provider status、billing、route table | decommission checklistをdependency順で完了する |
変更時の確認と rollback
- 変更前にcircuit JSON、service key、provider order、peering/connection一覧を保存する。
- providerを伴うchangeはAzure側rollbackだけで完結しないため、provider rollback手順/連絡先を事前に取得する。
- deprovisionはtrafficをsecond pathへ移し、route withdrawalとapplication正常を確認してから進める。
- resource削除は最後の手段とし、再作成でservice key/coordinationが変わる影響を理解する。
What changed recently
2026年のPortal guidanceでは新規circuit設計時にMaximum / High / Standard resiliencyの選択肢が示されます。circuit lifecycleの開始時点でresiliency classを決め、後から「同じlocationにもう1本」で済ませないことが重要です。