Azure Private Link は、Azure プラットフォーム サービスと、Azure 仮想マシンでホストされている独自のアプリケーション用のプライベート IP アドレス指定を提供します。 Private Link を使用して、テナントの Azure 環境からのプライベート接続を有効にすることができます。 テナントは、仮想プライベート ネットワーク ゲートウェイ (VPN ゲートウェイ) または ExpressRoute 経由で接続されている場合に、Private Link を使用してオンプレミス環境からソリューションにアクセスすることもできます。
Azure Private Link は、 Snowflake、 Confluent Cloud、 MongoDB Atlas など、多くの大規模な SaaS プロバイダーによって使用されます。
この記事では、Azure でホストされるマルチテナント ソリューションの Private Link を構成する方法について説明します。
主な考慮事項
IP アドレス空間の重複
Private Link は、テナントがプライベート アドレス空間を介してサービスにアクセスできるマルチテナント ソリューション向けの強力な機能を提供します。
異なるテナントでは、同じまたは重複するプライベート IP アドレス空間が頻繁に使用されます。 たとえば、マルチテナント ソリューションでは、 10.1.0.0/16の IP アドレス空間を使用できます。 テナント A が同じ IP アドレス空間を持つ独自のオンプレミス ネットワークを使用し、偶然にもテナント B も同じ IP アドレス空間を使用するとします。 IP アドレス範囲が重複しているため、ネットワークを直接接続したりピアリングしたりすることはできません。
Private Link を使用して各テナントからマルチテナント ソリューションへの接続を有効にすると、各テナントのトラフィックにネットワーク アドレス変換 (NAT) が自動的に適用されます。 各テナントは、それぞれのネットワーク内でプライベート IP アドレスを使用でき、トラフィックは透過的にマルチテナント ソリューションに送信されます。 テナントとサービス プロバイダーがすべて重複する IP アドレス範囲を使用している場合でも、Private Link はトラフィックに対して NAT を実行します。
マルチテナント ソリューションにトラフィックが到着すると、既に変換されています。 つまり、トラフィックはマルチテナント サービス独自の仮想ネットワーク IP アドレス空間内から送信されたように見えます。 Private Link には TCP プロキシ プロトコル v2 機能が用意されています。これにより、マルチテナント サービスは、要求を送信したテナントと、ソース ネットワークからの元の IP アドレスを認識できます。
サービスの選択
Private Link を使用する場合は、受信接続を許可するサービスを検討することが重要です。
Azure Private Link サービス は、Standard ロード バランサーの背後にある仮想マシンで使用されます。
他の Azure サービスで Private Link を使用することもできます。 これらのサービスには、Azure App Service などのアプリケーション ホスティング プラットフォームが含まれます。 また、ネットワークおよび API ゲートウェイである Azure Application Gateway または Azure API Management も含まれます。
使用するアプリケーション プラットフォームによって、Private Link 構成の多くの側面と、適用される制限が決まります。 さらに、一部のサービスでは受信トラフィックの Private Link がサポートされていません。 Private Link のサポートを理解するために使用する Azure サービスのドキュメントを確認します。
制限
ソリューションのアーキテクチャに基づいて、作成できるプライベート エンドポイントの数を慎重に検討してください。 サービスとしてのプラットフォーム (PaaS) アプリケーション プラットフォームを使用する場合は、1 つのリソースでサポートできるプライベート エンドポイントの最大数に注意することが重要です。 仮想マシンを実行する場合は、Private Link サービス インスタンスを Standard ロード バランサー (SLB) にアタッチできます。 この構成では、通常、より多くのプライベート エンドポイントを接続できますが、制限は引き続き適用されます。 これらの制限により、Private Link を使用してリソースに接続できるテナントの数が決まります。 Azure サブスクリプションとサービスの制限、クォータ、制約を確認して、エンドポイントと接続の数に対する制限を理解します。
さらに、一部のサービスでは、Private Link を使用するために特殊なネットワーク構成が必要です。 たとえば、Azure Application Gateway で Private Link を使用する場合は、Application Gateway リソースの標準サブネットに加えて、専用サブネットを プロビジョニングする必要があります。
Private Link 構成を有効にして、デプロイと診断の構成を含むソリューションを慎重にテストします。 一部の Azure サービスでプライベート エンドポイントが有効になっている場合、パブリック インターネット トラフィックはブロックされます。 この動作では、デプロイと管理のプロセスを変更する必要があります。
プライベート リンクと一般向けサービスの組み合わせ
インターネットに接続し、プライベート エンドポイントを介して公開されるようにソリューションをデプロイすることもできます。 たとえば、テナントの中にはプライベート接続が必要なテナントもあれば、パブリック インターネット接続に依存するテナントもあります。 ネットワーク トポロジ全体と、各テナントのトラフィックが従うパスを検討します。
ソリューションが Standard ロード バランサーの背後にある仮想マシンに基づいている場合は、Private Link サービスを介してエンドポイントを公開できます。 この場合、Web アプリケーション ファイアウォールとアプリケーション ルーティングは、既に仮想マシン ベースのワークロードの一部である可能性があります。
多くの Azure PaaS サービスでは、異なる Azure サブスクリプションと Microsoft Entra テナント間でも、受信接続用の Private Link がサポートされています。 そのサービスの Private Link 機能を使用して、エンドポイントを公開できます。
Azure Front Door などの他のインターネットに接続するサービスを使用する場合は、受信トラフィックに対して Private Link がサポートされているかどうかを検討することが重要です。 そうでない場合は、トラフィックがソリューションへの各パスを通過する方法を検討してください。
たとえば、仮想マシン スケール セットで実行されるインターネットに接続するアプリケーションを構築するとします。 セキュリティとトラフィックの高速化には、Web アプリケーション ファイアウォール (WAF) を含む Azure Front Door を使用し、 プライベート エンドポイント経由でバックエンド (配信元) サービスにトラフィックを送信するように Front Door を構成します。 テナント A はパブリック エンドポイントを使用してソリューションに接続し、テナント B はプライベート エンドポイントを使用して接続します。 Front Door は着信接続用の Private Link をサポートしていないため、テナント B のトラフィックは Front Door とその WAF をバイパスします。
分離モデル
Private Link は、テナントなどの複数の個別のクライアントで 1 つのアプリケーション層を使用できるシナリオをサポートするように設計されています。 Private Link の分離を検討する場合、主な懸念事項は、要件をサポートするためにデプロイする必要があるリソースの数に関するものです。 Private Link に使用できるテナント分離モデルは、使用するサービスによって異なります。
Private Link サービスの分離モデル
Standard ロード バランサーの背後にある仮想マシンで Private Link サービスを使用する場合は、検討できる分離モデルがいくつかあります。
| 考慮事項 | Shared Private Link サービスと共有ロード バランサー | 専用の Private Link サービスと専用ロード バランサー | 専用の Private Link サービスと共有ロード バランサー |
|---|---|---|---|
| 配置の複雑性 | 低 | テナントの数に応じて中高 | テナントの数に応じて中高 |
| 操作の複雑さ | 低 | リソースの数に応じて中高 | リソースの数に応じて中高 |
| 考慮すべき制限 | 同じ Private Link サービス上のプライベート エンドポイントの数 | サブスクリプションあたりの Private Link サービスの数 | Standard ロード バランサーあたりの Private Link サービスの数 |
| サンプル シナリオ | 共有アプリケーション層を持つ大規模なマルチテナント ソリューション | テナントごとに分離されたデプロイ スタンプ | 多数のテナントを含む 1 つのスタンプ内の共有アプリケーション層 |
3 つのモデルすべてにおいて、データの分離とパフォーマンスのレベルはソリューションの他の要素によって異なります。Private Link サービスのデプロイは、これらの要因に大きく影響しません。
共有プライベートリンクサービスと標準ロードバランサーの共有
Standard ロード バランサーに接続されている共有 Private Link サービスのデプロイを検討できます。 各テナントはプライベート エンドポイントを作成し、それを使用してソリューションに接続できます。
1 つの Private Link サービス インスタンスは、多数のプライベート エンドポイントをサポートします。 制限を超える場合は、より多くの Private Link サービス インスタンスをデプロイできますが、1 つのロード バランサーにデプロイできる Private Link サービスの数にも制限があります。 これらの制限に近づくことが予想される場合は、デプロイ スタンプベースのアプローチを使用し、共有ロード バランサーと Private Link サービス インスタンスを各スタンプにデプロイすることを検討してください。
テナントごとの専用の Private Link サービスと専用の Standard ロード バランサー
テナントごとに専用の Private Link サービスと専用ロード バランサーをデプロイできます。 この方法は、テナントに厳密なコンプライアンス要件がある場合など、テナントごとに専用の仮想マシンセットがある場合に適しています。
テナントごとの専用 Private Link サービスと共有 Standard ロード バランサー
共有 Standard ロード バランサーを使用して、テナントごとに専用の Private Link サービス インスタンスをデプロイすることもできます。 ただし、このモデルは多くの利点を提供する可能性は低いです。 さらに、1 つの Standard ロード バランサーにデプロイできる Private Link サービスの数には制限があるため、このモデルは小規模なマルチテナント ソリューションを超えてスケーリングする可能性は高くありません。
より一般的には、複数の共有 Private Link サービスをデプロイできます。 この方法では、ソリューションが 1 つの共有ロード バランサーでサポートできるプライベート エンドポイントの数を増やすことができます。
プライベート エンドポイントを使用した Azure PaaS サービスの分離モデル
Azure サービスとしてのプラットフォーム (PaaS) サービスをデプロイし、テナントがプライベート エンドポイントを使用してそれらのサービスにアクセスできるようにする場合は、特定のサービスの機能と制約を考慮してください。 さらに、アプリケーション層リソースが特定のテナント専用であるか、テナント間で共有されているかを検討します。
テナントごとにアプリケーション層リソースの専用セットをデプロイする場合、そのテナントのリソースへのアクセスに使用するプライベート エンドポイントを 1 つデプロイできる可能性があります。 各テナントには専用のリソースがあるため、Private Link 関連のサービス制限を使い果たすことはほとんどありません。
テナント間でアプリケーション層リソースを共有する場合は、テナントごとにプライベート エンドポイントをデプロイすることを検討してください。 1 つのリソースにアタッチできるプライベート エンドポイントの数には制限があり、これらの制限はサービスごとに異なります。
マルチテナントをサポートする Azure Private Link の機能
Private Link には、マルチテナント環境で役立ついくつかの機能があります。 ただし、使用できる特定の機能は、使用するサービスによって異なります。 仮想マシンとロード バランサー用の基本的な Azure Private Link サービスでは、以下で説明するすべての機能がサポートされています。 Private Link がサポートされている他のサービスでは、これらの機能のサブセットのみが提供される場合があります。
サービス エイリアス
テナントが Private Link を使用してサービスへのアクセスを構成する場合、Azure が接続を確立できるように、サービスを識別できる必要があります。
Private Link サービスとその他の Private Link と互換性のある特定の Azure サービスを使用すると、テナントに提供する エイリアスを構成 できます。 エイリアスを使用すると、Azure サブスクリプション ID とリソース グループ名が公開されないようにします。
サービスの可視性
Private Link サービスを使用すると、 プライベート エンドポイントの可視性を制御できます。 エイリアスまたはリソース ID がわかっている場合は、すべての Azure 顧客にサービスへの接続を許可できます。 または、一連の既知の Azure 顧客のみにアクセスを制限することもできます。
プライベート エンドポイントに接続できる、事前に承認された Azure サブスクリプション ID のセットを指定することもできます。 この方法を使用する場合は、サブスクリプション ID を収集して承認する方法を検討してください。 たとえば、テナントのサブスクリプション ID を収集するための管理ユーザー インターフェイスをアプリケーションに提供できます。 その後、Private Link サービス インスタンスを動的に再構成して、接続のサブスクリプション ID を事前に承認できます。
接続の承認
クライアント (テナントなど) とプライベート エンドポイントの間で接続が要求された後、Private Link では接続が 承認されている必要があります。 接続が承認されるまで、トラフィックはプライベート エンドポイント接続を通過できません。
Private Link サービスでは、次のようないくつかの種類の承認フローがサポートされています。
- 手動承認。チームがすべての接続を明示的に承認します。 この方法は、Private Link 経由でサービスを使用するテナントが少数しかない場合に有効です。
- API ベースの承認。Private Link サービスは接続を手動承認が必要と見なし、アプリケーションは Update Private Endpoint Connection API、Azure CLI、または Azure PowerShell を使用して接続を承認します。 この方法は、プライベート エンドポイントの使用が承認されているテナントの一覧がある場合に役立ちます。
- 自動承認。Private Link サービス自体は、接続を自動的に承認する必要があるサブスクリプション ID の一覧を保持します。
詳細については、「 サービス アクセスの制御」を参照してください。
プロキシ プロトコル v2
Private Link サービスを使用する場合、既定では、アプリケーションでは、ネットワーク アドレス変換 (NAT) を介した IP アドレスのみが表示されます。 この動作は、トラフィックが独自の仮想ネットワーク内からフローしているように見えるということです。
Private Link を使用すると、テナントの仮想ネットワーク内の元のクライアント IP アドレスにアクセスできます。 この機能では、 TCP プロキシ プロトコル v2 を使用します。
たとえば、テナントの管理者が IP アドレスベースのアクセス制限を追加する必要があるとします。たとえば、 ホスト 10.0.0.10 はサービスにアクセスできますが、ホスト 10.0.0.20 ではアクセスできません。 プロキシ プロトコル v2 を使用する場合、テナントがアプリケーションでこれらの種類のアクセス制限を構成できるようにします。 ただし、アプリケーション コードでは、クライアントの元の IP アドレスを検査し、制限を適用する必要があります。
関連リソース
- Azure Private Link サービスのプロバイダー (SaaS ISV) とコンシューマーの視点からの説明とデモ: マルチテナント サービス プロバイダー (独立系ソフトウェア ベンダーが SaaS 製品を構築するなど) を可能にするAzure Private Link サービス機能を見るビデオ。 このソリューションを使用すると、コンシューマーは、コンシューマー自身の Azure 仮想ネットワークからプライベート IP アドレスを使用してプロバイダーのサービスにアクセスできます。
- Azure Private Link サービスを使用した TCP プロキシ プロトコル v2 — 徹底解説: Azure Private Link サービスの高度な機能である TCP プロキシ プロトコル v2 を深く掘り下げたビデオです。 マルチテナントや SaaS のシナリオで役立ちます。 ビデオでは、Azure Private Link サービスでプロキシ プロトコル v2 を有効にする方法を説明します。 また、NGINX サービスを構成して、NAT IP ではなく元のクライアントのソース プライベート IP アドレスを読み取り、プライベート エンドポイント経由でサービスにアクセスする方法についても説明します。
-
NGINX Plus を使用して、Azure Private Link サービスからプロキシ プロトコル TLV をデコード
linkIdentifierする: NGINX Plus を使用して、Azure Private Link サービスから TCP プロキシ プロトコル v2 TLV を取得する方法を説明する動画。 この動画では、プライベート エンドポイント接続の数値linkIdentifier(LINKIDとも呼ばれます) を抽出してデコードする方法が紹介されています。 このソリューションは、接続元となる特定のコンシューマー テナントを識別する必要があるマルチテナント プロバイダーに役立ちます。 - SaaS プライベート接続パターン: Azure Managed Applications を使用してプライベート エンドポイント接続の承認を自動化するための 1 つのアプローチを紹介するサンプル ソリューション。
貢献者達
この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。
主要な著者:
- John Downs | プリンシパル ソフトウェア エンジニア
- Arsen Vladimirskiy | FastTrack for Azure の主任顧客エンジニア
その他の共同作成者:
- Sumeet Mittal |プリンシパル製品マネージャー、Azure Private Link
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
マルチテナントのネットワーク アプローチを確認します。