次の方法で共有

Azure Container Apps 環境でのネットワーク

  • [アーティクル]

Azure Container Apps は、それ独自の仮想ネットワーク (VNet) を使用して環境のコンテキストで実行されます。

既定では、コンテナー アプリ環境は、自動的に生成される VNet を使用して作成されます。 ネットワークをきめ細かく制御するために、環境を作成するときに既存の VNet を提供できます。 生成された VNet または既存の VNet を使用して環境を作成すると、ネットワークの種類を変更することはできません。

生成された VNet には次のような特徴があります。

以下のとおりです:

  • Microsoft のテナントに作成されるため、ユーザーはアクセスできません
  • インターネットを介してパブリックにアクセスできます
  • インターネットにアクセス可能なエンドポイントにのみ到達できます

さらに、イングレス IP 制限やコンテナー アプリ レベルのイングレス制御など、ネットワーク機能の限られたサブセットのみをサポートします。

次のようなより多くの Azure ネットワーク機能が必要な場合は、既存の VNet を使用します。

  • Application Gateway との統合
  • ネットワーク セキュリティ グループ
  • 仮想ネットワーク内のプライベート エンドポイントの背後にあるリソースとの通信

使用できる VNet 機能は、環境の選択によって異なります。

環境の選択

Container Apps には 2 つの異なる環境の種類があり、これらは多くの同じネットワーク特性を共有しますが、いくつかの重要な違いがあります。

環境の種類 説明 サポートされるプランの種類
ワークロード プロファイル ユーザー定義ルート (UDR) と NAT Gateway 経由のエグレスをサポートします。 必要な最小サブネット サイズは /27 です。 従量課金、専用
消費量のみ ユーザー定義ルート (UDR)、NAT Gateway 経由のエグレス、リモート ゲートウェイ経由のピアリング、またはその他のカスタム エグレスはサポートされません。 必要な最小サブネット サイズは /23 です。 従量課金

アクセシビリティ レベル

コンテナー アプリで、パブリック イングレスを許可するか、環境レベルで VNet 内からのイングレスのみを許可するかどうかを構成できます。

アクセシビリティ レベル 説明
外部品目番号 コンテナー アプリで、パブリック要求を受け入れることを許可します。 外部環境は、外部に公開されている IP アドレス上の仮想 IP を使用してデプロイされます。
Internal 内部環境にはパブリック エンドポイントが存在せず、内部環境は内部 IP アドレスにマップされた仮想 IP (VIP) を使用してデプロイされます。 内部エンドポイントは Azure 内部ロード バランサー (ILB) であり、IP アドレスはカスタム VNet のプライベート IP アドレスのリストから発行されます。

カスタム VNet の構成

カスタム VNet を作成するときは、次の状況に注意してください。

  • コンテナー アプリですべての外部アクセスを制限する場合は、内部 Container Apps 環境を作成します。

  • 独自の VNet を使用する場合は、デプロイするコンテナー アプリ環境専用のサブネットを指定する必要があります。 このサブネットは、他のサービスでは使用できません。

  • ネットワーク アドレスは、環境の作成時に定義したサブネット範囲から割り当てられます。

    • Container Apps 環境で使われるサブネットの範囲を定義できます。

    • 環境を内部としてデプロイすることで、環境へのインバウンド要求を VNet だけに制限できます。

Note

独自の仮想ネットワークを指定すると、追加の管理対象リソースが作成されます。 これらのリソースでは、それらに関連付けられた料金でコストが発生します。

コンテナー アプリに関するネットワークの設計を始めるときは、「仮想ネットワークを計画する」をご覧ください。

Azure Container Apps 環境で既存の VNET がどのように使用されているか、または独自の VNET を提供する方法の図。

Note

VNet が Container Apps 環境によって使われている場合、異なるリソース グループ間またはサブスクリプション間で VNet を移動することは許可されていません。

HTTP エッジ プロキシの動作

Azure Container Apps では、エッジ HTTP プロキシとして Envoy プロキシが使われます。 トランスポート層セキュリティ (TLS) はエッジで終了されて、要求はトラフィック分割ルールに基づいてルーティングされ、トラフィックは正しいアプリケーションにルーティングされます。

HTTP アプリケーションは、HTTP の要求と接続の数に基づいてスケーリングされます。 Envoy は、内部トラフィックをクラスターの内部でルーティングします。

ダウンストリーム接続では HTTP1.1 と HTTP2 がサポートされ、クライアント接続をアップグレードする必要がある場合、Envo では接続を自動的に検出してアップグレードします。

アップストリーム接続は、ingress オブジェクトの transport プロパティを設定することによって定義されます。

イングレスの構成

ingress セクションでは、次の設定を構成できます。

  • アクセシビリティ レベル: コンテナー アプリは、環境内で外部アクセスまたは内部アクセス可能として設定できます。 環境の完全修飾ドメイン名 (FQDN) サフィックスを自動的に解決するには、環境変数 CONTAINER_APP_ENV_DNS_SUFFIX を使います。 同じ環境内のコンテナー アプリ間で通信する場合は、アプリ名を使用することもできます。 アプリにアクセスする方法の詳細については、「Azure Container Apps でのイングレス」を参照してください。

  • トラフィック分割ルール: アプリケーションの異なるリビジョンの間で、トラフィック分割ルールを定義できます。 詳細については、「トラフィックの分割」を参照してください。

異なるネットワークのシナリオの詳細については、「Azure Container Apps でのイングレス」を参照してください。

ポータルの依存関係

Azure Container Apps 内のすべてのアプリに、2 つの URL が存在します。

Container Apps ランタイムでは、アプリにアクセスするために使用される完全修飾ドメイン名 (FQDN) が最初に生成されます。 コンテナー アプリの FQDN は、Azure portal でコンテナー アプリの [概要] ウィンドウの [アプリケーション URL] で確認してください。

2 つ目の URL も自動的に生成されます。 この場所では、ログ ストリーミング サービスとコンソールへのアクセス権が付与されます。 必要に応じて、ファイアウォールまたはプロキシの許可リストに https://azurecontainerapps.dev/ を追加することが必要な場合があります。

ポートと IP アドレス

インバウンド接続には、次のポートが公開されます。

プロトコル ポート
HTTP/HTTPS 80、443

IP アドレスは、次の種類に分類されます。

型 説明
パブリック インバウンド IP アドレス 外部デプロイにおけるアプリケーション トラフィックのほか、内部デプロイと外部デプロイの両方における管理トラフィックに使用されます。
アウトバウンド パブリック IP 仮想ネットワークから出ていくアウトバウンド接続の "発信元" IP として使用されます。 これらの接続は VPN 経由ではルーティングされません。 送信 IP は時間の経過と共に変化する可能性があります。 Container Apps 環境からの送信トラフィックに NAT ゲートウェイまたはその他のプロキシを使用することは、ワークロード プロファイル環境でのみサポートされています。
内部ロード バランサー IP アドレス このアドレスは内部環境にのみ存在します。

Subnet

仮想ネットワーク統合は、専用サブネットに依存します。 サブネットでの IP アドレスの割り当て方法と、サポートされるサブネット サイズは、Azure Container Apps で使用しているプランによって異なります。

サブネット サイズは慎重に選択してください。 Container Apps 環境を作成した後は、サブネット サイズを変更できません。

環境の種類によって、サブネットの要件は異なります。

  • /27 は、仮想ネットワーク統合に必要な最小サブネット サイズです。

  • サブネットは、Microsoft.App/environments に委任する必要があります。

  • 外部イングレスを備えた外部環境を使用する場合、受信トラフィックはサブネットを経由するのではなく、インフラストラクチャのパブリック IP 経由でルーティングされます。

  • Container Apps では、サブネットとの統合のために 12 個の IP アドレスが自動的に予約されます。 インフラストラクチャの統合に必要な IP アドレスの数は、その環境のスケールの需要に基づいて変わるわけではありません。 使用しているワークロード プロファイルの種類に応じて、次の規則に従って追加の IP アドレスが割り当てられます。お使いの環境のワークロード プロファイルに応じて、より多くの IP アドレスが割り当てられます。

  • 単一リビジョン モードでリビジョンに変更を加えると、必要なアドレス空間は短期間 2 倍になり、ダウンタイムゼロのデプロイをサポートします。 これは、特定のサブネット サイズでサポートされる、実際に使用可能なレプリカまたはノードに影響します。 次のテーブルに、CIDR ブロック 1 つにつき使用可能なアドレスの最大数と、水平スケーリングに対する効果の両方を示します。

    サブネットのサイズ 使用可能な IP アドレス 1 最大ノード数 (専用ワークロード プロファイル) 2 最大レプリカ数 (従量課金ワークロード プロファイル) 2
    /23 500 250 2,500
    /24 244 122 1,220
    /25 116 58 580
    /26 52 26 260
    /27 20 10 100

    1 使用可能な IP アドレスは、サブネットのサイズから、Azure Container Apps インフラストラクチャに必要な 12 個の IP アドレスを引いた値です。
    2 これは、単一リビジョン モードのアプリを考慮しています。

サブネット アドレス範囲の制限

サブネットのアドレス範囲は、Azure Kubernetes Services によって予約されている次の範囲と重複できません。

  • 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 を指定します。

CLI を使っている場合、サブネット リソース ID を定義するパラメーターは infrastructure-subnet-resource-id です。 サブネットは、インフラストラクチャ コンポーネントとユーザー アプリ コンテナーをホストします。

従量課金のみの環境で Azure CLI を使っていて、PlatformReservedCidr 範囲が定義されている場合は、サブネットが platformReservedCidr で定義されている IP 範囲と重複しないようにする必要があります。

Routes

ユーザー定義ルート (UDR)

ユーザー定義ルート (UDR) と NAT ゲートウェイ経由で制御されたエグレスは、ワークロード プロファイル環境には対応していますが、 従量課金のみの環境では、これらの機能はサポートされていません。

Note

Azure Container Apps で Azure Firewall とともに UDR を使用する場合は、ファイアウォールの許可リストに特定の FQDN のタグ とサービス タグを追加する必要があります。 詳細については、「Azure Firewall を使用した UDR の構成」を参照してください。

  • ワークロード プロファイル環境で UDR を使用して、Azure Firewall またはその他のネットワーク装置を介してコンテナー アプリからのアウトバウンド トラフィックを制限できます。

  • UDR は、Container Apps 環境のスコープ外部で構成されます。

Azure Container Apps の UDR の実装方法を示す図。

Azure では、作成時に仮想ネットワークの既定のルート テーブルが作成されます。 ユーザー定義ルート テーブルを実装することで、仮想ネットワーク内でのトラフィックのルーティング方法を制御できます。 次の例では、すべてのトラフィックをファイアウォールにルーティングする UDR を作成できます。

Azure Firewall を使用した UDR の構成

ユーザー定義ルートは、ワークロード プロファイル環境でのみサポートされます。 使用しているリソースに応じて、次のアプリケーション ルールとネットワーク ルールをファイアウォールの許可リストに追加する必要があります。

Note

Azure Firewall で送信トラフィックを制限するように Container Apps で UDR を設定する方法のガイドについては、Container Apps と Azure Firewall の方法に関する記事を参照してください。

アプリケーション ルール

アプリケーション ルールでは、アプリケーション レイヤーに基づいて、トラフィックを許可または拒否します。 シナリオに基づいて、次の送信ファイアウォール アプリケーション規則が必要です。

シナリオ FQDN 説明
すべてのシナリオ mcr.microsoft.com、*.data.mcr.microsoft.com Microsoft Container Registry (MCR) のこれらの FQDN は Azure Container Apps によって使用されます。Azure Firewall とともに Azure Container Apps を使用する場合は、MCR についてのこれらのアプリケーション規則またはネットワーク規則を許可リストに追加する必要があります。
Azure Container Registry (ACR) Your-ACR-address、*.blob.core.windows.net、login.microsoft.com これらの FQDN は、ACR および Azure Firewall とともに Azure Container Apps を使用する場合に必要です。
Azure Key Vault Your-Azure-Key-Vault-address、login.microsoft.com これらの FQDN は、Azure Key Vault のネットワーク規則に必要なサービス タグに加えて必要です。
マネージド ID *.identity.azure.net、login.microsoftonline.com、*.login.microsoftonline.com, *.login.microsoft.com これらの FQDN は、Azure Container Apps で Azure Firewall とともにマネージド ID を使用する場合に必要です。
Docker Hub レジストリ hub.docker.com、registry-1.docker.io、production.cloudflare.docker.com Docker Hub レジストリを使用していて、ファイアウォール経由でアクセスする場合は、これらの FQDN をファイアウォールに追加する必要があります。
ネットワーク ルール

ネットワーク ルールでは、ネットワーク レイヤーとトランスポート レイヤーに基づいてトラフィックを許可または拒否します。 シナリオに基づいて、次の送信ファイアウォール ネットワーク規則が必要です。

シナリオ サービス タグ 説明
すべてのシナリオ MicrosoftContainerRegistry、AzureFrontDoorFirstParty Microsoft Container Registry (MCR) のこれらのサービス タグは Azure Container Apps によって使用されます。Azure Firewall とともに Azure Container Apps を使用する場合は、MCR についてのこれらのネットワーク規則またはアプリケーション規則を許可リストに追加する必要があります。
Azure Container Registry (ACR) AzureContainerRegistry、 AzureActiveDirectory Azure Container Apps とともに ACR を使用する場合は、Azure Container Registry で使用されるこれらのアプリケーション規則を構成する必要があります。
Azure Key Vault AzureKeyVault、AzureActiveDirectory これらのサービス タグは、Azure Key Vault のアプリケーション規則の FQDN に加えて必要です。
マネージド ID AzureActiveDirectory Azure Container Apps とともにマネージド ID を使用する場合は、マネージド ID で使用されるこれらのアプリケーション規則を構成する必要があります。

Note

この記事に記載されていない、Azure Firewall とともに使用している Azure リソースについては、サービス タグのドキュメントを参照してください。

NAT ゲートウェイの統合

NAT Gateway を使用すると、ワークロード プロファイル環境の仮想ネットワーク内の送信インターネット トラフィックのアウトバウンド接続を簡略化できます。

サブネット上に NAT Gateway を構成すると、NAT Gateway では環境の静的パブリック IP アドレスが提供されます。 コンテナー アプリからの送信トラフィックはすべて、NAT Gateway の静的パブリック IP アドレスを介してルーティングされます。

環境のセキュリティ

Container Apps のネットワークを完全にロックダウンする方法を示す図。

次のアクションを実行することで、イングレスおよびエグレスのネットワーク トラフィック ワークロード プロファイル環境を完全にセキュリティ保護できます。

Container Apps 環境でのピアツーピア暗号化

Azure Container Apps では、環境内のピアツーピア TLS 暗号化がサポートされています。 この機能を有効にすると、Azure Container Apps 環境スコープ内で有効なプライベート証明書を使用して、環境内のすべてのネットワーク トラフィックが暗号化されます。 これらの証明書は、Azure Container Apps によって自動的に管理されます。

Note

既定では、ピアツーピア暗号化は無効になっています。 アプリケーションに対してピアツーピア暗号化を有効にすると、高負荷のシナリオで応答の待機時間が長くなり、最大スループットが低下する可能性があります。

次の例は、ピアツーピア暗号化が有効になっている環境を示しています。 ピアツーピア暗号化を有効にしてトラフィックを暗号化/復号化する方法を示す図。

1 受信 TLS トラフィックは、環境のエッジにあるイングレス プロキシで終了します。

2 環境内のイングレス プロキシとの間のトラフィックは、プライベート証明書で TLS 暗号化され、受信側で復号化されます。

3 アプリ A からアプリ B の FQDN への呼び出しは、まずエッジ イングレス プロキシに送信され、TLS で暗号化されます。

4 アプリ B のアプリ名を使用してアプリ A からアプリ B に対して行われた呼び出しは、アプリ B に直接送信され、TLS で暗号化されます。

Container Apps 環境内のアプリケーションは自動的に認証されます。 ただし、Container Apps ランタイムでは、組み込みのピアツーピア暗号化を使用したアプリケーション間のアクセス制御の認可はサポートされていません。

アプリが環境外のクライアントと通信している場合は、mTLS を使用した双方向認証がサポートされます。 詳細については、「クライアント証明書の構成」に関するページを参照してください。

ピアツーピア暗号化は、次のコマンドを使用して有効にすることができます。

作成時:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-peer-to-peer-encryption

既存のコンテナー アプリの場合:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-peer-to-peer-encryption

DNS

  • カスタム DNS: Azure 提供の既定の DNS サーバーではなくカスタム DNS サーバーが VNet で使われている場合は、未解決の DNS クエリを 168.63.129.16 に転送するように DNS サーバーを構成します。 Azure の再帰リゾルバーは、この IP アドレスを使って要求を解決します。 NSG またはファイアウォールを構成するときに、168.63.129.16 アドレスをブロックしないでください。ブロックすると、Container Apps 環境が正しく機能しなくなります。

  • VNet スコープのイングレス: 内部環境で VNet スコープのイングレスを使う予定の場合は、次のいずれかの方法でドメインを構成します。

    1. 非カスタム ドメイン: カスタム ドメインを使わない場合は、Container Apps 環境の既定のドメインを Container Apps 環境の静的 IP アドレスに解決するプライベート DNS ゾーンを作成します。 Azure プライベート DNS または独自の DNS サーバーを使用できます。 Azure プライベート DNS を使う場合は、コンテナー アプリ環境の既定のドメイン (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io) として名前が指定されたプライベート DNS ゾーンと、A レコードを作成します。 A レコードには、Container Apps 環境の名前 *<DNS Suffix> と静的 IP アドレスが含まれています。

    2. カスタム ドメイン: カスタム ドメインを使う予定で、外部 Container Apps 環境を使用している場合、パブリックに解決可能なドメインを使って、コンテナー アプリにカスタム ドメインと証明書を追加します。 内部 Container Apps 環境を使用している場合、クラスターには仮想ネットワーク内からのみアクセスできるため、DNS バインドの検証はありません。 さらに、Apex ドメインを Container Apps 環境の静的 IP アドレスに解決するプライベート DNS ゾーンを作成します。 Azure プライベート DNS または独自の DNS サーバーを使用できます。 Azure プライベート DNS を使う場合は、Apex ドメインとして名前が指定されたプライベート DNS ゾーンと、Container Apps 環境の静的 IP アドレスを指す A レコードを作成します。

Container Apps 環境の静的 IP アドレスは、Azure portal のコンテナー アプリ ページの [カスタム DNS サフィックス] か、Azure CLI の az containerapp env list コマンドを使用して取得できます。

マネージド リソース

内部環境または外部環境を独自のネットワークにデプロイすると、お使いの環境がホストされている Azure サブスクリプションに新しいリソース グループが作成されます。 このリソース グループには、Azure Container Apps プラットフォームによって管理されるインフラストラクチャ コンポーネントが含まれています。 このグループ内のサービスや、リソース グループ自体を変更しないでください。

ワークロード プロファイル環境

お使いの環境がホストされている Azure サブスクリプションで作成されたリソース グループの名前には、既定で ME_ が先頭に付けられ、このリソース グループ名は、コンテナー アプリ環境を作成するときにカスタマイズすることが "できます"。

外部環境の場合、リソース グループには外部環境への受信接続に特に使用されるパブリック IP アドレスと、ロード バランサーが含まれます。 内部環境の場合、リソース グループにはロード バランサーのみが含まれます。

標準の Azure Container Apps の課金に加え、次の料金が課金されます。

従量課金のみの環境

お使いの環境がホストされている Azure サブスクリプションで作成されたリソース グループの名前には、既定で MC_ が先頭に付けられ、このリソース グループ名は、コンテナー アプリを作成するときにカスタマイズすることが "できません"。 リソース グループには、環境とロード バランサーからのアウトバウンド接続専用に使われるパブリック IP アドレスが含まれます。

標準の Azure Container Apps の課金に加え、次の料金が課金されます。

次のステップ