Azure Container Apps のネットワーク設計を見直しているなら、2026年4月24日の「Networking in Azure Container Apps environment」更新でまず押さえるべき結論はシンプルです。今回の更新は新機能追加ではなく、HTTP バージョン表記を HTTP1.1 / HTTP2 から HTTP/1.1 / HTTP/2 へ正すドキュメント修正が中心です。ただし、Azure Container Apps 環境のネットワーク設計では、VNet、Ingress、Private Endpoint、NAT Gateway、UDR の選択を作成前に決める必要があり、後から簡単にやり直せない項目が多いため、実務上は「設計確認のタイミング」として重要です。(GitHub)
この記事では、Microsoft公式ソースで扱われた Azure Container Apps のネットワーク情報をもとに、IT 管理者、プロダクトオーナー、Microsoft エコシステム利用者が確認すべき更新ポイントと、既存環境・新規構築での判断基準を整理します。
Azureの最新動向: Networking in Azure Container Apps environmentで何が変わったか
2026年4月24日の更新は、GitHub上の MicrosoftDocs/azure-docs リポジトリでは networking.md に対する変更として確認できます。変更内容は、HTTP エッジプロキシの説明にある HTTP バージョン表記を HTTP/1.1 と HTTP/2 に修正するものです。つまり、Azure Container Apps のネットワーク機能そのものが大きく変わったわけではありません。(GitHub)
ただし、この修正は単なる表記揺れでは済ませにくいポイントです。Azure Container Apps では、エッジ HTTP プロキシが TLS を終端し、リクエストを各アプリケーションへルーティングします。また、下流接続では HTTP/1.1 と HTTP/2 がサポートされ、上流接続は ingress オブジェクトの transport プロパティで定義されます。プロトコルの理解が曖昧だと、gRPC、WebSocket、HTTP/2 前提のAPI、リバースプロキシ配下のヘッダー処理で設定ミスが起きやすくなります。(GitHub)
| 確認項目 | 今回の更新で分かること | 実務上の影響 |
|---|---|---|
| HTTP表記 | HTTP/1.1、HTTP/2 という標準的な表記に修正 | 設定値の変更ではなく、仕様理解の明確化 |
| TLS終端 | Azure Container Apps のエッジ HTTP プロキシが TLS を終端 | アプリ側でクライアント接続情報を見る場合はヘッダー確認が必要 |
transport | 上流接続は ingress の transport で定義 | HTTP/2 や TCP を使うアプリでは明示設定を検討 |
| 運用対応 | 既存環境の即時変更は基本的に不要 | ネットワーク設計レビューやIaC確認の機会にする |
Azure Container Appsのネットワークは「環境」単位で考える
Azure Container Apps は、個々のコンテナーアプリだけで完結するサービスではありません。アプリは Azure Container Apps environment の中で動作し、その環境が仮想ネットワーク上の境界として機能します。複数のコンテナーアプリを同じ環境に置くと、同じ仮想ネットワークやログの宛先を共有します。(GitHub)
ここで重要なのは、ネットワーク設計の主語が「アプリ」ではなく「環境」になることです。たとえば、同じマイクロサービス群を1つの環境にまとめれば通信やログ管理はシンプルになります。一方で、開発・本番を完全に分離したい場合、あるいはチームやプロダクトごとにネットワーク境界を分けたい場合は、複数環境に分ける判断が必要です。
プロダクトオーナーにとっては、これは単なるインフラ設定ではありません。環境の分け方は、リリース速度、障害時の影響範囲、セキュリティレビュー、コスト配賦に直結します。後から分離しようとすると、DNS、Private Endpoint、Ingress、CI/CD、監視設定まで再設計が必要になることがあります。
環境タイプの選び方：Workload profilesを前提に検討する
Azure Container Apps には、Workload profiles 環境と Consumption only 環境があります。公式ドキュメントでは Workload profiles が既定の環境タイプとされ、Consumption only はレガシー扱いです。ネットワーク機能の観点では、この差が大きくなります。(GitHub)
| 環境タイプ | 対応プラン | 主なネットワーク機能 | 最小サブネットサイズ | 向いている用途 |
|---|---|---|---|---|
| Workload profiles | Consumption、Dedicated | UDR、NAT Gateway 経由のエグレス、環境への Private Endpoint 作成をサポート | /27 | 本番環境、閉域接続、固定送信IP、企業ネットワーク統制 |
| Consumption only | Consumption のみ | UDR、NAT Gateway、リモートゲートウェイ経由のピアリング、カスタムエグレスをサポートしない | /23 | 既存の軽量ワークロード、ネットワーク制御が少ない環境 |
新規構築では、特別な理由がない限り Workload profiles 環境を前提に設計するのが現実的です。特に、次のような要件がある場合は Consumption only を選ぶと後で詰まりやすくなります。
- SaaS や外部APIに対して固定送信IPを使いたい
- Azure Firewall で送信通信を監査・制御したい
- Storage Account、SQL、Key Vault などへ Private Endpoint 経由で接続したい
- NSG や UDR を含めて企業ネットワークポリシーに合わせたい
- 将来的に Dedicated workload profile を使う可能性がある
VNet統合は作成前に決める：後から差し替えにくい
Azure Container Apps 環境は、既定では Azure 側で統合されたネットワークに作成されます。この場合、インターネットから到達可能なエンドポイントとの通信が中心です。一方、既存の VNet を指定して環境を作ると、NSG、Application Gateway、Azure Firewall、送信通信制御、Private Endpoint 配下のリソースへのアクセスなどを使えるようになります。(GitHub)
注意したいのは、環境を作成した後に「既定の Azure ネットワーク」から「既存 VNet」へネットワークタイプを変更できない点です。また、既存 VNet を使う場合は、Container Apps 環境専用のサブネットを用意する必要があり、そのサブネットは他サービスと共有できません。(GitHub)
サブネット設計では、最小サイズだけを見て決めると失敗します。Workload profiles 環境では /27 が最小ですが、Azure Container Apps はインフラ用IPを予約し、スケールアウトやゼロダウンタイムデプロイ時にも追加のアドレス余力が必要になります。公式ドキュメントでは、単一リビジョンモードでリビジョン変更を行う際、必要なアドレス空間が一時的に倍になることも示されています。(Microsoft Learn)
作成前に決めるべきネットワーク項目
| 判断項目 | 確認すること | 失敗しやすいポイント |
|---|---|---|
| VNetを使うか | NSG、Firewall、Private Endpoint、社内接続が必要か | 作成後にネットワークタイプを変更できない |
| 環境をExternalにするかInternalにするか | インターネット公開が必要か、VNet内限定か | Internal環境は後からインターネット公開へ変更できない |
| サブネットサイズ | 最大レプリカ数、Dedicatedノード数、リビジョン更新時の余力 | /27 で足りると思い込み、スケール時に不足する |
| 送信IP制御 | 外部SaaSのIP許可リストが必要か | NAT GatewayやAzure Firewallを後回しにする |
| DNS | Private Endpoint の名前解決をどこで行うか | Private Endpointは作ったがFQDNがプライベートIPに解決されない |
Public Network AccessとInternal環境を混同しない
Azure Container Apps のネットワークで混乱しやすいのが、環境レベルのアクセシビリティと、アプリレベルの ingress 設定です。
環境レベルでは、External と Internal があります。External 環境はパブリック向けの仮想IPを持ち、Public Network Access を Enabled または Disabled にできます。Internal 環境はパブリックエンドポイントを持たず、Public Network Access は Disabled のみです。Internal 環境を作成した後に、インターネットからのトラフィックを受け入れる設定へ変更することはできません。(GitHub)
一方、アプリレベルの ingress では、コンテナーアプリを外部公開するか、同じ Container Apps 環境内に限定するかを設定します。Ingress はアプリ全体に適用され、設定変更は全リビジョンに同時適用されますが、新しいリビジョンは生成しません。(Microsoft Learn)
| 要件 | 推奨される考え方 | 補足 |
|---|---|---|
| WebアプリやAPIをインターネット公開したい | External環境 + 外部Ingress | 必要に応じてFront Door、Application Gateway、IP制限を組み合わせる |
| 社内・VNet内だけで使いたい | Internal環境を検討 | 作成後に公開型へ切り替えられない点に注意 |
| Private Endpoint経由だけでアクセスしたい | Public Network AccessをDisabledにする | 環境へのPrivate Endpoint作成には Public Network Access の無効化が必要 |
| マイクロサービス間通信を環境内に閉じたい | アプリのIngressを内部向けにする | 環境レベルのExternal/Internalとは別に確認する |
Private Endpointを使うならDNSまで設計する
Private Endpoint は、Azure Container Apps をパブリックインターネットに公開せず、VNet内のプライベートIP経由で安全にアクセスするための仕組みです。公式手順でも、Public Network Access を無効化し、Private Endpoint を有効にする流れが示されています。(Microsoft Learn)
実務で多い失敗は、Private Endpoint の作成だけで満足してしまい、Private DNS の確認をしないことです。公式CLI例では、環境の既定ドメインを取得し、privatelink.${LOCATION}.azurecontainerapps.io の Private DNS Zone を作成する流れが示されています。グローバル展開ではリージョンごとに値が変わるため、IaCではリージョン名をハードコードせず、変数化して管理するのが安全です。(Microsoft Learn)
確認すべきポイントは次の3つです。
- クライアントがいるVNet、または接続元ネットワークからFQDNがプライベートIPに解決されるか
- Private DNS Zone が必要なVNetにリンクされているか
- Public Network Access が意図せず
Enabledのままになっていないか
Private Endpoint には追加料金が発生するため、セキュリティ要件だけでなく、アクセス元、接続頻度、環境数、リージョン数も含めて設計する必要があります。(Microsoft Learn)
送信通信は「Outbound IPが変わる前提」で設計する
Azure Container Apps の送信通信では、アウトバウンドのパブリックIPが時間とともに変わる可能性があります。外部SaaSや取引先APIでIP許可リストを使う場合、既定の送信IPに依存する設計は避けるべきです。NAT Gateway やその他のプロキシを使った送信制御は、Workload profiles 環境でのみサポートされます。(GitHub)
Workload profiles 環境でサブネットに NAT Gateway を構成すると、環境のアウトバウンド通信に静的なパブリックIPを使えます。より厳格に宛先制御や監査ログを求める場合は、UDRでAzure Firewallへ送信通信を集約する構成も検討対象になります。(Microsoft Learn)
| 要件 | 検討する構成 | 判断基準 |
|---|---|---|
| 外部APIに固定IPで接続したい | NAT Gateway | 宛先制御よりも固定送信IPが主目的 |
| 送信先を厳密に制御したい | UDR + Azure Firewall | 監査、宛先制限、セキュリティ運用が必要 |
| Private Endpoint配下のAzureリソースへ接続したい | 既存VNet + Private Endpoint + Private DNS | 名前解決とサブネット設計が重要 |
| 小規模な検証環境 | 既定ネットワーク | 本番移行時に再作成が必要になる可能性を許容する |
Ingress設定ではHTTP/2、gRPC、TCPの要件を先に確認する
今回の4月更新で表記が明確になった HTTP/1.1 と HTTP/2 は、Ingress設計でも確認すべきポイントです。Azure Container Apps の HTTP ingress は TLS 終端、HTTP/1.1、HTTP/2、WebSocket、gRPC をサポートし、HTTPS エンドポイントは TLS 1.2 または 1.3 を使います。既定ではHTTPリクエストがHTTPSへリダイレクトされます。(Microsoft Learn)
Ingress の transport には、auto、http、http2、tcp などを設定できます。通常のWeb APIなら auto で十分な場合もありますが、gRPCやHTTP/2前提の通信、TCPベースの独自プロトコルを扱う場合は、アプリが待ち受ける targetPort と transport を明示的に確認してください。(Microsoft Learn)
また、外部TCP ingress は VNet を使う Container Apps 環境でのみサポートされます。追加TCPポートを外部公開する場合は、環境内でポート番号の一意性が必要です。メールテスト用のMaildev、Redis互換プロトコル、独自TCPサービスなどを扱う場合は、HTTPアプリと同じ感覚で公開しないよう注意が必要です。(Microsoft Learn)
ポータル操作・ログ確認で見落としやすい依存関係
Azure Container Apps では、各アプリにアプリケーションアクセス用のFQDNが生成されます。さらに、ログストリーミングサービスやコンソールアクセス用の別URLも生成されるため、企業のファイアウォールやプロキシ環境では https://azurecontainerapps.dev/ の許可が必要になる場合があります。(GitHub)
ネットワークを厳しく閉じた環境では、「アプリにはアクセスできるが、ポータル上のログストリームやコンソールが使えない」という状態が起きます。これはアプリの障害ではなく、管理・運用に必要なURLがブロックされている可能性があります。IT管理者は、本番環境だけでなく、運用端末・踏み台・SOC環境からの管理経路も許可リストに含めて確認してください。
既存環境を見直すためのチェック手順
既存の Azure Container Apps 環境では、まず環境のネットワーク設定を棚卸しします。Azure CLI を使う場合は、以下のように Public Network Access、既定ドメイン、静的IP、VNet構成を確認します。
az containerapp env show \
--resource-group <resource-group> \
--name <environment-name> \
--query "{publicNetworkAccess:properties.publicNetworkAccess, defaultDomain:properties.defaultDomain, staticIp:properties.staticIp, vnetConfiguration:properties.vnetConfiguration}" \
--output json次に、アプリ側の ingress 設定を確認します。
az containerapp show \
--resource-group <resource-group> \
--name <container-app-name> \
--query "{ingress:properties.configuration.ingress}" \
--output json確認後は、次のように対応を分けると判断しやすくなります。
| 見つかった状態 | リスク | 次のアクション |
|---|---|---|
| 既定ネットワークで本番運用している | NSG、UDR、Private Endpoint、送信制御を使いにくい | 要件次第でVNet統合環境への再構築を検討 |
| Consumption only環境で送信制御が必要 | NAT GatewayやUDRを使えない | Workload profiles環境への移行計画を作る |
| Public Network Accessが有効のまま | Private Endpoint前提の設計と矛盾する可能性 | アクセス元とDNSを確認して無効化を検討 |
| サブネットが最小サイズに近い | スケールやリビジョン更新時にIP不足の恐れ | レプリカ数、Dedicatedノード数、ゼロダウンタイム更新を再計算 |
| ポータルのログやコンソールが使えない | 管理系URLがプロキシで遮断されている可能性 | azurecontainerapps.dev の許可を確認 |
プロダクトオーナーが押さえるべき判断基準
Azure Container Apps のネットワーク設計は、IT部門だけで完結する話ではありません。VNet統合やPrivate Endpointを選ぶと、管理対象リソースや追加コストが発生します。公式ドキュメントでも、独自ネットワークに内部または外部環境をデプロイすると、Azure Container Apps プラットフォームが管理するインフラコンポーネント用のリソースグループが作成され、標準の課金に加えて標準パブリックIP、ロードバランサー、管理操作のデータ処理コストなどが発生することが示されています。(Microsoft Learn)
そのため、プロダクトオーナーは次の基準で優先度を決めるとよいでしょう。
- 顧客データや社内データを扱うなら、Private EndpointとVNet統合を早期に検討する
- 外部SaaS連携でIP許可リストが必要なら、NAT GatewayまたはFirewall構成を見積もる
- グローバル展開するなら、リージョンごとのDNS、送信IP、FirewallルールをIaCで標準化する
- 検証環境では簡単な構成を選んでも、本番移行時に再作成が必要になる可能性を計画に入れる
- セキュリティ要件が未確定なら、後戻りしにくいInternal環境やサブネットサイズだけは慎重に決める
2026年4月更新を受けて、今やるべきこと
今回の「Networking in Azure Container Apps environment」の更新は、機能追加というよりもプロトコル表記の明確化です。しかし、HTTP/1.1、HTTP/2、Ingress、Edge proxy、VNet、Private Endpoint、NAT Gateway の理解が曖昧なまま本番環境を作ると、公開範囲、送信元IP、名前解決、スケール時のIP不足で運用トラブルにつながります。
新規構築では、まず Workload profiles 環境を前提に、VNet統合、External/Internal、Public Network Access、サブネットサイズ、送信制御を決めてから環境を作成してください。既存環境では、Public Network Access、VNet構成、Ingressの transport、Private DNS、送信IP制御を棚卸しし、変更できない項目が要件に合っていない場合は、環境の再作成や段階的な移行を計画するのが現実的です。
コメント