1. はじめに
皆さんは、異なるテナント間の VM を通信させたいとき、どのような方法を検討しますか？
最初に候補として挙がるのは、VNet Peering ではないでしょうか。（参考：公式ドキュメント）
しかし、VNet Peering には「双方の VNet のアドレス空間の重複が許可されない」という大きな制約があります。この制約を回避しつつ、セキュアに通信を確立できるのが、今回のテーマとなる「Azure Private Link Service」です。
本記事では、Azure Private Link Service を用いた VM のテナント間通信の仕組みと、構成時に押さえておくべきポイントを解説します。
2. Azure Private Link Service とは
Azure Private Link Service は、Azure の PaaS サービスや、仮想ネットワーク内でホストされているサービスを、他の VNet や他の Azure テナントに対してプライベートに公開するための仕組みです。
App Service、Storage Account、SQL Database などの PaaS サービス、あるいは VM 上で稼働する独自サービスを対象にできます。
Azure Private Link Service には、次のような特徴があります。
-
ソースと宛先のアドレス空間が重複可能
VNet Peering との大きな違いです。 -
一方向のみの通信
ソースから宛先への通信のみ可能で、逆方向はできません。双方向の通信が必要な場合は使用できないので、ご注意ください。
※詳細は公式ドキュメントをご参照ください。
3. 構成時のポイント
では、構成時のポイントについて詳しく見ていきましょう。
今回は下図の構成を想定します。
ソース VM からプライベートエンドポイント → Azure Private Link Service → Load Balancer を経由し、宛先 VM へ接続が可能になります。
作成時は、リソース間の依存関係から、Load Balancer → Azure Private Link Service → プライベートエンドポイントの順で作成する必要があります。
ここからは、作成時の流れに沿って各要素を解説していきます。
3-1. アドレス空間
まず、アドレス空間についてです。
先述の通り、Azure Private Link Service を使用すると ソース VNet と宛先 VNet でアドレス空間が重複可能になります。VM も同様に、ソース・宛先ともに同一 IP アドレスで通信可能です。
「同じ IP アドレスの VM 同士を通信させたい」ケースは稀だと思いますが、今回は仕組みを分かりやすく示すために、同一 IP アドレスとしています。
アドレス空間や IP アドレスが重複可能な理由については、「3-3. Azure Private Link Service」をご参照ください。
3-2. Load Balancer
続いて、Load Balancer です。
「負荷分散しないのに、なぜ Load Balancer が必要なの？」と疑問に思われるかもしれません。
実は、現時点（2025年12月）では Azure Private Link Service は VM に直接接続できないため、Standard Load Balancer を経由する必要があります（※1、※2、※3）。ここでの Load Balancer は「負荷分散のため」ではなく、Azure Private Link Service が接続先を認識するためのエンドポイントとして機能します。
そのため、宛先 VNet に Load Balancer を作成し、バックエンドプールに宛先 VM を紐づける構成を取ります。これにより、Azure Private Link Service は Load Balancer を介して宛先 VM へトラフィックを届けることが可能になります。
※1）Load Balancer は Standard SKU を利用する必要があります。
※2）Azure Private Link Service に接続可能なリソースの一覧は、公式ドキュメントをご参照ください。
※3）本記事の最後に補足として載せていますが、Azure Private Link Service に直接 VM を接続できる機能がパブリックプレビューとして公開されています。
3-3. Azure Private Link Service
続いて本記事の主役、Azure Private Link Service です。
Azure Private Link Service を作成する際には、接続先の Load Balancer（3-2 で作成したもの）と、NAT IP と呼ばれる IP アドレスを指定します。
NAT IP は 静的 または 動的 のいずれかを選択でき、どちらの場合も NAT サブネット（NAT IP の割り当て元となるサブネット）から IP アドレスを割り当てます。
本構成では静的 IP アドレスを指定し、宛先サブネットを NAT サブネットとして、未使用のアドレスを割り当てました。
一方、動的 IP アドレスを選択した場合は、ユーザーが NAT サブネットを指定すると、そのサブネット内から NAT IP が自動的に割り当てられます。
NAT IP の役割
この NAT IP が、同じアドレス空間・同じ IP アドレス同士でも通信を成立させるための鍵となります。
- ソース VM の IP アドレスは、Azure Private Link Service を経由する際に NAT IP に変換されます。
- 宛先 VM には「NAT IP からの通信」として届くため、アドレス空間が重複していても衝突せずに通信可能になります。
たとえば構成図では、
- ソース VM（10.0.0.11）の通信が NAT IP（10.0.0.13）に変換され、
- 宛先 VM（10.0.0.11）へ「10.0.0.13 からの通信」として届きます。
この仕組みにより、同じアドレス範囲・同じ IP アドレス同士の通信が可能になるのです。
3-4. プライベートエンドポイント
続いて、プライベートエンドポイントです。
プライベートエンドポイントを作成する際は、Azure Private Link Service（3-3 で作成したもの） を指定します。
テナント間通信の場合は、Azure Private Link Service のリソースID を指定する必要があります。
設定時の注意点
-
専用サブネットの利用
Microsoft から、プライベートエンドポイントには専用サブネットを設けることが推奨されています。 -
NSGとの組み合わせ
プライベートエンドポイントのサブネットに NSG を紐づける場合は、サブネットの設定画面から「プライベートエンドポイントのネットワークポリシー」を有効化しておきましょう。
3-5. NSG ルール
最後に、NSG のルール設定です。
Azure Private Link Service の通信に必要な最小限のルールで構成したい場合、以下の通り設定しましょう（※）。
①ソースサブネット
- （out）ソースVMのIP → プライベートエンドポイントNICのIPへの送信許可
②プライベートエンドポイントサブネット
- （in）ソースVMのIP → プライベートエンドポイントNICのIPへの受信許可
- （out）不要 ※送信は暗黙的に許可されるため
③宛先サブネット
- （in）NAT IPからの受信許可
- （in）AzureLoadBalancer タグからの受信許可（全ポート・プロトコル）
※前提
NSGはサブネットへ紐づけの前提です。
必要最小限のルールを示すため、記載のルール以外は全通信拒否を想定しています。
ポート・プロトコルは必要に応じて指定ください。
4. まとめ
本記事では、Azure Private Link Service を用いたVMのテナント間通信について、構成時のポイントを中心にまとめました。少しでも参考になれば幸いです！
補足： Azure Private Link Service の Direct Connect
Azure Private Link Service に直接 VM を接続できる機能がパブリックプレビューとして公開されています（公式ドキュメントはこちら）。
この機能が正式リリースされれば、これまで必須だった Load Balancer を省略した構成が可能になる見込みです。
We Are Hiring!