MS_AzurePeeringService

Azure Peering Service

• 戻る（Azureの仮想ネットワーク）
  • VPN Gateway
  • Azure ExpressRoute
  • Azure Peering Service
  • 仮想ネットワーク ピアリング
  • Azure Private Link / Endpoint
  • OA-LANとAzureのVNETの分離

概要

• イントラからイイ感じに SaaS を使用できるようにする。
• Azure ExpressRoute の Microsoft Peering と同等だが、以下が異なる。
  • 接続方法が異なる。
  • 利用承認が不要。

補足（この 2 つの違いが分かりにくい理由）: Peering Service と
ExpressRoute Microsoft Peering は
**「同じ目的、違う手段」**であるため混同されやすい。

どちらも**「Microsoft の SaaS（Microsoft 365 等）に、
品質の良い経路で繋ぐ」**ためのものだが、実現方法が異なる。

	ExpressRoute（Microsoft Peering）	Azure Peering Service
回線	専用線を自分で契約する	既存のインターネット回線を使う
経路	専用線 → Microsoft のエッジ	ISP の網 → 最寄りの Microsoft エッジ
インターネット経由	しない	公衆インターネットは経由しない（ISP と Microsoft が直接ピアリング）
申請	Microsoft の利用承認が必要	不要
費用	高い（回線＋ ExpressRoute 課金）	安い（ISP のサービスとして提供）
主な用途	Azure の VNET への接続（Private Peering が本命）	SaaS への接続

つまり、

• Azure 上に構築した自社システム（VNET）に閉域で繋ぎたい
  → ExpressRoute（Private Peering）
• Microsoft 365 などの SaaS を快適に使いたい
  → Peering Service（安価で、専用線が要らない）

という使い分けになる。

Microsoft が Microsoft Peering の利用に承認を求めるのは、
SaaS 向けに専用線を引くのは費用対効果が悪いためで、
その代替として提供されたのが Peering Service という経緯である。

詳細

特徴

Microsoft Peeringとの類似点

接続先 SaaS はマルチテナントなので、
L7 プロキシを使用して、自テナントへのアクセスのみに制限するなど。

補足（この「類似点」は重要な制約）: どちらの方式でも、
経路を閉域にしても「自社テナントだけに繋がる」わけではない。

イントラ ──[閉域経路]── Microsoft 365 のエンドポイント
                           ├─ 自社テナント
                           ├─ 他社テナント  ← ここにも到達できてしまう
                           └─ 個人アカウント ← 同上

SaaS は同じ FQDN でマルチテナントを提供しているため、
経路制御だけでは「自社のデータだけ」に限定できない。
結果として、

• 社員が個人の Microsoft アカウントでログインして
  データを持ち出す、
• 他社テナントにファイルをアップロードする

といったことが経路上は可能になる。

対策はアプリケーション層で行う。

手段	内容
テナント制限（Tenant Restrictions）	プロキシで Restrict-Access-To-Tenants ヘッダーを付与し、許可したテナントにしかログインできなくする
条件付きアクセス	送信元 IP・デバイス準拠を条件に
CASB / MCAS	SaaS 利用の可視化と制御

本文が「L7 プロキシを使用して、自テナントへのアクセスのみに制限する」と
書いているのは、まさにこのテナント制限のことである。
同じ議論はAzureの管理ポータルとARM APIの
「閉域化」の節にもある。

...

接続方法

• パブリック・インターネットを経由しない。
• 経路が異なる（DC 経由ではなく、ISP のネットワーク経由）。

補足（「ISP のネットワーク経由」の意味）: 通常のインターネット接続と
何が違うのかを図にすると次のようになる。

【通常のインターネット】
  拠点 → ISP → 複数の AS を経由（経路は日によって変わる）→ Microsoft
         ↑ 経路が長く、品質が保証されない。障害時の切り分けも困難

【Peering Service】
  拠点 → ISP（Microsoft と直接ピアリング済み）→ 最寄りの Microsoft エッジ
         ↑ 経路が短く、ISP が品質を保証。冗長経路あり

得られる効果は、

効果	内容
遅延の低減	経路が短くなる（最寄りのエッジに入る）
経路の安定	経路ハイジャックやフラッピングを回避
可用性	ISP 側で冗長経路を確保
可視性	Microsoft 側でテレメトリ（遅延・経路）を確認できる

重要なのは、利用者側で特別な機器や設定が要らない点である。
対応 ISP と契約するだけで、既存のインターネット回線がそのまま
高品質な経路になる。これが「利用承認が不要」の実態でもある。

参考

Microsoft Docs

• Azure Peering Service のドキュメント
  https://docs.microsoft.com/ja-jp/azure/peering-service/
• Azure Peering Service の概要
  https://docs.microsoft.com/ja-jp/azure/peering-service/about

---

Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, 通信技術, Azure