エンタープライズ案件で必ず問われるのがネットワークとセキュリティです。「外部に出さず、VNet内に閉じたい」「WAFを前段に置きたい」「アウトバウンドをFirewallで制御したい」——これらに答えられないと、本番には載りません。
この記事は、Microsoft Learnのネットワークドキュメントに忠実に、Azure Container Apps（ACA）の本番ネットワーク設計を解説します。私はAWSでAPI Gateway→NLB→ALB→ECSの多層構成を本番運用し、WAFの多層防御を設計してきました。「信頼境界をネットワークで作る」発想はAzureでも同型です。ACA全体は Azure Container Apps 本番運用ガイド を参照してください。
大前提：環境がVNetを持つ
Azure Container Apps operates in the context of an environment, which runs its own virtual network.（— Networking in an Azure Container Apps Environment）
ネットワークはアプリ単位ではなく環境単位です。同じ環境のアプリはVNetを共有します。設計で最初に決めるべきは3つ——環境タイプ・VNetタイプ・アクセシビリティレベル。そして決定的な制約：
After you create an environment with either the default Azure network or an existing virtual network, you can't change the network type.
ネットワークタイプは作成後に変更できません。最初の設計が後戻りできないので、ここは慎重に。
環境タイプとサブネットサイズ
| 環境タイプ | 対応プラン | 機能 | 最小サブネット |
|---|---|---|---|
| ワークロードプロファイル（既定） | Consumption, Dedicated | UDR・NAT Gateway・Private Endpoint対応 | /27 |
| Consumption only（レガシー） | Consumption | UDR・NAT Gateway・リモートゲートウェイ等非対応 | /23 |
本番でネットワークを制御したいなら、ワークロードプロファイル環境一択です。UDR（user-defined routes）・NAT Gateway・Private Endpointという、egress制御と非公開化の要が揃うのはこちらだけ。
サブネットはACA環境専用でなければなりません。
you need to provide a subnet that's dedicated exclusively to the Container Apps environment that you deploy. This subnet isn't available to other services.——他サービスと相乗りさせない、専用サブネットを切ります。
アクセシビリティ：External と Internal
環境作成時に、公開するか内部に閉じるかを選びます。
| レベル | 説明 |
|---|---|
| External | 公開IP（外部向けの仮想IP）を持ち、インターネットからのリクエストを受けられる。 |
| Internal | 公開エンドポイントを持たず、内部IP（Azure内部ロードバランサ）にマップされる。VNetのプライベートIPから払い出される。 |
そしてpublic network accessの挙動が、仮想IP構成に依存します。
| 仮想IP | 設定可能なpublic network access |
|---|---|
| External | Enabled / Disabled（作成後も変更可） |
| Internal | Disabledのみ（インターネット受信に変更不可） |
Private Endpointを作るには、
To create private endpoints in your Container Apps environment, you must set public network access to Disabled.——public network accessをDisabledにする必要があります。Internal環境はこれが常にDisabledなので、Private Endpoint運用の自然な土台になります。
多層防御アーキテクチャ：本番の定石
公式が示す「ロックダウン」構成を、実務の形にまとめます。
[Internet]
│
┌─────────────▼──────────────┐
│ Application Gateway + WAF │ ← OWASP対策・L7防御・公開接点はここだけ
└─────────────┬──────────────┘
│ (VNet内のプライベート通信)
┌─────────────────────▼─────────────────────┐
│ Internal ACA Environment（専用サブネット /27） │
│ ├─ public-api (External Ingress: 環境内) │
│ ├─ order-worker (Ingress無し / Service Bus駆動)│
│ └─ nightly-report (Schedule Job) │
└─────────────────────┬─────────────────────┘
│ egress
┌─────────────▼──────────────┐
│ UDR → Azure Firewall │ ← 全アウトバウンドを検査・許可リスト制御
└─────────────┬──────────────┘
▼
許可した宛先（ACR/Key Vault/外部API）のみ
公式の「環境セキュリティ」の指針そのままです。
- Create your internal Container Apps environment in a workload profile environment.
- Integrate Container Apps with Application Gateway.
- Configure a UDR to route all traffic through Azure Firewall.（— networking）
① 前段：Application Gateway ＋ WAF
公開接点をApplication Gateway（WAF付き）に一本化し、ACA環境はInternalにして直接インターネットに晒さない。WAFでOWASP Top 10（SQLi・XSS等）を弾く。AWSでいう「ALB＋AWS WAF」をAzureでApplication Gateway＋WAFに置き換えた形です（WAF多層防御の設計思想）。
② 非公開化：Private Endpoint / Front Door
- Private Endpoint：ACA環境をVNet内のプライベートIPで公開し、インターネット非経由でアクセス。public network accessをDisabledにして使う。
- Azure Front Door：
Connect directly from Azure Front Door to a container app by using a private link instead of the public internet.——Front DoorからPrivate Link経由で接続し、グローバルなエッジ／CDN／WAFを前段に置ける。
③ egressロックダウン：UDR ＋ Azure Firewall
アウトバウンドをUDRで全部Azure Firewallに迂回させ、許可した宛先（ACR・Key Vault・特定の外部API）以外への通信を遮断します。データ持ち出し（exfiltration）対策の要。これはワークロードプロファイル環境でのみ可能です。
アウトバウンドIPとNAT Gateway
外部APIのIP許可リストに登録したい、固定のegress IPが欲しい——という要件は珍しくありません。ここに注意点があります。
Outbound IPs might change over time. Using Azure NAT Gateway or another proxy for outbound traffic from a Container Apps environment is supported only in a workload profile environment.（— networking）
既定のアウトバウンドIPは変動しうる。固定したいならNAT Gateway（ワークロードプロファイル環境限定）で安定したegress IPを確保します。「取引先のAPIにIP許可リスト登録が必要」な業務連携で必須になるパターンです。
Ingressとプロトコル：ネットワーク観点の要点
- 公開ポートは80/443のみ（HTTP/HTTPS）。HTTPSはTLS終端され、80→443へ自動リダイレクト。
- EnvoyエッジプロキシがTLS終端とルーティングを担う。HTTP/1.1・HTTP/2を自動検出してアップグレード。
- 外部TCP Ingressはやや特殊：
External TCP ingress is only supported for Container Apps environments that use a virtual network.——外部TCP公開はVNet必須。 - path-based routing：1つの環境内で、パスに応じて複数のコンテナアプリへルーティングできる。
- IP制限・mTLS（クライアント証明書）・セッションアフィニティ・CORSは、Ingress設定で有効化。
DNSの落とし穴
VNet統合で最も多いトラブルがDNSです。カスタムDNSを使う環境では、これを忘れるとイメージpullや管理通信が失敗します。
Azure recursive resolvers uses the IP address
168.63.129.16to resolve requests.（— troubleshooting）
- カスタムDNSサーバーを使うなら、未解決クエリを
168.63.129.16へ転送する設定にする。 - NSGやファイアウォールで**
168.63.129.16をブロックしない**。 - マネージドIDを使うなら、トークンエンドポイント**
login.microsoft.com（または<REGION>.login.microsoft.com）への到達性**を確保する。 - ACR等のプライベートレジストリを使うなら、そのFQDNを名前解決・到達できること。
UDR＋Firewallでegressを締めるときは、これらの必須宛先を許可リストに入れるのを忘れずに。
NSGによる多層化
VNet統合した環境は、サブネットに**NSG（ネットワークセキュリティグループ）**を付けて、インバウンド／アウトバウンドをさらに細かく制御できます。公式の必須ルール（管理通信・DNS・プローブ用の内部ポート等）を尊重しつつ、業務上不要な通信を遮断します。168.63.129.16とプラットフォーム管理に必要な通信を塞がないことが、運用を壊さないコツです。
環境を消せないときの罠
VNet統合環境を削除しようとしてprovisioningState: ScheduledForDeleteのまま消えない——これはよくあります。原因は関連VNetが残っていること。手順は、環境のinfrastructureSubnetIdからVNetを特定し、VNetを手動削除してから環境を削除します（詳細はトラブルシューティングガイド）。
設計チェックリスト
- ワークロードプロファイル環境を選ぶ（UDR/NAT/Private Endpointが要るなら必須）。サブネットは専用・最小/27。
- 公開要件に応じてExternal/Internalを決める（作成後に変更不可）。
- 公開接点はApplication Gateway＋WAFに一本化し、ACA環境はInternalに。
- 非公開化が要るならPrivate Endpoint（public network access=Disabled）またはFront Door＋Private Link。
- アウトバウンドはUDR＋Azure Firewallでロックダウン。固定egress IPはNAT Gatewayで。
- DNS：カスタムDNSは
168.63.129.16へ転送、login.microsoft.comとレジストリFQDNを許可。 - サブネットにNSGで多層化（プラットフォーム必須通信は塞がない）。
まとめ
ACAのネットワークは環境＝VNet＝セキュリティ境界という構造で、本番品質は「最初の設計」で決まります（タイプは後から変えられない）。エンタープライズの定石は——ワークロードプロファイル環境＋専用サブネットを土台に、Application Gateway(WAF)を前段、Internal＋Private Endpointで非公開化、UDR＋Firewallでegressロックダウン。AWSで多層防御を設計してきた発想が、そのままAzureの語彙に移植できます。
VNet統合・WAF・Private Endpoint・egress制御を含むエンタープライズ要件の設計から構築まで、ご相談はお問い合わせへ。本番運用全体は Azure Container Apps 本番運用ガイド をどうぞ。