# Azure Container Apps ネットワーク設計ガイド：VNet統合・内部環境・Private Endpoint・WAF・egressロックダウン

> Azure Container Appsのネットワークを本番品質で設計する実装ガイド。ワークロードプロファイル環境の専用サブネット（/27）、内部環境とExternal/Internal、Private Endpointによる非公開化、Application Gateway＋WAFの前段、UDR＋Azure Firewallによるegressロックダウン、DNS（168.63.129.16）までを、Microsoft Learn公式に忠実に解説します。

- 公開日: 2026-06-26
- 著者: 友田 陽大
- タグ: Azure, Container Apps, ネットワーク, セキュリティ, VNet, WAF, インフラ, アーキテクチャ設計
- URL: https://tomodahinata.com/blog/azure-container-apps-networking-vnet-private-endpoint-waf-egress-guide

## 要点

- 本番ネットワークはワークロードプロファイル環境＋専用サブネット（最小/27）が既定。UDR・NAT Gateway・Private Endpointに対応する。Consumption only（レガシー）は/23でUDR/NAT非対応
- アクセシビリティはEnvironment単位でExternal（公開IP）かInternal（内部LB IPのみ）かを選ぶ。Internal環境はpublic network accessが常にDisabledで、Private Endpoint運用の土台になる
- 多層防御の定石：内部環境＋Application Gateway(WAF)を前段に＋UDRで全egressをAzure Firewall経由に。ネットワークタイプは作成後に変更できないため最初に決める
- サブネットは環境専用（他サービスと共有不可）。カスタムDNSは未解決クエリを168.63.129.16へ転送し、NSG/ファイアウォールでこのアドレスとlogin.microsoft.comをブロックしない
- 外部TCP IngressはVNet必須。アウトバウンドIPは変動しうるため、固定egressが要るならNAT Gateway（ワークロードプロファイル環境のみ）を使う

---

エンタープライズ案件で必ず問われるのが**ネットワークとセキュリティ**です。「外部に出さず、VNet内に閉じたい」「WAFを前段に置きたい」「アウトバウンドをFirewallで制御したい」——これらに答えられないと、本番には載りません。

この記事は、[Microsoft Learnのネットワークドキュメント](https://learn.microsoft.com/en-us/azure/container-apps/networking)に忠実に、Azure Container Apps（ACA）の**本番ネットワーク設計**を解説します。私はAWSで[API Gateway→NLB→ALB→ECSの多層構成](/blog/aws-ecs-fargate-networking-alb-service-connect-vpc-guide)を本番運用し、[WAFの多層防御](/blog/waf-defense-in-depth-aws-waf-cloud-armor-owasp-guide)を設計してきました。「信頼境界をネットワークで作る」発想はAzureでも同型です。ACA全体は [Azure Container Apps 本番運用ガイド](/blog/azure-container-apps-production-guide) を参照してください。

---

## 大前提：環境がVNetを持つ

> Azure Container Apps operates in the context of an environment, which runs its own virtual network.（— [Networking in an Azure Container Apps Environment](https://learn.microsoft.com/en-us/azure/container-apps/networking)）

ネットワークは**アプリ単位ではなく環境単位**です。同じ環境のアプリは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運用の自然な土台になります。

---

## 多層防御アーキテクチャ：本番の定石

公式が示す「ロックダウン」構成を、実務の形にまとめます。

```text
                        [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](https://learn.microsoft.com/en-us/azure/container-apps/networking)）

### ① 前段：Application Gateway ＋ WAF

公開接点を**Application Gateway（WAF付き）に一本化**し、ACA環境はInternalにして直接インターネットに晒さない。WAFでOWASP Top 10（SQLi・XSS等）を弾く。AWSでいう「ALB＋AWS WAF」をAzureで`Application Gateway＋WAF`に置き換えた形です（[WAF多層防御の設計思想](/blog/waf-defense-in-depth-aws-waf-cloud-armor-owasp-guide)）。

### ② 非公開化：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](https://learn.microsoft.com/en-us/azure/container-apps/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.16` to resolve requests.（— [troubleshooting](https://learn.microsoft.com/en-us/azure/container-apps/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を手動削除してから環境を削除します（詳細は[トラブルシューティングガイド](/blog/azure-container-apps-troubleshooting-revision-failed-exit-code-137-probes-guide)）。

---

## 設計チェックリスト

- [ ] **ワークロードプロファイル環境**を選ぶ（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制御を含むエンタープライズ要件の設計から構築まで、ご相談は[お問い合わせ](/contact)へ。本番運用全体は [Azure Container Apps 本番運用ガイド](/blog/azure-container-apps-production-guide) をどうぞ。