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

[アーティクル]
11/19/2024

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` です。

仮想 IP

仮想 IP の構成に応じて、コンテナーアプリ環境で、パブリックイングレスを許可するか、それとも環境レベルでの 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 アドレスが割り当てられます。
- 専用ワークロードプロファイル: コンテナーアプリがスケールアウトすると、各ノードに 1 つの IP アドレスが割り当てられます。
- 従量課金ワークロードプロファイル: 各 IP アドレスは、複数のレプリカ間で共有することができます。アプリに必要な IP アドレスの数を計画する際は、10 のレプリカごとに 1 つの IP アドレスを計画します。

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

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

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

/23 は、仮想ネットワーク統合に必要な最小サブネットサイズです。
サブネットをサービスに委任することはできません。
Container Apps ランタイムには、VNet 内のインフラストラクチャ用に少なくとも 60 個の IP が予約されています。予約される量は、環境内のアプリの拡大縮小に合わせて、最大 256 個のアドレスまで増大することがあります。
アプリの拡大縮小に合わせて、新しいレプリカ用の新しい 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 アドレスを介してルーティングされます。

公衆ネットワークアクセス (プレビュー)

公衆ネットワークアクセスの設定により、パブリックインターネットからコンテナーアプリ環境にアクセスできるかどうかが決まります。環境の作成後にこの設定を変更できるかどうかは、環境の仮想 IP の構成によって異なります。次の表では、環境の仮想 IP 構成に基づく、公衆ネットワークアクセスの有効な値を示します。

仮想 IP	サポートされている公衆ネットワークアクセス	説明
外部	`Enabled`、`Disabled`	コンテナーアプリ環境は、インターネットアクセス可能なエンドポイントを使って作成されました。公衆ネットワークアクセスの設定により、パブリックエンドポイント経由のトラフィックを受け入れるか、それともプライベートエンドポイント経由のみを受け入れるかが決まります。パブリックネットワークアクセスの設定は、環境の作成後に変更できます。
Internal	`Disabled`	コンテナーアプリ環境は、インターネットアクセス可能なエンドポイントを使わずに作成されました。公衆ネットワークアクセスの設定を変更して、インターネットからのトラフィックを受け入れることはできません。

Azure Container Apps 環境にプライベートエンドポイントを作成するには、公衆ネットワークアクセスを Disabled に設定する必要があります。

Azure ネットワークポリシーは、パブリックネットワークアクセスフラグでサポートされています。

プライベートエンドポイント (プレビュー)

Note

この機能は、すべてのパブリックリージョンでサポートされています。政府と中国のリージョンはサポートされていません。

Azure プライベートエンドポイントを使って、プライベートネットワーク内にあるクライアントを、Azure Private Link 経由で Azure Container Apps 環境に安全に接続できます。プライベートリンク接続を使うと、パブリックインターネットへの露出がなくなります。プライベートエンドポイントでは、Azure 仮想ネットワークアドレス空間内のプライベート IP アドレスが使われます。

この機能は、ワークロードプロファイル環境の従量課金プランと専用プランの両方でサポートされています。

チュートリアル

Azure Container Apps でプライベートエンドポイントを構成する方法について詳しくは、Azure Container Apps 環境でのプライベートエンドポイントの使用に関するチュートリアルをご覧ください。
Azure Container Apps では、Azure Front Door とのプライベートリンク接続がサポートされています。詳しくは、Azure Front Door とのプライベートリンクの作成に関する記事をご覧ください。

考慮事項

Azure Container Apps のプライベートエンドポイントでは、インバウンドの HTTP トラフィックのみがサポートされています。 TCP トラフィックはサポートされていません。
カスタムドメインでプライベートエンドポイントを使用し、"ホスト名レコードの種類" が "Apex ドメイン" の場合は、パブリック DNS と同じ名前でプライベート DNS ゾーンを構成する必要があります。レコードセットで、コンテナーアプリ環境の IP アドレスではなく、プライベートエンドポイントのプライベート IP アドレスを構成します。 CNAME でカスタムドメインを構成していると、セットアップは変更されません。詳細については、「既存の証明書を使用してカスタムドメインを設定する」を参照してください。
プライベートエンドポイントの VNet は、コンテナーアプリと統合された VNet とは別にすることができます。
新規と既存どちらのワークロードプロファイル環境にでも、プライベートエンドポイントを追加できます。

プライベートエンドポイントを介してコンテナーアプリに接続するには、プライベート DNS ゾーンを構成する必要があります。

サービス	subresource	プライベート DNS ゾーンの名前
Azure Container Apps (Microsoft.App/ManagedEnvironments)	managedEnvironment	privatelink.{regionName}.azurecontainerapps.io

環境のセキュリティ

Note

イングレストラフィックを制御するには、Application Gateway の代わりに、Azure Front Door へのプライベート接続でプライベートエンドポイントを使うこともできます。この機能はプレビュー段階にあります。

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

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

ワークロードプロファイル環境で内部コンテナーアプリ環境を作成します。手順については、「Azure CLI を使用してワークロードプロファイルを管理する」を参照してください。
Container Apps を Application Gateway と統合します。
すべてのトラフィックを Azure Firewall 経由でルーティングするために UDR を構成します。

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

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

Note

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

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

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

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

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

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

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

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

Azure CLI
ARM テンプレート

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

作成時:

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

次の構成を使用して、Container Apps 環境の ARM テンプレートで mTLS を有効にすることができます。

{
  ...
  "properties": {
       "peerTrafficConfiguration":{
            "encryption": {
                "enabled": "true|false"
            }
        }
  ...
}

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 アドレスが含まれています。詳細については、「Azure プライベート DNS ゾーンの作成と構成」に関する記事を参照してください。
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 の課金に加え、次の料金が課金されます。

内部環境または外部環境を使用する場合は、エグレス用の 1 つの標準静的パブリック IP、外部環境を使用する場合は、イングレス用の 1 つの標準静的パブリック IP。 SNAT の問題が原因でエグレスにさらにパブリック IP が必要な場合は、サポートチケットを開いてオーバーライドを要求してください。
1 つの標準ロードバランサー。
処理済みデータのコスト (GB 単位) には、管理操作のイングレスとエグレスの両方が含まれます。

従量課金のみの環境

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

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

エグレス用の 1 つの標準静的パブリック IP。送信元ネットワークアドレス変換 (SNAT) の問題が原因でエグレスにさらに IP が必要な場合は、サポートチケットを開いてオーバーライドを要求してください。
内部環境を使用する場合は 2 つの標準ロードバランサー、外部環境を使用する場合は 1 つの標準ロードバランサー。各ロードバランサーの規則は 6 未満です。処理済みデータのコスト (GB 単位) には、管理操作のイングレスとエグレスの両方が含まれます。

次のステップ

カスタム仮想ネットワークを使用する

次の方法で共有

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

環境の選択

仮想 IP

カスタム VNet の構成

HTTP エッジプロキシの動作

イングレスの構成

ポータルの依存関係

ポートと IP アドレス

Subnet

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

CLI を使用したサブネット構成

Routes

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

Azure Firewall を使用した UDR の構成

アプリケーションルール

ネットワークルール

NAT ゲートウェイの統合

公衆ネットワークアクセス (プレビュー)

プライベートエンドポイント (プレビュー)

チュートリアル

考慮事項

環境のセキュリティ

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

DNS

マネージドリソース

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

従量課金のみの環境

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

環境の選択

仮想 IP

カスタム VNet の構成

HTTP エッジ プロキシの動作

イングレスの構成

ポータルの依存関係

ポートと IP アドレス

Subnet

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

CLI を使用したサブネット構成

Routes

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

Azure Firewall を使用した UDR の構成

アプリケーション ルール

ネットワーク ルール

NAT ゲートウェイの統合

公衆ネットワーク アクセス (プレビュー)

プライベート エンドポイント (プレビュー)

チュートリアル

考慮事項

環境のセキュリティ

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

DNS

マネージド リソース

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

従量課金のみの環境

次のステップ

フィードバック

その他のリソース

HTTP エッジプロキシの動作

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

アプリケーションルール

ネットワークルール

公衆ネットワークアクセス (プレビュー)

プライベートエンドポイント (プレビュー)

マネージドリソース

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