Azure Private Link ServiceとPrivate Endpointでハブを経由しないスポーク間通信を実現する方法

Azure でハブ＆スポーク構成を組んでいると、「スポーク同士で一部のサービスだけを安全に共有したい、でも VNet ピアリングは増やしたくない」という場面がよくあります。本記事では、そのような要件に対して Azure Private Link Service（PLS）＋ Private Endpoint（PE）を使い、ハブを経由せずにスポーク間でサービスを公開する設計と注意点を、レイテンシや経路の挙動まで含めて詳しく解説します。

シナリオと要件整理

まず、前提となるネットワーク構成と要件を整理します。

構成は典型的な ハブ＆スポーク型 VNet トポロジ
ハブ VNet には Azure Firewall や NVA、VPN/ExpressRoute Gateway などを集約
スポーク VNet-A にはアプリケーション（サービス提供側）が存在（サブネット X）
スポーク VNet-B にはクライアント（サービス利用側）が存在（サブネット M、N）

今回の要件は次のとおりです。

VNet-A（サブネット X）のサービスを VNet-B（サブネット M, N など複数）から安全に利用したい
しかし スポーク同士の VNet ピアリングは、運用上これ以上増やしたくない
可能であれば ハブを経由せずにスポーク間で直接通信させたい
そのために PLS＋PE を使った場合、レイテンシ・経路・安定性がどうなるかを知りたい

（イメージ）

   [Hub VNet]
      ├─ Azure FW / NVA / GW など
      │
      ├─ Peering
      │
[VNet-A]  ---------（PLS）------&gt;  提供サービス
  Subnet X

[VNet-B]
  Subnet M ---- (PE) ---┐
  Subnet N ---- (PE) ---┘  --&gt; VNet-A の PLS を利用

このような構成で、本当にハブをバイパスできるのか、サブネット間でレイテンシ差が出るのか、といった疑問に答えていきます。

Azure Private Link Service / Private Endpoint の基本

Azure Private Link 全体像

Azure Private Link は、「VNet 内のプライベート IP」から Azure PaaS や自前サービスに安全にアクセスするための仕組みです。トラフィックは Microsoft のバックボーンネットワーク内にとどまり、インターネットへは一切出ません。

クライアント側：Private Endpoint（PE）… VNet 内の NIC として存在する
サービス側：Azure PaaS / Private Link Service（PLS）
両者は Azure の内部ファブリックで接続され、論理的には L4（TCP/UDP）レベルで閉じた private connection を形成

Private Endpoint（PE）とは？

Private Endpoint は、「プライベート IP を持つ特別な NIC」です。VNet のサブネットから IP が割り当てられ、その IP に向けて送られたトラフィックが、そのまま背後の Private Link 対象リソースへ転送されます。

VNet 内の任意のサブネットに作成可能
作成時に対象サービス（PaaS or PLS）を紐づける
クライアントは、対象の FQDN を PE の IP に名前解決してアクセス

Private Link Service（PLS）とは？

Private Link Service（PLS） は、自分の VNet 内のサービスを Private Link 経由で他 VNet や他テナントに公開するための仕組みです。

サービスは Standard Load Balancer のフロントエンド を経由して提供
PLS はこの Standard Load Balancer を参照して作成
PLS は 同一リージョンの VNet＆Standard LB 上に配置する必要がある
一方、PLS に接続する PE 側 VNet は 他リージョンや別サブスクリプション でも可

本記事のシナリオでは、VNet-A（提供側）に PLS を配置し、VNet-B（利用側）のサブネット M / N に PE を作ることで、スポーク間の閉じた通信を実現します。

ハブ＆スポークにおける Private Link の位置づけ

ハブ＆スポーク構成で Private Link を使うと、次のような「二層構造」になります。

第 1 層：クライアント VM ～ Private Endpoint（同一 VNet 内の通信）
第 2 層：Private Endpoint ～ PLS（Azure ファブリック内、Microsoft バックボーンを通る通信）

このとき、クライアントから見える宛先 IP は、あくまで自分の VNet 内のプライベート IP（PE） です。ここが「ハブを経由しない」ポイントになります。

アーキテクチャ：PLS＋PE でスポーク間通信を実現する

構成の全体イメージ

今回取り上げる構成は、次のとおりです。

VNet-A：サービス提供側
- Subnet X：アプリケーション VM または App Service Environment など
- アプリ前段に Standard Load Balancer を配置
- この Load Balancer をもとに PLS を作成
VNet-B：サービス利用側
- Subnet M, Subnet N：それぞれ開発・本番など用途別のサブネット
- サブネットごとに Private Endpoint を作成（VNet-A の PLS を参照）

構成パターン比較（高レベル）

方式	経路	セキュリティ境界	運用の特徴
従来：ハブ経由（FW/NVA 経由）	Spoke-B → Hub FW/NVA → Spoke-A	全トラフィックを中央集約して検査	ポリシー一元管理だが、遅延とばらつきが増えがち
従来：スポーク間 VNet ピアリング	Spoke-B ↔ Spoke-A（Peering）	VNet 単位で接続（細かい制御は NSG/UDR 頼み）	重複アドレスやルート設計が複雑化しやすい
提案：PLS＋PE	Spoke-B（PE） → Azure Backbone → Spoke-A（PLS）	サービス単位で公開可。VNet 同士は直接つながない	疎結合でマルチテナント・マルチサブスクリプションにも展開しやすい

今回のテーマは、この 3 番目のパターンです。

経路の挙動：本当にハブを通らないのか？

Private Endpoint 作成時に何が起きるか

Private Endpoint をサブネットに作成すると、そのサブネットの 既定ルートテーブルに「/32 のプラットフォームルート」 が自動的に追加されます。次ホップ種別は InterfaceEndpoint です。

これはイメージとして、次のようなルートです。

アドレスプレフィックス : 10.10.10.4/32   （PE の IP）
次ホップ種別           : InterfaceEndpoint

この /32 ルートにより、「対象サービスの FQDN → PE IP に解決されたトラフィック」は、ピンポイントで PE に吸い込まれます。結果として、既存の UDR でハブに向けていた経路よりも優先され、ハブを経由しなくなる、という動きになります。

通信フローを分解する

クライアント（VNet-B / Subnet M）の VM が、サービス FQDN に対して接続を開始
DNS により、その FQDN は Subnet M にある PE の IP（例：10.10.10.4）に解決
クライアントの NIC の有効ルートに、10.10.10.4/32 → InterfaceEndpoint が存在するため、パケットは同一 VNet 内の PE に到達
PE から先は Azure の Private Link ファブリックを通じて、VNet-A の PLS（および背後の Standard LB・アプリ）へ配送
戻りのトラフィックも Private Link 上で対向の PE に戻されるため、通信は対称

どのステップを見ても、ハブ VNet の FW/NVA が経路上に現れない ことが分かります。ハブを経由させたい場合は、逆に設計側で工夫（/32 UDR で FW に向けるなど）をする必要がある、というのが重要なポイントです。

ハブに経路が伝播するケース

Private Endpoint の /32 ルートは、同じ VNet だけでなく、VNet ピアリングや VPN/ExpressRoute 経由でも伝播する 仕様があります。

したがって、次のような点に注意が必要です。

ハブ側から、意図せず PE に直接到達できてしまう場合がある
ハブにいる管理サーバーやセキュリティツールからのアクセスを制限したい場合は、PE を配置しているサブネットの NSG で制御する のが基本
逆に、ハブからも PE を経由してサービスを利用したい場合は、「/32 ルートが伝播する」ことをうまく活用できる

サブネット M と N に PE を配置したときの違い（レイテンシは変わる？）

質問の一つは、「VNet-B 内のサブネット M と N にそれぞれ PE を作った場合、レイテンシ差は出るのか？」という点です。

結論から言うと、同一リージョン内であれば、サブネットの違いによるレイテンシ差はほぼありません。

クライアント → PE：同じ VNet 内のルーティング（サブネット違いによる差はほぼゼロ）
PE → PLS：Azure の Private Link ファブリック内通信であり、同一リージョン内なら経路はほぼ同等

そのため、サブネット M/N へ PE を分けるかどうかは、主に 論理分離や運用上の都合（開発環境と本番環境の分離など） で判断するとよいです。

パターン	構成例	メリット	デメリット
共通 PE	Subnet M に 1 個だけ PE を置き、N からも M 経由で利用	エンドポイント数が少なく運用がシンプル	ネットワーク分離が甘くなる（NSG 制御も込み入る）
サブネットごとに PE	Subnet M 用 PE、Subnet N 用 PE を個別に作成	環境ごとの分離がしやすく、承認フローも分けられる	PE 数が増え、接続管理がやや複雑
専用 PE VNet	PE だけを集約する専用 VNet を用意	大規模環境で管理しやすい設計パターン	設計・運用の初期コストは最も高い

VNet ピアリング / ハブ経由と PLS＋PE のレイテンシ比較

VNet ピアリングのレイテンシ水準

Microsoft の公式ドキュメントでは、同一リージョンの VNet ピアリング間のレイテンシは「同一 VNet 内と同水準」 とされています。

追加のゲートウェイやルーターは不要
トラフィックは Microsoft バックボーンを通過し、インターネットには出ない

PLS＋PE の場合は？

PLS＋PE の通信も、同じく Azure のバックボーンを通過する private connection です。そのため、同一リージョンにおいては VNet ピアリングと同じオーダーのレイテンシ（おおむね 1～5ms 程度）が期待できます。

実運用では、むしろ次のような観点で差が出ます。

ハブ経由（FW/NVA 経由）は、装置の処理負荷やログ転送等により「ばらつき」が増えやすい
PLS＋PE は、L4 レベルで Azure ファブリックに閉じるため、中央装置を挟まない分、遅延のばらつきが小さくなりやすい

ざっくりとしたレイテンシの目安

あくまで一般的な目安ですが、同一リージョンでの例として次のように考えるとイメージしやすいでしょう。

方式	典型的な往復遅延のイメージ	ばらつき（ジッタ）の傾向	要因
VNet 内（同一サブネット）	1～2ms 程度	非常に小さい	純粋に Azure ファブリック内の L2/L3 転送
VNet ピアリング（同一リージョン）	1～5ms 程度	小さい	バックボーン上の L3 転送。装置を挟まない
PLS＋PE（同一リージョン）	1～5ms 程度	小さい～中程度	Private Link ファブリック内転送。中央装置は通常挟まない
ハブ経由（FW/NVA 経由）	4～20ms 程度までブレるケースも	中～大	FW/NVA の負荷状態・ログ設定・SNAT などの影響

もちろん、実際の値は リージョン間距離・VM サイズ・アプリの応答時間 によって変わるため、本番前に必ず自社環境で計測してください。

Azure Network Watcher の Connection Monitor で RTT / 可用性を継続監視
iPerf や HTTP ベンチマークでスループットと遅延を確認

DNS 設計：PE の IP にどう名前解決させるか

基本方針

Private Endpoint を使う場合、クライアントが解決する FQDN は「PE のプライベート IP」になっている必要があります。

一般的な設計は次のとおりです。

社内 DNS（オンプレ or Azure VM）で、対象サービス用のゾーンをホスト
- 例：app.internal.example.com
- レコード：service01.app.internal.example.com → PE の IP
Azure 側では Private Endpoint の NIC 情報から、割り当て IP を確認
ハブ VNet または共通 DNS VNet で DNS サーバーを稼働させ、各 VNet からフォワード
オンプレ AD/DNS からもハブ経由でフォワードして、同じ名前で解決できるようにする

Azure Private DNS Zone を利用するパターン

Azure の Private DNS Zone を使うと、Azure 内の VNet 間での名前解決を一元化しやすくなります。

共通の Private DNS Zone を作成
- 例：privatelink.internal.example.com
PLS に紐づく PE の DNS レコードを登録
この Private DNS Zone を、VNet-A / VNet-B / ハブ VNet など必要な VNet にリンク

こうすることで、Azure 内のどの VNet からでも同じ名前で PLS 背後のサービスに到達でき、運用がシンプルになります。

UDR／FW／NVA と Private Endpoint の共存設計

基本の考え方

Private Endpoint の /32 ルートは、プラットフォームルートとして自動的に入り、通常は UDR よりも優先されます。このため、UDR で「全トラフィックを FW に送りたい」と思っていても、PE 宛てだけは FW をバイパスする、という挙動になります。

今回のように「ハブを通さずにスポーク間通信をしたい」場合には、これはむしろ望ましい動作です。設計上は次の点を意識します。

スポーク側サブネット（M/N）には、0.0.0.0/0 → ハブ FW などの UDR を設定してもよい
ただし、PE 宛ての /32 UDR を追加しない（既定の InterfaceEndpoint ルートを活かす）
PE 宛のトラフィックを FW 経由にしたい場合は、個別に /32 の UDR を明示的に追加する

セキュリティと可観測性のバランス

PLS＋PE は、中央 FW を経由しない構成が基本になります。そのため、どこでログを取り、どこで制御するか を事前に決めておくことが重要です。

サブネットの NSG で L4 レベルのアクセス制御（許可元サブネットやポートの制限）
アプリケーション側での認証／認可（JWT、mTLS など）
アプリケーションログ（アクセスログ）を Log Analytics や SIEM に集約

「レイテンシのばらつきを抑えたい」「スポークごとにセキュリティ境界を持ちたい」という文脈では、FW/NVA ではなく NSG＋アプリ層での制御に寄せる のが、PLS＋PE にマッチした考え方になります。

リージョン設計と可用性

リージョンと Private Link の関係

PLS と PE には、次のようなリージョン制約があります。

PE は「自分が所属する VNet と同一リージョン」に作成する
PLS は「提供側 VNet と Standard Load Balancer と同一リージョン」に作成する
ただし、PLS は他リージョンの VNet からの Private Endpoint でも利用可能（クロスリージョン利用）

レイテンシを最小化したい場合、原則として同一リージョンで PLS とクライアント VNet を設計する のがセオリーです。クロスリージョン接続は、DR 用やグローバルな共有基盤など、特別な要件がある場合のみ採用するのがおすすめです。

可用性・冗長化のポイント

提供側 VM／App は、可能な限り 可用性ゾーン冗長 にする
Standard Load Balancer もゾーン冗長構成を選択
PLS は背後の Standard LB を参照するため、LB 側の設計に可用性が左右される
Private Endpoint 自体は PaaS 的に冗長化されており、ゾーン障害には比較的強い

コストと制約の整理

PLS＋PE の課金イメージ

Private Endpoint：エンドポイント数に応じた時間課金＋データ処理料金
Private Link Service：有効化している時間に応じた料金＋スループットに応じた料金
クロスリージョン利用時：グローバル転送としての帯域課金が別途発生

大量のスポークから同じサービスを利用する場合、エンドポイント数の増加とデータ量がコストに効いてくるため、トラフィックパターンとスループット要件を見積もった上で PoC で実測 しておくと安心です。

技術的な制約の主なもの

PLS は Standard Load Balancer のみサポート（Basic 版は非対応）
IPv4 のみ、L4（TCP/UDP）のみサポート
PLS の NAT IP は最大で 8 個まで（スケールアウト設計時に考慮）
Private Endpoint の NIC は読み取り専用であり、手動で設定を変更できない

最小構成の構築手順（ハイレベル手順）

1. 提供側（VNet-A）で PLS を準備

アプリケーションを Subnet X の VM などにデプロイ
アプリの前段に Standard Load Balancer を配置
- フロントエンド IP（プライベート）を作成
- バックエンドプールにアプリケーション VM を登録
- Health Probe と LB ルールを設定
Standard LB を参照する Private Link Service を作成
- NAT IP 用サブネットを指定（十分な IP を確保）
- 必要に応じて Alias を利用して他サブスクリプション・他テナントへの公開を想定
- 接続要求の承認方法（手動／自動）を設定

2. 利用側（VNet-B）で Private Endpoint を作成

VNet-B の Subnet M に Private Endpoint を作成
- ターゲットとして VNet-A の PLS を指定（リソース ID または Alias）
- 承認フローに従って、サービス提供側が接続要求を承認
必要に応じて、Subnet N にも別の Private Endpoint を作成（環境ごとに分けたい場合）
Private Endpoint の NIC に割り当てられた IP アドレスを控えておく

3. DNS を構成

DNS でサービス FQDN → PE IP への名前解決ができるように設定
- Azure Private DNS Zone を利用するか、独自 DNS サーバーでゾーンを管理
オンプレ環境や他 VNet からも同じ FQDN でアクセスできるように、フォワーダーや条件付きフォワーダーを設定

4. ネットワーク制御の見直し

Subnet M/N の NSG で、PE 宛の許可ルールを定義
既存 UDR が PE 宛 /32 を上書きしていないか確認
ログ要件に応じて、NSG フローログやアプリケーションログを設定

5. 動作確認と性能検証

クライアント VM から FQDN で疎通確認（nslookup → curl / Invoke-WebRequest など）
Network Watcher の Connection Monitor で RTT・可用性を観測
想定ピーク時トラフィックに近い負荷でスループットと遅延を測定し、SLO を満たすか確認

PoC で確認しておきたいチェックポイント

名前解決：すべてのクライアントから同じ FQDN で PE に解決されているか
経路：
- クライアント VM の「有効ルート」を確認し、PE 宛が InterfaceEndpoint になっているか
- 意図せずハブ FW/VPN を経由していないか
レイテンシ／ジッタ：従来構成（ハブ経由など）と比較して、目標値を満たしているか
可用性：バックエンド VM 一部停止時やゾーン障害を想定したテスト
セキュリティ：NSG・アプリケーション認証で、想定外のクライアントからのアクセスを防げているか
運用：PLS/PE のライフサイクル（承認・更新・削除）のオペレーション手順が整備されているか

よくある質問（FAQ）

Q. VNet-B のサブネット M と N に PE をそれぞれ作ると、レイテンシは変わりますか？

A. 同一リージョンであれば、ほぼ変わりません。 クライアントから見れば、どちらも「同じ VNet 内の別サブネットにある PE」への通信であり、その先は同じ Private Link ファブリックを通ります。運用上の分離（開発／本番など）や、アプリケーションの責任分界点をどう切るかで決めるのがよいでしょう。

Q. 通信は本当にハブを通らないのですか？

A. 既定では通りません。 Private Endpoint 作成時に追加される /32 → InterfaceEndpoint のプラットフォームルートにより、対象サービス宛のトラフィックは PE にダイレクトに誘導されます。ハブを経由させたい場合は、あえて /32 UDR を追加して次ホップを FW/NVA に向けるなど、明示的な設計が必要です。

Q. PLS の方が VNet ピアリングよりレイテンシは低く、安定しますか？

A. 絶対値はほぼ同等（1～5ms 程度が多い）と考えてよい 一方で、中央装置（FW/NVA）を回避できる分、PLS＋PE の方が「ばらつきが小さい」傾向はあります。ただし、どちらもレイテンシの公式 SLA はありません。最終的には、自社の要件に照らして PoC で実測するのが確実です。

Q. すでにハブ＆スポーク＋ FW 構成がある場合でも、PLS＋PE に移行する価値はありますか？

はい、特に次のような場合は検討する価値があります。

スポークの数が増え、VNet ピアリング・ルート設計・セキュリティポリシーの管理が煩雑になっている
FW/NVA の性能上限が近づいており、トラフィックをオフロードしたい
特定サービスだけを厳格にスコープしたい（VNet 全体をつなぎたくない）

まとめ：どんな要件に PLS＋PE がフィットするか

ハブをバイパスしてスポーク間でサービスを共有したい
VNet ピアリングをこれ以上増やしたくない／運用を軽くしたい
サービス単位で公開範囲をコントロールしたい（VNet 全体を接続したくない）
レイテンシだけでなく、ばらつき（ジッタ）も小さくしたい

このような要件に対して、Azure Private Link Service ＋ Private Endpoint は非常に相性のよい選択肢です。

PE → PLS 間の経路は Azure バックボーン上で完結し、デフォルトではハブを経由しない
同一リージョンであれば、VNet ピアリングと同程度のレイテンシが期待できる
サブネット M/N どちらに PE を作っても、体感レベルでの差はほぼない
一方で、遅延に関する公式 SLA はないため、PoC での実測と SLO 設定は必須

ハブ＆スポーク構成が大きく育ってきたタイミングで、「すべてをハブ経由にする」発想から一歩進めて、PLS＋PE によるスポーク間サービス共有を設計に取り込むと、セキュリティと運用のバランスをとりやすくなります。ぜひ、自組織の要件に合わせて検討してみてください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。