仮想ネットワークは、Azure Container Apps environmentの周囲にセキュリティ境界を作成します。 既定では、環境は自動的に生成される仮想ネットワークで作成されます。 ただし、既存の仮想ネットワークを使用すると、Azure Application Gatewayとの統合、ネットワーク セキュリティ グループ、プライベート エンドポイントの背後にあるリソースとの通信など、よりAzureなネットワーク機能が提供されます。 この構成は、社内のミッション クリティカルなアプリケーションをパブリック インターネットから分離する必要がある企業のお客様にとって重要です。
仮想ネットワークを作成するときは、次の状況に注意してください。
コンテナー アプリですべての外部アクセスを制限する場合は、内部 Container Apps 環境を作成します。
独自の仮想ネットワークを使用する場合は、コンテナー アプリ専用のサブネットを提供する必要があります。 このサブネットは、他のサービスでは使用できません。
ネットワーク アドレスは、環境の作成時に定義したサブネット範囲から割り当てられます。
Container Apps 環境で使用されるサブネット範囲を定義できます。
環境を内部としてデプロイすることで、環境に対する受信要求を仮想ネットワークのみに制限できます。
注
独自の仮想ネットワークを指定すると、追加の管理対象リソースが作成されます。 これらのリソースでは、それらに関連付けられた料金でコストが発生します。
コンテナー アプリに関するネットワークの設計を始めるときは、「仮想ネットワークを計画する」をご覧ください。
注
Container Apps 環境で仮想ネットワークが使用されている場合、異なるリソース グループまたはサブスクリプション間での仮想ネットワークの移動は許可されません。
サブネット
仮想ネットワーク統合は、専用サブネットに依存します。 サブネット内の IP アドレスの割り当てとサポートされるサブネット サイズは、Container Apps で使用している プラン によって異なります。
サブネット サイズは慎重に選択してください。 Container Apps 環境を作成した後でサブネット サイズを変更することはできません。
各環境の種類には、独自のサブネット要件があります。
仮想ネットワーク統合に必要な最小サブネット サイズは
/27。サブネットを
Microsoft.App/environmentsに委任する必要があります。外部イングレスで外部環境を使用している場合、受信トラフィックはサブネットを経由するのではなく、インフラストラクチャのパブリック IP を経由してルーティングされます。
Container Apps では、サブネットとの統合のために 12 個の IP アドレスが自動的に予約されます。 インフラストラクチャの統合に必要な IP アドレスの数は、その環境のスケールの需要に基づいて変わるわけではありません。
使用しているワークロード プロファイルの種類に応じて、次の規則に従って追加の IP アドレスが割り当てられます。
専用ワークロード プロファイル: コンテナー アプリがスケールアウトすると、各ノードに 1 つの IP アドレスが割り当てられます。
消費ワークロード プロファイル: 各 IP アドレスは複数のレプリカで共有できます。 アプリに必要な IP アドレスの数を計画するときは、10 個のレプリカごとに 1 つの IP アドレスを計画します。
単一リビジョン モードで リビジョンを変更 すると、ダウンタイムゼロのデプロイをサポートするために、必要なアドレス空間が短期間で 2 倍になります。 この 2 倍は、特定のサブネット サイズでサポートされている実際の使用可能なレプリカまたはノードに影響します。 次のテーブルに、CIDR ブロック 1 つにつき使用可能なアドレスの最大数と、水平スケーリングに対する効果の両方を示します。
サブネットのサイズ 使用可能な IP アドレス1 最大ノード数 (専用ワークロード プロファイル)2 最大レプリカ数 (従量課金型ワークロード プロファイル)2 /23 498 249 2,490 /24 242 121 1,210 /25 114 五十七 570 /26 50 二十五 250 /27 18 9 90 1 使用可能な IP アドレスの数は、サブネットのサイズから、Azure Container Apps インフラストラクチャに必要な 14 個の IP アドレス (サブネットが予約する 5 つの IP アドレスを含む) を引いた値です。
2 これらの番号は、単一リビジョン モードのアプリを表します。
サブネット アドレス範囲の制限
サブネットのアドレス範囲は、Azure Kubernetes Service が予約している次の範囲と重複できません。
- 169.254.0.0/16
- 172.30.0.0/16
- 172.31.0.0/16
- 192.0.2.0/24
さらに、ワークロード プロファイル環境では、次のアドレスが予約されます。
- 100.100.0.0/17
- 100.100.128.0/19
- 100.100.160.0/19
- 100.100.192.0/19
CLI を使用したサブネットの構成
Container Apps 環境を作成するとき、1 つのサブネットにリソース ID を指定します。
Azure CLIを使用している場合、サブネット リソース ID を定義するパラメーターは infrastructure-subnet-resource-id です。 サブネットは、インフラストラクチャ コンポーネントとユーザー アプリ コンテナーをホストします。
従量課金専用環境でAzure CLIを使用していて、platformReservedCidr 範囲が定義されている場合、両方のサブネットが platformReservedCidr で定義されている IP 範囲と重複してはなりません。
Azure NAT Gateway の統合
Azure NAT Gatewayを使用すると、ワークロード プロファイル環境の仮想ネットワーク内の送信インターネット トラフィックの接続を簡略化できます。
サブネット上にネットワーク アドレス変換 (NAT) ゲートウェイを構成すると、NAT ゲートウェイによって環境に静的パブリック IP アドレスが提供されます。 コンテナー アプリからの送信トラフィックはすべて、NAT ゲートウェイの静的パブリック IP アドレスを介してルーティングされます。
注
現在、Azure NAT Gatewayの StandardV2 SKU は統合ではサポートされていません。
マネージド リソース
内部環境または外部環境を独自のネットワークにデプロイすると、お使いの環境がホストされている Azure サブスクリプションに新しいリソース グループが作成されます。 このリソース グループには、Azure Container Apps プラットフォームが管理するインフラストラクチャ コンポーネントが含まれています。 このグループ内のサービスや、リソース グループ自体を変更しないでください。
注
Container Apps 環境に割り当てられたユーザー定義タグは、リソース グループ自体を含め、リソース グループ内のすべてのリソースにレプリケートされます。
環境がホストされているAzure サブスクリプションで作成されたリソース グループの名前には、既定で ME_ が付きます。 Container Apps 環境を作成するときに、リソース グループ名をカスタマイズ できます 。
外部環境の場合、リソース グループには外部環境への受信接続に特に使用されるパブリック IP アドレスと、ロード バランサーが含まれます。 内部環境の場合、リソース グループには ロード バランサーのみが含まれます。
標準の Container Apps の課金に加えて、次の料金が課金されます。
内部環境または外部環境を使用している場合は、エグレス用の 1 つの標準静的 パブリック IP と、外部環境を使用している場合はイングレス用の 1 つの標準静的 パブリック IP 。 ソース NAT (SNAT) の問題が原因でエグレス用のパブリック IP が必要な場合は、 サポート チケットを開いてオーバーライドを要求します。
1 つの標準ロード バランサー。
処理されたデータのコスト (ギガバイト単位) には、管理操作のイングレスとエグレスの両方が含まれます。