Azure Container Apps のネットワーク設計で最初に決めるべきことは、環境タイプ、仮想ネットワークの種類、公開範囲の3つです。2026年5月20日時点の公式情報では、Workload profiles 環境を前提に、既存 VNet、Private Endpoint、Public network access、UDR、Azure Firewall、NAT Gateway をどう組み合わせるかが重要になります。特に、既定の Azure ネットワークを使うか、既存の VNet に統合するかは環境作成後に変更できないため、後から閉域化したいシステムでは作成前の設計が肝心です。(Microsoft Learn)
結論として、社内システム、基幹 API、プライベートなバックエンド接続を扱う場合は、Workload profiles 環境 + 既存 VNet + Private Endpoint または内部環境 + DNS/送信制御の設計を最初から検討してください。一方、PoC や単純な公開 Web アプリであれば既定のネットワークでも始められますが、将来の NSG、Azure Firewall、Application Gateway、Private Link 連携まで見込むなら、最初から既存 VNet を使う判断が安全です。(Microsoft Learn)
Azure Container Apps のネットワーク更新で押さえるべきポイント
今回の公式情報は、単に「Azure Container Apps で VNet が使える」という説明ではなく、ネットワーク機能がどの環境タイプで使えるのか、どの設定が後から変えられないのかを整理する内容として読むべきです。実務上は、次の点を確認しておくと判断しやすくなります。
| 確認ポイント | 実務上の影響 | 管理者・開発者が取るべき対応 |
|---|---|---|
| Workload profiles 環境が既定 | UDR、NAT Gateway、Private Endpoint など本番向けネットワーク機能を使いやすい | 新規環境は Workload profiles を前提に設計する |
| Consumption-only はレガシー | UDR、NAT Gateway、カスタム送信制御などに制約がある | 既存環境では利用中の機能と移行要否を棚卸しする |
| VNet の種類は作成後に変更不可 | 既定ネットワークから既存 VNet 統合へ後から切り替えられない | 本番化前に VNet 統合の必要性を判断する |
| Public network access は環境の公開制御に関わる | Private Endpoint を使うには無効化が必要 | 外部公開、Private Link、内部専用のどれにするか決める |
| サブネットサイズは後から変更できない | レプリカ増加やゼロダウンタイム更新で IP が不足する可能性がある | 最小サイズではなく将来のスケールを見積もる |
| 送信元 IP は変わる可能性がある | 外部 SaaS や取引先の IP 許可リストで問題になりやすい | NAT Gateway または Firewall 経由の固定化を検討する |
Workload profiles 環境は、UDR、Azure NAT Gateway による送信、Container Apps 環境での Private Endpoint 作成をサポートします。一方、Consumption-only 環境はレガシー扱いで、これらの高度な送信制御やカスタム egress に制約があります。(Microsoft Learn)
環境タイプは Workload profiles を基準に選ぶ
Azure Container Apps には、Workload profiles 環境と Consumption-only 環境があります。新規作成では Workload profiles が既定かつ推奨されており、Consumption-only はレガシーの選択肢として扱われます。消費課金を使いたい場合でも、Workload profiles 環境内の Consumption profile を使う構成が推奨されています。(Microsoft Learn)
| 項目 | Workload profiles 環境 | Consumption-only 環境 |
|---|---|---|
| 位置づけ | 既定・推奨 | レガシー |
| 利用できるプラン | Consumption、Dedicated | Consumption のみ |
| VNet 統合時の最小サブネット | /27 | /23 |
| UDR | 対応 | 非対応または制約あり |
| Azure NAT Gateway | 対応 | 非対応 |
| Private Endpoint | 対応 | 環境タイプとしては対象外 |
| 向いている用途 | 本番、閉域接続、送信制御、将来拡張 | 既存の単純な Consumption-only 構成 |
「従量課金でよいから Consumption-only で作る」という判断は、今後の拡張性を狭める可能性があります。最初は小規模でも、将来 Azure Firewall、Private Endpoint、Application Gateway、プライベートなデータベース接続が必要になりそうなら、Workload profiles 環境を選ぶのが無難です。
VNet 統合は環境作成前に決める
Azure Container Apps 環境は、既定では Azure 側で用意されるネットワークに統合されます。この構成ではインターネット上の到達可能なエンドポイントとの通信が中心になります。一方、既存 VNet を指定すると、NSG、Application Gateway、Azure Firewall、送信トラフィック制御、Private Endpoint 背後のリソースへのアクセスなど、Azure Networking の機能を組み合わせやすくなります。(Microsoft Learn)
重要なのは、既定の Azure ネットワークか既存 VNet かは、環境作成後に変更できないという点です。後から「やはり社内ネットワークからだけアクセスさせたい」「DB を Private Endpoint 経由にしたい」「送信を Firewall に集約したい」となった場合、既存環境の設定変更だけでは対応できず、新しい Container Apps 環境の作成とアプリの再展開が必要になる可能性があります。(Microsoft Learn)
既存 VNet を選ぶべきケース
次の条件に1つでも当てはまる場合は、既定ネットワークではなく既存 VNet への統合を検討してください。
- Azure SQL Database、Storage、Key Vault、API Management などへ Private Endpoint 経由で接続したい
- Azure Firewall で送信先 FQDN やサービス タグを制御したい
- 送信元 IP を固定して、外部サービスの許可リストに登録したい
- Application Gateway や WAF と組み合わせたい
- NSG でサブネット単位の通信制御をしたい
- ExpressRoute、VPN、ハブ・スポーク構成など既存ネットワーク設計に組み込みたい
既存 VNet を使う場合、Container Apps 環境専用のサブネットが必要です。このサブネットは他サービスと共有できません。また、Container Apps 環境が利用している VNet を別のリソースグループやサブスクリプションへ移動することはできません。(Microsoft Learn)
サブネットサイズは最小値ではなく将来のスケールで決める
Workload profiles 環境では、VNet 統合に最低 /27 のサブネットが必要です。ただし、本番環境で最小サイズをそのまま採用すると、後からレプリカ数、ノード数、リビジョン更新時の一時的な IP 消費で余裕がなくなることがあります。サブネットサイズは環境作成後に変更できないため、作成前の見積もりが重要です。(Microsoft Learn)
| サブネットサイズ | 利用可能 IP アドレス | Dedicated workload profile の最大ノード目安 | Consumption workload profile の最大レプリカ目安 |
|---|---|---|---|
/27 | 18 | 9 | 90 |
/26 | 50 | 25 | 250 |
/25 | 114 | 57 | 570 |
/24 | 242 | 121 | 1,210 |
/23 | 498 | 249 | 2,490 |
この目安は、単一リビジョンモードでのゼロダウンタイム更新時に必要なアドレス空間の増加も考慮されています。実務では、開発・検証環境なら /27 でも足りる場合がありますが、本番環境では /26 以上、将来の複数アプリ集約やDedicatedノード増加を見込むなら /24 以上も検討したいところです。(Microsoft Learn)
また、Workload profiles 環境ではサブネットを Microsoft.App/environments に委任する必要があります。一方、Consumption-only 環境ではサブネットをサービスに委任してはいけないため、既存の環境タイプを確認せずに IaC テンプレートを流用すると失敗しやすくなります。(Microsoft Learn)
Public network access と Ingress を混同しない
Azure Container Apps の公開制御で混乱しやすいのが、環境レベルの公開設定とアプリ単位の Ingress 設定の違いです。
環境レベルでは、External と Internal のアクセシビリティがあります。External 環境はパブリックに到達可能な仮想 IP を持ち、Public network access を Enabled または Disabled に変更できます。Internal 環境はパブリックエンドポイントを持たず、内部ロードバランサーの IP を使うため、Public network access を後からインターネット受け入れに変更することはできません。(Microsoft Learn)
アプリ単位では、Ingress を有効化して、External ingress または Internal ingress を選びます。External ingress は環境の受信 IP 経由で公開されますが、その環境が内部環境であれば到達範囲は VNet 側になります。Internal ingress は同じ Container Apps 環境内の他アプリからの到達に限定されます。(Microsoft Learn)
| やりたいこと | 推奨構成 | 注意点 |
|---|---|---|
| インターネットへ公開する Web/API | External 環境 + External ingress + Public network access Enabled | 必要に応じて IP 制限、WAF、認証を追加する |
| VNet 内からだけアクセスさせる | Internal 環境 + External ingress | DNS と内部ロードバランサーの到達性を確認する |
| 同じ Container Apps 環境内だけで通信する | アプリを Internal ingress にする | 外部クライアントからは直接アクセスできない |
| Private Link 経由でアクセスさせる | Workload profiles 環境 + Public network access Disabled + Private Endpoint | Private DNS Zone の設定が必須 |
| 将来、公開/非公開を切り替える余地を残す | External 環境で Public network access を制御 | Internal 環境はインターネット受け入れに変更できない |
Private Endpoint を使う場合は、Public network access を Disabled にする必要があります。既定では Public network access が有効であり、その状態では Private Endpoint は無効です。(Microsoft Learn)
Private Endpoint では DNS 設計を後回しにしない
Private Endpoint は、Azure Private Link を使って Container Apps 環境へプライベート IP で接続するための構成です。インターネットへ公開せずにアプリへアクセスできるため、社内 API、管理系アプリ、バックエンドサービスに向いています。Private Endpoint は Workload profiles 環境の Consumption と Dedicated の両方のプランでサポートされています。(Microsoft Learn)
ただし、Private Endpoint は作成するだけでは不十分です。Container Apps へ名前解決できるよう、Private DNS Zone を構成する必要があります。Azure Container Apps の Private DNS Zone 名は、privatelink.{regionName}.azurecontainerapps.io です。(Microsoft Learn)
カスタムドメインを apex domain で使う場合は、公開 DNS と同じ名前の Private DNS Zone を作成し、Container Apps 環境の IP ではなく Private Endpoint のプライベート IP を A レコードに設定する必要があります。CNAME を使う構成では、基本的なセットアップは変わりません。(Microsoft Learn)
カスタム DNS サーバーを使う場合は、未解決の DNS クエリを 168.63.129.16 へ転送する設計も確認してください。Consumption plan では AzurePlatformDNS サービス タグへの通信を許可する必要があり、これをブロックすると Container Apps 環境が正常に機能しなくなる可能性があります。(Microsoft Learn)
送信トラフィックは NAT Gateway、UDR、Azure Firewall で設計する
Azure Container Apps から外部へ出ていく通信では、送信元 IP と送信先制御が問題になりやすくなります。公式情報では、Outbound public IP は時間とともに変わる可能性があると説明されています。取引先 API や SaaS で送信元 IP の許可リストが必要な場合、Container Apps の素の送信 IP に依存する設計は避けるべきです。(Microsoft Learn)
送信元 IP を固定したい場合は、Workload profiles 環境のサブネットに Azure NAT Gateway を関連付ける構成が有効です。NAT Gateway を構成すると、Container Apps からの送信トラフィックを NAT Gateway の静的パブリック IP 経由にできます。ただし、Azure NAT Gateway の StandardV2 SKU は Container Apps 統合ではサポートされていません。(Microsoft Learn)
送信先をより厳密に制御したい場合は、UDR で 0.0.0.0/0 を Azure Firewall へ向け、Firewall policy で許可する FQDN やサービスを管理します。UDR は既定の Workload profiles 環境タイプでのみサポートされ、Consumption-only 環境ではサポートされません。(Microsoft Learn)
| 目的 | 推奨構成 | 失敗しやすいポイント |
|---|---|---|
| 送信元 IP を固定したい | Azure NAT Gateway | Workload profiles 環境が前提。StandardV2 SKU は使えない |
| 送信先を制御したい | UDR + Azure Firewall | MCR、ACR、Microsoft Entra ID、Azure Monitor など必要通信を許可し忘れる |
| コンテナーイメージを安全に取得したい | ACR の Private Endpoint または Firewall 許可 | レジストリ通信を遮断するとリビジョン起動に失敗する |
| 外部公開環境で受信を NSG だけで絞りたい | 設計を見直す | External workload profile 環境のパブリック受信はサブネット経由ではない |
| 社内閉域アプリにしたい | Internal 環境 + DNS + 必要に応じて Application Gateway | Ingress と Public network access の違いを混同しやすい |
External workload profile 環境では、Container Apps への受信トラフィックはマネージドリソースグループ内のパブリック IP 経由でルーティングされ、サブネットを経由しません。そのため、外部公開されている受信トラフィックを NSG や Firewall だけでロックダウンする構成はサポートされません。閉域性を重視するなら、Internal 環境や Private Endpoint、Application Gateway/WAF、Azure Front Door Private Link との組み合わせを検討してください。(Microsoft Learn)
管理者が確認すべき設定チェックリスト
Azure Container Apps 環境を運用している管理者は、ネットワーク変更の前に次の項目を確認してください。
| 確認項目 | 見るべきポイント | NG例 |
|---|---|---|
| 環境タイプ | Workload profiles か Consumption-only か | Consumption-only で UDR や NAT Gateway を前提にする |
| VNet 統合 | 既定ネットワークか既存 VNet か | 本番化後に既存 VNet へ切り替えようとする |
| サブネット | CIDR、委任、IP 余裕、重複アドレス | /27 で本番複数アプリを詰め込む |
| Public network access | Enabled/Disabled と Virtual IP | Private Endpoint 利用時に Enabled のままにする |
| Ingress | External/Internal、HTTP/TCP、target port | 内部専用アプリを External ingress で公開する |
| DNS | Private DNS Zone、カスタム DNS、168.63.129.16 | 必須 FQDN や Azure DNS をブロックする |
| NSG | 必須の受信/送信ルール | Azure Load Balancer probe や Envoy 関連通信を遮断する |
| 送信制御 | NAT Gateway、UDR、Firewall policy | MCR、ACR、認証、監視系の通信を許可しない |
| マネージドリソース | ME_ または MC_ 系リソースグループ | プラットフォーム管理リソースを手動変更する |
| 運用監視 | 環境状態、Azure Policy、VNet 設定 | 失敗状態を長期間放置する |
既存 VNet を使うと、Container Apps のプラットフォームが管理するリソースグループが作成されます。この中のロードバランサーやパブリック IP などのリソースは手動で変更しないでください。また、構成によっては標準パブリック IP やロードバランサーなどの追加コストも発生します。(Microsoft Learn)
運用面では、VNet や Azure Policy の構成不備により環境が失敗状態になったり、インフラ更新をブロックしたりする状態が長く続くと問題になります。公式情報では、アイドル状態、失敗状態、インフラ更新ブロックが90日を超えて続く場合、環境が自動削除される可能性があると説明されています。(Microsoft Learn)
Azure Portal のログストリーミングやコンソール機能を使う場合は、https://azurecontainerapps.dev/ へのアクセス許可も確認してください。企業プロキシや Firewall でこの URL がブロックされていると、アプリ本体は動いていてもポータル上の操作や調査が不便になります。(Microsoft Learn)
開発者がデプロイ前に確認すべきこと
開発者は、ネットワーク設定を「インフラ担当だけの話」として扱わないほうがよいです。Ingress、ポート、リビジョン、ヘッダー、コンテナーイメージ取得は、アプリの動作に直接影響します。
HTTP Ingress を有効にすると、Azure Container Apps は TLS 終端、HTTP/1.1、HTTP/2、WebSocket、gRPC をサポートします。HTTPS エンドポイントは TLS 1.2 または 1.3 を使用し、HTTP のリクエストタイムアウトは240秒です。長時間処理の API やストリーミング処理では、この制約を前提に設計してください。(Microsoft Learn)
TCP Ingress も利用できますが、外部 TCP Ingress は VNet を使う Container Apps 環境でのみサポートされます。追加 TCP ポートを使う場合、外部公開ポートは環境全体で一意である必要があり、追加ポートはアプリごとに最大5つです。また、CORS やセッションアフィニティなどの組み込み HTTP 機能はメインの Ingress ポートでのみ利用できます。(Microsoft Learn)
クライアント IP をアプリ側で扱う場合は、X-Forwarded-For の扱いにも注意が必要です。Container Apps は Ingress でリクエストメタデータのヘッダーを付与しますが、ヘッダー値はアプリ側で信頼境界を考えて検証する必要があります。(Microsoft Learn)
デプロイ前の確認には、Azure Portal だけでなく Azure CLI も使うと効率的です。環境の全体設定は az containerapp env show、アプリの Ingress 設定は az containerapp ingress show で確認できます。(Microsoft Learn)
az containerapp env show \
--resource-group <resource-group> \
--name <environment-name> \
--output jsonc
az containerapp ingress show \
--resource-group <resource-group> \
--name <container-app-name> \
--output jsonc既存環境から移行・再展開するときの注意点
既定ネットワークで作成した Container Apps 環境を、後から既存 VNet 統合へ変更することはできません。閉域化、Private Endpoint、Azure Firewall 経由の送信制御が必要になった場合は、新しい環境を作成し、アプリを再展開して切り替える計画を立てます。(Microsoft Learn)
移行時は、単にコンテナーイメージを再デプロイするだけでは不十分です。次の項目を移行チェックリストに入れてください。
| 移行対象 | 確認内容 |
|---|---|
| Container Apps 環境 | 環境タイプ、リージョン、VNet、サブネット、Public network access |
| アプリ設定 | 環境変数、シークレット、マネージド ID、スケールルール |
| Ingress | External/Internal、target port、カスタムドメイン、証明書 |
| DNS | 既定 FQDN、Private DNS Zone、カスタムドメインの A/CNAME レコード |
| 通信経路 | Private Endpoint、UDR、NAT Gateway、Firewall policy |
| イメージ取得 | ACR、MCR、Docker Hub、Private Endpoint または Firewall 許可 |
| 監視 | Log Analytics、Application Insights、Azure Monitor 送信許可 |
| 切り替え | DNS TTL、リビジョン、トラフィック分割、ロールバック手順 |
移行で特に見落としやすいのは DNS です。Private Endpoint を使う場合、アプリの FQDN がプライベート IP に解決されることを確認しなければ、ネットワーク設定が正しくても接続できません。内部環境でカスタムドメインを使う場合も、VNet 内で正しい静的 IP へ名前解決できるように Private DNS Zone または独自 DNS サーバーを構成します。(Microsoft Learn)
まず何から対応すべきか
これから Azure Container Apps を新規構築するなら、最初に「公開 Web アプリなのか」「VNet 内部アプリなのか」「Private Link で公開するのか」を決めてください。そのうえで、Workload profiles 環境を前提に、既存 VNet の有無、サブネットサイズ、Public network access、Ingress、Private DNS、送信制御を設計します。
既存環境を運用している場合は、まず環境タイプと VNet 統合の有無を棚卸ししてください。Consumption-only 環境や既定ネットワーク環境を使っていて、今後 UDR、NAT Gateway、Private Endpoint、Azure Firewall が必要になるなら、設定変更ではなく新環境への再展開を含めて計画するのが現実的です。
Azure Container Apps のネットワークは、後から柔軟に変えられる項目と、作成時に決めるべき項目が混在しています。失敗を避けるには、アプリをデプロイする前に「受信」「送信」「DNS」「サブネット」「運用監視」を1枚の設計図に落とし込み、管理者と開発者で同じ前提を確認することが最短ルートです。
コメント