企業ネットワークでは、通常、、10.0.0.0/8、172.16.0.0/12など、192.168.0.0/16 で定義されたプライベート IPv4 アドレス範囲のアドレス空間が使用されます。 オンプレミス環境では、これらの範囲は、最大のネットワークの要件を満たすのに十分な IP アドレスを提供します。 その結果、多くの組織は、IP アドレス割り当ての単純なルーティング構成とアジャイル プロセスに優先順位を付けるアドレス管理プラクティスを開発しています。 多くの場合、IPv4 アドレス空間の効率的な使用は優先されません。
クラウドでは、大規模なネットワークを簡単に構築できます。 マイクロサービスやコンテナー化などの一般的なアーキテクチャ パターンによっては、IPv4 アドレスの消費量が増加する可能性があります。 そのため、より保守的なアドレス管理プラクティスを採用し、IPv4 アドレスを限られたリソースとして扱することが重要です。
注
Azure 仮想ネットワークでは、RFC 1918 で定義されているアドレス ブロックを使用することをお勧めします。 詳細については、「 仮想ネットワークのアドレス範囲」を参照してください。
この記事では、Azure で大規模なネットワークを構築するときに IPv4 アドレス空間の消費を最小限に抑える 2 つの方法について説明します。 この方法は、複数の仮想ネットワークまたはランディング ゾーンで同じ IPv4 アドレス ブロックを再利用するネットワーク トポロジに依存します。
方法 1:IPv4 サブネット ピアリングを使用して、ランディング ゾーンのスポーク仮想ネットワークとハブ仮想ネットワークの間のピアリングから 1 つ以上のサブネットを除外します。 すべてのランディング ゾーンのピアリング関係から除外されたサブネットに、同じ非ルーティング IP アドレス範囲を割り当てることができます。 これらの IP アドレス範囲は、他のルーティング可能な IP アドレス範囲と重複することはできません。
方法 2: ランディング ゾーンの仮想ネットワークに接続されていない分離された仮想ネットワークにアプリケーションをデプロイします。 エンドポイントを Azure Private Link サービスに関連付けます。 ランディング ゾーンのスポーク仮想ネットワークで、Private Link サービスに関連付けられているプライベート エンドポイントを作成します。 分離された仮想ネットワークは、企業ネットワークのルーティング可能なアドレス空間と重複している場合でも、任意の IPv4 アドレス空間を使用できます。
方法 1 は、複数のシステムとアプリケーションが相互に依存する従来のエンタープライズ環境で最適に機能します。 方法 2 は、アプリケーションが独立して動作する疎結合環境で最適に機能します。
Azure ランディング ゾーンのアラインメント
この記事の推奨事項は、 Azure ランディング ゾーン アーキテクチャに基づくネットワーク トポロジに適用されます。
Azure リソースをホストする各リージョンには、ハブ アンド スポーク ネットワークがあります。
異なるリージョンのハブ アンド スポーク ネットワークは、グローバル仮想ネットワーク ピアリングを介して接続します。
ハブアンドスポーク ネットワークは、Azure ExpressRoute 回線またはサイト間 VPN を介してオンプレミス サイトに接続します。
Azure ランディング ゾーン アーキテクチャでは、各アプリケーションは独自のスポーク仮想ネットワークで実行されます。 各スポーク仮想ネットワークは、企業ネットワーク全体で一意の IPv4 アドレス空間を使用します。
ランディング ゾーン内のすべてのリソースは、次の方法で接続できます。
IP アドレスを使用して、企業ネットワーク内の他のリソースへの接続を開始する
企業ネットワーク全体から IP アドレスを介して直接接続を受信する
ただし、リソースに企業ネットワーク全体からの到達可能性が常に必要なわけではありません。 たとえば、HTTP フロントエンド、ビジネス ロジック、データ層などの 3 層の Web アプリケーションを含むランディング ゾーンでは、ランディング ゾーンの外部から HTTP フロントエンドのみに到達できる必要があります。 他のレイヤーは互いに接続し、フロントエンドを接続する必要がありますが、クライアントからの接続を受け入れる必要はありません。 この例では、次のコンポーネントを各ランディング ゾーンに割り当てることで、IPv4 アドレスの使用量を最小限に抑えることができることを示唆しています。
企業ネットワーク全体で一意のアドレス空間。 このアドレス空間を使用するのは、ランディング ゾーンの外部から到達できる必要があるリソースだけです。 この記事では、このアドレス空間をランディング ゾーンの ルーティング可能なアドレス空間と見なします。
独自のランディング ゾーン内の他のリソースと通信するだけで済むリソースの内部アドレス空間。 このアドレス空間では、企業ネットワークからの直接の到達可能性は必要ありません。 この記事では、このアドレス空間をランディング ゾーンの nonroutale アドレス空間と見なします。
次のセクションでは、 フロントエンド コンポーネント は、企業ネットワーク全体から到達可能である必要があるアプリケーション コンポーネントを参照します。 バックエンド コンポーネント とは、企業ネットワーク内のエンドポイントを公開せず、独自のランディング ゾーン内でのみ到達可能なアプリケーション コンポーネントを指します。
方法 1: スポーク仮想ネットワーク内のルーティング不可能なサブネット
IPv4 サブネット ピアリングを使用して、2 つの仮想ネットワーク間のピアリング関係を特定のサブネットに制限できます。 ピアリング構成に含まれるサブネットのみが、トラフィックを相互にルーティングできます。 ピアリング構成から除外されたサブネットは非表示のままであり、ピア仮想ネットワークから到達できません。
ハブ アンド スポーク トポロジでは、ピアリング構成から各スポーク内の 1 つ以上のサブネットを除外した場合、それらのサブネットは、ハブから、また他のピアリング、ExpressRoute 接続、または VPN 接続を介してハブに接続されているすべてのリモート ネットワークから、非表示のままで到達できません。 そのため、すべてのスポーク仮想ネットワークのピアリング構成から除外されたすべてのサブネットに同じアドレス範囲を割り当てることができます。 この範囲は nonroutale として定義する必要があり、企業ネットワーク内の他の場所では使用できません。
次の図には、これらのコンポーネントが含まれています。
10.57.0.0/16範囲は、nonroutale アドレス空間として機能します。ハブ仮想ネットワークと各ランディング ゾーンスポーク仮想ネットワークは、一意のルーティング可能な IP アドレス範囲 (
10.0.0.0/24、10.1.0.0/24、および10.2.0.0/24) を使用します。各ランディング ゾーン スポーク仮想ネットワークには、
10.57.0.0/16のノンルータブル範囲内に1つ以上のノンルータブル サブネットが含まれています。 Azure 仮想ネットワークのアドレス空間には、複数の IP アドレス範囲を含めることができます。これらのサブネットは、ハブとのピアリング関係から除外されます。 そのため、異なるランディング ゾーン スポーク内の nonroutale サブネットは、
10.57.0.0/16内で同じアドレス範囲または重複するアドレス範囲を持つことができます。
このアーキテクチャの PowerPoint ファイル をダウンロードします。
この方法では、ランディング ゾーンのスポーク仮想ネットワーク内で完全な接続が維持されます。 同じスポーク仮想ネットワーク内のすべてのリソースは、ルーティング可能なサブネットと非ルーティング サブネットのどちらに存在するかにかかわらず、相互に接続できます。 ただし、ルーティング可能なサブネット内のリソースのみが、独自のランディング ゾーン外のリソースに接続できます。
ランディング ゾーンにアプリケーションをデプロイする
サブネット ピアリングを使用して nonroutale サブネットを含むランディング ゾーンを構築する場合は、さまざまなパターンを適用して、アプリケーションのフロントエンド コンポーネントとバックエンド コンポーネントをルーティング可能なサブネットと非ルーティング サブネットに分散できます。 次の考慮事項は、新しく構築されたアプリケーションと、完全にルーティング可能な単一のアドレス空間を使用する従来のランディング ゾーンから移行されたアプリケーションの両方に適用されます。
レイヤー 7 アプリケーション配信コントローラーを介して公開されるアプリケーション: これらのアプリケーション配信コントローラーには、Azure Application Gateway または Microsoft 以外のネットワーク仮想アプライアンス (NVA) が含まれます。 ランディング ゾーン外のクライアントから到達できる必要があるのは、アプリケーション配信コントローラーのエンドポイントのみです。 そのため、アプリケーション配信コントローラーは、ルーティング可能なサブネットに存在する必要がある唯一のフロントエンド コンポーネントです。
Azure ロード バランサーを介して公開されるアプリケーション: アプリケーションで内部 Azure ロード バランサーを使用する場合は、ロード バランサーのバックエンド プール内の仮想マシンがルーティング可能なサブネットに存在する必要があります。 他のすべてのコンポーネントを nonroutale サブネットにデプロイできます。
次の図は、これらのパターンを示しています。
ランディング ゾーン A は、ルーティング可能なサブネット内の唯一のコンポーネントであるアプリケーション配信コントローラーを介して公開される 3 層 Web アプリケーションをホストします。
ランディング ゾーン B は、内部 Azure ロード バランサーを介して公開される 3 層アプリケーションをホストします。
このアーキテクチャの PowerPoint ファイル をダウンロードします。
アウトバウンドの依存関係
アプリケーションのバックエンド コンポーネントは、企業ネットワークから受信接続を受信する必要はありません。 ただし、ランディング ゾーン外のエンドポイントへの接続を開始する必要がある場合があります。 一般的な例としては、ドメイン ネーム システム (DNS) の解決、Active Directory Domain Services (AD DS) ドメイン コントローラーとの対話、他のランディング ゾーン内のアプリケーションや、ログ管理やバックアップ システムなどの共有サービスへのアクセスなどがあります。
非ルーティング サブネット内のリソースがランディング ゾーン外のエンドポイントへの接続を開始する必要がある場合、それらの接続ではルーティング可能な IP アドレスの背後でソース NAT (SNAT) を使用する必要があります。 そのため、各ランディング ゾーンのルーティング可能なサブネットに NAT 対応 NVA をデプロイする必要があります。 次の図はこの構成を示したものです。
このアーキテクチャの PowerPoint ファイル をダウンロードします。
ルーティング不可能なサブネットでは、 ランディング ゾーンの外部宛てのすべてのトラフィックを NAT 対応 NVA に転送するカスタム ルート テーブルを使用する必要があります。 前の図では、 10.57.0.0/16 範囲は nonroutale ですが、 10.0.0.0/8 内の他の範囲はルーティング可能です。 各非ルーティング サブネットのカスタム ルート テーブルには、次のユーザー定義ルート (UDR) が含まれている必要があります。
| 行き先 | 次ホップの種類 | 次ホップの IP アドレス |
|---|---|---|
| 10.0.0.0/8 | VirtualNetworkAppliance | <スポーク NAT 対応 NVA IP アドレス> |
仮想ネットワークのシステム ルート テーブルには、nonroutale 10.57.0.0/16 範囲内の宛先のシステム ルートが既に含まれています。 その範囲内のトラフィックの UDR を定義する必要はありません。
ルーティング可能なサブネット (NAT 対応 NVA をホストするサブネットを含む) では、ランディング ゾーンの外部 (通常はハブ仮想ネットワーク内の NVA) にトラフィックを転送するカスタム ルート テーブルを使用する必要があります。 これらの NVA は、スポーク間のトラフィックをルーティングします。 これらのハブ NVA は NAT 操作を実行しません。 前の図では、ルーティング可能な各サブネットのカスタム ルート テーブルに次の UDR が含まれている必要があります。
| 行き先 | 次ホップの種類 | 次ホップの IP アドレス |
|---|---|---|
| 10.0.0.0/8 | VirtualNetworkAppliance | <ハブ ルーター/ファイアウォールの IP アドレス> |
| 10.0.0.0/24 | VirtualNetworkAppliance | <ハブ ルーター/ファイアウォールの IP アドレス> |
宛先 10.0.0.0/24 を持つ 2 番目の UDR により、ハブ仮想ネットワーク内のリソースへの接続がハブ ファイアウォールを経由して確実にルーティングされます。 一部のアプリケーションでは、より多くの UDR が必要になる場合があります。 ランディング ゾーン内の仮想マシンで、通常ハブでホストされている NVA 経由のインターネット アクセスが必要な場合は、 0.0.0.0/0の既定のルートも定義する必要があります。
注
NAT 経由のクライアントto-AD DS ドメイン コントローラー通信がサポートされています。 NAT 経由のドメイン コントローラー間通信はテストされておらず、サポートされていません。 詳細については、「 NAT 経由の Windows Server Active Directory のサポート境界」を参照してください。 ルーティング可能なサブネットに Windows Server Active Directory ドメイン コントローラーを展開することをお勧めします。
AZURE Firewall または Microsoft 以外の NVA を NAT 対応デバイスとして使用できます。 次のセクションでは、両方のオプションについて説明します。 Azure NAT ゲートウェイは、インターネットにバインドされたトラフィックに対してのみ SNAT をサポートするため、使用できません。
Azure Firewall を使用して SNAT を実装する
低い複雑さと最小限の管理に優先順位を付ける必要がある場合、Azure Firewall は、nonroutale サブネットからの接続に SNAT を実装するための最適なソリューションを提供します。 Azure Firewall には、次の利点があります。
- フル マネージドライフサイクル
- 組み込みの高可用性
- トラフィック量に基づく自動スケール
Azure Firewall を使用する場合は、次の要因を考慮してください。
ルーティング可能なアドレス空間を使用する必要がある AzureFirewallSubnet という名前の独自の予約済みサブネットに Azure Firewall をデプロイします。
一部の Azure Firewall SKU または構成では、ファイアウォール管理のために 2 つ目の予約サブネットが必要になる場合があります。 管理サブネットには、ルーティング可能なアドレス空間は必要ありません。
Azure Firewall には、3 つの異なる SKU があります。 SNAT はリソースを集中的に消費しないため、Basic SKU から始めます。 ルート不可能なサブネットから大量の送信トラフィックを生成するランディング ゾーンの場合は、標準 SKU を検討してください。
[SNAT の実行] オプションを Always に設定して Azure Firewall を構成します。 各インスタンスは、SNAT に対して特権のないポートを使用します。 受信したすべての接続に SNAT を実装するように Azure Firewall を構成するには、 SNAT 構成手順に従います。
ランディング ゾーンの外部宛てのすべてのトラフィックをファイアウォールのプライベート IP アドレスに転送するカスタム ルート テーブルに、すべての非ルーティング サブネットを関連付けます。
次の図は、各スポークが Azure Firewall を使用して nonroutale サブネットからの接続に SNAT を提供するハブアンドスポーク ネットワークを示しています。
このアーキテクチャの PowerPoint ファイル をダウンロードします。
Microsoft 以外の NVA を使用して SNAT を実装する
Azure Marketplace で NAT 機能を持つ Microsoft 以外の NVA を見つけることができます。 要件が Azure Firewall でサポートできる要件を超える場合は、Microsoft 以外の NVA の使用を検討してください。 たとえば、次の機能が必要な場合があります。
NAT プールに対するきめ細かい制御
カスタム NAT ポリシー (たとえば、異なる接続に異なる NAT アドレスを使用する必要がある場合など)
スケールインとスケールアウトに対するきめ細かい制御
Microsoft 以外の NVA を使用する場合は、次の要因を考慮してください。
高可用性を確保するために、少なくとも 2 つの NVA を持つクラスターをデプロイします。
Standard SKU Azure ロード バランサーを使用して、ルーティング不可のスポーク仮想ネットワークからネットワーク仮想アプライアンス (NVA) に接続を分散します。 すべての接続では宛先ポートに関係なく SNAT を使用する必要があるため、 高可用性負荷分散規則 ( 任意のポート負荷分散規則とも呼ばれます) を使用する必要があります。
NAT 対応 NVA のシングルアーム構成とデュアルアーム構成を選択します。 シングルアーム構成の方が簡単で、一般的に推奨されます。
次の図は、Microsoft 以外の NVA を使用して、ハブ アンド スポーク ネットワーク トポロジに SNAT を実装する方法を示しています。
このアーキテクチャの PowerPoint ファイル をダウンロードします。
Azure Virtual WAN で方法 1 を使用する
Azure Virtual WAN では、サブネット ピアリングはサポートされていません。 そのため、Virtual WAN ベースのハブ アンド スポーク ネットワークでは、非ルーティング可能なサブネットを持つランディングゾーン仮想ネットワークを作成することはできません。 ただし、ランディング ゾーンごとに 2 つのピアリングされた仮想ネットワークを使用することで、方法 1 の基本原則を適用できます。
ルーティング可能なアドレス空間を最初の仮想ネットワークに割り当て、Virtual WAN ハブに接続します。
非ルーティング アドレス空間を 2 番目の仮想ネットワークに割り当て、ルーティング可能な仮想ネットワークとピアリングします。
次の図は、結果のトポロジを示しています。
このアーキテクチャの PowerPoint ファイル をダウンロードします。
この方法では、ランディング ゾーン内の接続は制限されません。 ランディング ゾーン内の 2 つの仮想ネットワークは直接ピアリングされるため、ルーティング可能な仮想ネットワークと非ルーティング仮想ネットワークのどちらに存在するかに関係なく、すべてのリソースが相互に接続できます。 ただし、ルーティング可能な仮想ネットワーク内のリソースのみが、ランディング ゾーン外のリソースに接続できます。
ルーティングの観点からは、次の構成に違いはありません。
同じ仮想ネットワーク内のルーティング可能サブネットと非ルーティング サブネット (従来のハブ アンド スポーク ネットワークの前のセクションで説明)
直接ピアリングされた仮想ネットワーク (Virtual WAN に基づくハブアンドスポーク ネットワークについては、このセクションで説明します)
その結果、Virtual WAN ベースのネットワークでは、次のガイダンスが適用されます。
前のセクションで説明したのと同じ考慮事項を使用して、ルーティング可能なサブネットと非ルーティング サブネットにアプリケーション コンポーネントを分散できます。
ルーティング可能なサブネット内の NAT 対応 NVA を使用して送信依存関係を管理できます。
方法 2: Private Link サービス
Private Link を使用すると、仮想ネットワーク内のクライアントは、仮想ネットワーク ピアリングや仮想ネットワーク間 VPN などのレイヤー 3 接続を構成せずに、別の仮想ネットワーク内のアプリケーションを使用できます。 2 つの仮想ネットワークでは、重複する IP アドレス範囲を使用できます。 Azure は、必要な NAT ロジックを透過的に処理します。 この方法は、従来のハブ アンド スポーク ネットワークと Virtual WAN ベースのネットワークの両方に適用されます。
Private Link を使用してアプリケーションを公開するには、次の手順を実行します。
Standard SKU を使用して、内部 Azure ロード バランサーのバックエンド プールにアプリケーションのエンドポイントを追加します。
ロード バランサーのフロントエンド IP アドレスを Private Link サービス リソースに関連付けます。
クライアント側で、 プライベート エンドポイント リソース を作成し、サーバー側の Private Link サービスに関連付けます。
アプリケーションを使用するには、クライアントがプライベート エンドポイントに接続します。 Azure は、対応する Private Link サービスに関連付けられているロード バランサーのフロントエンド IP アドレスに接続を透過的にルーティングします。
Private Link を使用すると、各ランディング ゾーンに 2 つの仮想ネットワークを割り当てることで、IPv4 の枯渇を軽減できます。
企業ネットワークに接続されたルーティング可能なアドレス空間を持つ仮想ネットワーク
任意に選択されたアドレス空間を持つ分離された仮想ネットワーク。企業ネットワークのアドレス空間と重複する可能性があります
分離された仮想ネットワークでエンドポイントを公開するアプリケーションと Private Link サービスをデプロイします。 ルーティング可能な仮想ネットワークに、これらのサービスに接続するプライベート エンドポイントをデプロイします。
次の図は、企業ネットワークのアドレス空間と重複する、大きなアドレス空間 10.0.0.0/16を使用する 2 つのランディング ゾーンを示しています。 各ランディング ゾーンは、分離された仮想ネットワークにこの領域を割り当てます。 アプリケーションは分離されたスポーク仮想ネットワークにデプロイされ、Private Link サービスに関連付けられます。
このアーキテクチャの PowerPoint ファイル をダウンロードします。
企業ネットワーク内のクライアント (他のランディング ゾーン内のクライアントを含む) は、Private Link サービスに関連付けられているプライベート エンドポイントを介してアプリケーションを使用します。 次の図は、これらの接続の確立方法を示しています。
このアーキテクチャの PowerPoint ファイル をダウンロードします。
送信依存関係に Private Link サービスを使用する
分離された仮想ネットワーク内のアプリケーションは、企業ネットワーク内のエンドポイントへの接続を開始できません。 そのため、方法 2 は、異なるランディング ゾーン内のアプリケーションが独立して動作し、企業ネットワーク内のシステムに依存しないシナリオに最適です。 ただし、分離された仮想ネットワーク内のアプリケーションがランディング ゾーン外の特定のエンドポイントにアクセスする必要がある場合でも、この方法を適用できます。
次の図は、Private Link サービスを使用して、ランディング ゾーン A の分離された仮想ネットワーク内のアプリケーションが、ハブ仮想ネットワーク内の共有サービスとランディング ゾーン B のアプリケーション エンドポイントの両方を使用できるようにする方法を示しています。
このアーキテクチャの PowerPoint ファイル をダウンロードします。
貢献者達
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要な著者:
- フェデリコ・ゲリニ |シニア クラウド ソリューション アーキテクト、EMEA Technical Lead Azure Networking
- クシュ・カヴィジ |クラウド ソリューション アーキテクト
- Jack Tracey | シニア クラウド ソリューション アーキテクト
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次のステップ
- サブネット ピアリングを構成する
- 仮想ネットワークに Azure Firewall をデプロイする
- Azure Firewall で SNAT を構成する
- Azure Virtual Network でサポートされている IP アドレス
- Private Link
- Azure Load Balancer
- 仮想ネットワーク ピアリング
- ハブアンドスポーク ネットワーク トポロジ