Azure Peering Serviceを理解するための前提
Peering Serviceはpublic Internetを使うIP serviceであり、ExpressRouteやAzure VPNのようなprivate connectivity productではない。この境界を最初に固定する。 利用そのものはPeering Service partnerとのservice契約が中心で、Azureへのconnection登録はtelemetry等を利用するためのcontrol plane。Azure resource作成だけでoptimized pathが自動生成されるわけではない。
Peering Service connectionではlogical name、provider、customer physical location、primary/backup service location、customer prefix等を関連付ける。 prefix validationではpublic prefix、origin ASN registry、prefix key、primary/backup全sessionからのadvertisement、community 8075:8007、AS path要件などを満たす必要がある。
AS pathは長さ3以下、private ASNやAS prependingを含めない等のcurrent validation ruleがある。一般的なBGP traffic engineeringをそのまま適用しない。 telemetryではuser latency/BGP prefix events等を参照でき、partner pathの品質・prefix announcement/withdrawalをoperational evidenceとして使える。
Control plane と data plane
Provider / responsibility boundary
Peering Service connection / prefix登録とtelemetryを提供する。resourceを作っただけでprivate tunnelが生成されるわけではない。
Microsoftとのoptimized public peeringとprimary/backup service locationを提供する。実際のservice利用にはpartner契約・設定が必要。
public prefix、origin ASN、BGP advertisementを管理する。prefix validation要件を満たさないとtelemetry対象prefixがActiveにならない。
仕組み
Peering Serviceを「ExpressRouteの廉価版」として扱わない。private address reachabilityやVNet private peeringを提供するserviceではなく、public Microsoft endpointsへのInternet routing品質改善が主眼。
prefix registrationはtelemetry/validation unitであり、customer prefixがpartner経由で正しくBGP広告されて初めてActive validationへ進む。
primary locationはlocal redundancyを満たす複数sessions、backup locationにも必要sessionがあることをvalidationで確認する。
backup locationをNoneにした場合のfailure behaviorはpublic Internetへのfailoverとなるため、business requirementに応じpartnerとsecondary pathを設計する。
customer edge route policyはPeering Service validationのcommunity/AS path制約と整合させ、通常Internet向けpolicyから分離する。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- customer networkがMicrosoft public destination宛packetをInternet edgeへ送る。
- ISP/Peering Service partnerがoptimized peering pathを選びMicrosoft networkへ転送する。
- Microsoft network内でpublic cloud/service endpointへ到達する。
- return trafficもpartner/customer prefix advertisementに基づきpublic routingでcustomerへ戻る。
- primary service location failure時はbackup location、または構成により通常Internet pathへfailoverする。
- Azure telemetryへlatency/prefix eventが記録されても、それ自体がtrafficをforwardするdata-plane objectではない。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Prefix validation | Azure Portal/CLIでvalidation stateを確認し、community、origin ASN、prefix key、all-session advertisementを要件別に潰す。 |
| BGP advertisement | customer/provider routerからprimary/backup全Peering Service sessionsへ同prefixが広告されているか確認する。 |
| AS path/community | 8075:8007 community、path length<=3、private ASN/prependなしをroute evidenceで確認する。 |
| Fallback | primary failureでbackup/Internetへ実際に収束するかlatency/path/applicationで試験する。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Product fit | public Microsoft serviceへのInternet routing reliability/telemetry改善に使う。 | private VNet connectivity要件ならExpressRoute/VPNを選ぶ。 |
| Partner | service location、last-mile、SLA/support、backup optionを比較する。 | data plane qualityの主要責任境界がpartnerにある。 |
| Prefix policy | Peering Service用BGP policyをvalidation ruleに合わせて明示する。 | community/AS path違反でprefixがActiveにならない。 |
| Telemetry | 重要siteはAzure connection登録しlatency/prefix eventsを監視する。 | 「体感が遅い」だけでなくrouting event evidenceを残せる。 |
確認手順
Azure Portal / provider / edge
- Peering Services → connectionでprovider、customer location、primary/backup locationを確認する。
- Prefixesでprefix、prefix key、validation stateを確認し、失敗reasonを要件別に処理する。
- partner/customer routerでprimary/backup全sessionsのadvertised routes、community、AS pathを確認する。
- Peering Service telemetryでlatencyとprefix eventsを確認し、application monitor/provider NOC evidenceと相関する。
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 peering service list --resource-group <rg> --output table
az peering service show --resource-group <rg> --peering-service-name <service> -o jsonc
az peering service prefix list --resource-group <rg> --peering-service-name <service> -o table
az peering service provider list --output table# Peering ServiceはAzure CLIのpeering extensionが一次的な運用手段として明確です。
# Azure Portal/CLIでresourceとprefix validationを確認し、BGP evidenceはcustomer/provider router側でも採取します。障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| prefix validation失敗 | community/prefix key/origin ASN/all-session advertisement/AS path | Azure validation reason + router advertised route | validation messageごとに要件を修正する |
| primary path品質悪化 | partner/peering location/Internet underlay | latency telemetry + path/provider evidence | private connectivity障害と誤認せずpartner boundaryへ切り分ける |
| backupへ切替わらない | backup service location/session未構成 | connection config + provider session state | backup None/validation/sessionを確認する |
| Azure resource正常だが利用効果なし | partner service未契約/未provision、prefix未Active | provider order + prefix validation | resource作成とdata-plane service activationを分離する |
変更時の確認と rollback
- 変更前にconnection/prefix JSON、validation state、partner order、router advertisementを保存する。
- BGP community/AS path変更はPeering Service prefixesだけにscopeし、他Internet routesへの副作用を避ける。
- backup location変更はprovider側session readinessを確認してからtraffic/failover testを行う。
- rollback後はprefix Active、primary/backup path、latency/applicationを確認し、Azure resource stateだけで終了しない。
What changed recently
Microsoft LearnのPeering Service主要ページは2026-02-25更新で、prefix validationにはcommunity 8075:8007、AS path length<=3、private ASN/prepending禁止等の要件が明示されています。既存Internet BGP policyを流用せず専用validationとして確認します。