Azure Container Appsをプライベートエンドポイントで公開している環境のインターネット送信設計とNVA経由ルーティング解説

Azure Container Apps をプライベート エンドポイント経由で公開していると、「この構成のままインターネット送信はどう設計すべきか？」という疑問がよく生まれます。本記事では、プライベート エンドポイント・VNet 統合・UDR・NVA の役割を整理しながら、実運用で使えるアウトバウンド設計パターンと具体的な構成例を詳しく解説します。

コンテナー アプリをプライベート エンドポイント公開したときの「インターネット送信」問題とは

Azure Container Apps（以下、コンテナー アプリ）を企業ネットワークに組み込む際、多くの環境で Private Endpoint（プライベート エンドポイント, PE） を使ったプライベート公開が採用されます。アプリの入口はインターネットから切り離しつつ、オンプレミスやハブ VNet 経由でのみアクセスさせる、というよくあるパターンです。

一方でアプリの中身（コンテナー）からは、次のような要件で インターネット宛てアウトバウンド通信 が必要になることが少なくありません。

• 外部の SaaS API（例：決済サービス、通知サービス）へのアクセス
• OS / ミドルウェアの更新サイト、パッケージリポジトリへのアクセス
• 社外サービスの Webhook 宛て通知

ここでよく出てくる誤解が、次のような設計です。

• コンテナー アプリは PE 経由で VNet に出ている
• だから「PE を作ったサブネット」に UDR の既定ルート 0.0.0.0/0 → 192.168.10.5（ILB） を当てれば、インターネット送信もそこで制御できるのでは？

残念ながら、この考え方は ネットワークの実際の動きと一致していません。結果として、

• コンテナー アプリからインターネットへ出られない
• NVA のログにトラフィックが全く乗ってこない
• 「PE 側の UDR をいじっても何も変わらない」

といった状況に陥りがちです。ここをきちんと理解するには、プライベート エンドポイントの役割 と コンテナー アプリ環境の VNet 統合 を分けて考える必要があります。

結論：インターネット送信は「できる」が、プライベート エンドポイント経由ではない

最初に結論を整理しておきます。

• コンテナー アプリからのインターネット送信は実現可能
• ただしその経路は プライベート エンドポイント（PE）ではない
• アウトバウンドは VNet に統合されたコンテナー アプリ環境のサブネット（以下、環境サブネット）から出ていく
• 経路制御は 環境サブネット に関連付けた UDR ＋ NVA（または NAT Gateway / Azure Firewall） で行う

整理すると、次のような役割分担になります。

要素	主な役割	インターネット送信への影響
プライベート エンドポイント（PE）	Azure PaaS への プライベート到達性（入口） を提供	主に インバウンド のみ。汎用アウトバウンド経路としては使えない
環境サブネット（コンテナー アプリ環境）	コンテナー アプリの実体（Pod/コンテナー）が属するネットワーク	ここに紐づく UDR / NSG がアウトバウンド経路・制御を決定
NVA（Palo Alto など）	ファイアウォール / セキュリティ検査 / NAT	UDR でトラフィックを集約し、SNAT → インターネット送信を実現
NAT Gateway	シンプルなアウトバウンド NAT（固定グローバル IP）	検査は行わないが、簡単にインターネット送信を実現できる
Azure Firewall	L3〜L7 レベルのセキュリティ制御、ログ一元管理	NVA の代替として、UDR で集約したトラフィックをインスペクション可能

つまり、PE はあくまで「入口専用のドア」 であり、アウトバウンドの経路を変えるスイッチではありません。インターネット送信をコントロールしたければ、コンテナー アプリ環境が存在するサブネット側で経路とセキュリティを設計する必要があります。

前提構成の整理：どこからどこへ流したいのか

本文で扱う構成を分かりやすくするため、典型的な例を整理しておきます。

• コンテナー アプリは Managed Environment を用いて構築
• Managed Environment は VNet の 環境サブネット に統合されている（例：10.10.0.0/24）
• アプリ公開用に、別サブネット（例：10.10.1.0/24）に プライベート エンドポイント を作成
• ハブ側には NVA（Palo Alto × 2 台）＋内部ロード バランサー（ILB）
• ILB のフロントエンド IP は例として 192.168.10.5

ここで「PE を作成したサブネット」側に、次のようなルート テーブルを関連付けてしまうケースがあります。

宛先: 0.0.0.0/0
次ホップ種別: 仮想アプライアンス
次ホップ: 192.168.10.5（ILB）

しかし、コンテナー アプリから外に出るトラフィックは、この PE サブネットを通りません。PE は「クライアントがコンテナー アプリへ入ってくるための入口」であって、「コンテナー アプリが出ていく出口」ではないためです。

正しい設計：環境サブネットに UDR を当てて NVA へ集約する

では、どう設計すればよいのでしょうか。ここからは、実際に使える構成パターンとして、「環境サブネット → ILB → NVA → インターネット」 の流れを具体的に解説します。

環境の VNet 統合を確認する

最初のポイントは、コンテナー アプリ環境がどのサブネットに統合されているかを正確に把握することです。Azure ポータルや CLI で、Managed Environment の設定を確認します。

• ポータルの場合：コンテナー アプリ環境 > ネットワーク > 仮想ネットワーク
• CLI の例：
  az containerapp env show \ --name <env-name> \ --resource-group <rg-name> \ --query "properties.vnetConfiguration"

ここで表示される サブネット ID が、以降の UDR / NSG を適用する「環境サブネット」です。PE を作成したサブネットとは別物 であることに注意してください。

ルート テーブル（UDR）の関連付け先を修正する

次に、インターネット宛てトラフィックを NVA に集約するため、環境サブネット に対してルート テーブルを関連付けます。構成イメージは以下のようになります。

サブネット	主な用途	関連付ける UDR
環境サブネット	コンテナー アプリの実行基盤	既定ルート 0.0.0.0/0 → ILB（192.168.10.5） を設定
PE サブネット	コンテナー アプリへの入口（Private Endpoint）	通常は既定ルート変更不要。UDR をつけてもコンテナー アプリの送信経路は変わらない

ルート テーブルの具体例は次の通りです。

ルート名: default-to-nva
宛先プレフィックス: 0.0.0.0/0
次ホップ種別: 仮想アプライアンス
次ホップ アドレス: 192.168.10.5（ILB フロントエンド）

このルート テーブルを 環境サブネットに関連付ける ことで、コンテナー アプリが外部へ出ようとする全トラフィックは、まず ILB に送られ、その後 NVA へと振り分けられます。

内部ロード バランサー（ILB）の設計ポイント

NVA を 2 台構成する場合、ILB は 高可用性と負荷分散 の要となります。設計時に押さえておきたいポイントは次の通りです。

• フロントエンド IP：例では 192.168.10.5。NVA と同じ VNet、もしくはルーティング可能なアドレス空間であること。
• バックエンド プール：NVA 2 台の NIC を登録。
• 負荷分散ルール：
  • HA ポート を有効化することで、全ポートをまるごと NVA に転送可能。
  • プロトコルは TCP/UDP 両方をカバー。
• プローブ：
  • NVA 側で応答可能なヘルスチェック用ポートを決める（例：TCP 8081）。
  • ILB のプローブは、そのポートに対して実施。

ここでよくあるトラブルが、プローブが失敗しているのに気付かない パターンです。プローブが通っていないと、ILB は NVA を「不健全」とみなし、トラフィックを流しません。結果として、UDR をいくら設定しても NVA にトラフィックが届かない、という状況になります。

NVA（Palo Alto など）の設定のポイント

NVA 側では、以下のような設定が必要です。

• 既定ルート（0.0.0.0/0） をインターネット側へ向ける（例：ISP ルータ、Azure のインターネットへの出口）。
• SNAT（NAT）設定：
  • 内部（環境サブネット）からのトラフィックを、NVA 側のパブリック IP などに変換。
  • 戻り経路を NVA に固定できるため、非対称ルーティングを防ぎやすい。
• セキュリティ ポリシー：
  • 送信元：環境サブネット（例：10.10.0.0/24）
  • 宛先：インターネット（任意 / 特定の FQDN / IP レンジなど）
  • アプリケーション / サービス：HTTPS、特定ポートのみ、など運用方針に合わせる

特に重要なのが SNAT の有無 です。SNAT を行わずに内部アドレスのままインターネットへ出そうとすると、戻りのパケットが別経路を通ってしまい、非対称ルーティング による通信失敗を招きがちです。コンテナー アプリのようなマネージドサービスでは内部の経路制御を細かくいじれないため、NVA で SNAT を有効にする 方が設計として安全です。

NSG / Firewall / UDR の整合性をチェックする

ネットワークトラブルの大半は「どこかでブロックされている」ことが原因です。次の観点で整合性を確認しましょう。

• 環境サブネットの NSG：
  • 送信先が ILB（192.168.10.5）のトラフィックを許可しているか。
  • 必要に応じて、NVA からの戻りトラフィックも許可しているか。
• 上流のファイアウォール / セキュリティ製品：
  • インターネット宛てのトラフィックが許可されているか。
  • URL / アプリケーション制御で意図せずブロックされていないか。
• UDR の競合：
  • 環境サブネットに複数の UDR を適用していないか。
  • より具体的なプレフィックス（例：特定 SaaS のサービスタグ）に別経路を指定していないか。

DNS の設計と確認

インターネット送信では、DNS が意外な落とし穴 になります。VNet でカスタム DNS を使っている場合、次の点をチェックします。

• コンテナー アプリが参照する DNS サーバーが、外部ドメインも正しく解決できるか。
• DNS サーバー自体が NVA 経由でインターネットに出られるか（フォワーダーの疎通）。
• DNS トラフィック（UDP/TCP 53）が NSG や NVA でブロックされていないか。

「curl は IP 指定だと通るのに、FQDN だと失敗する」という場合、ほぼ DNS 設定が原因です。コンテナー アプリ内から nslookup や dig を使い、解決できる／できないドメインを切り分けるとトラブルシュートしやすくなります。

動作確認：コンテナー アプリから実際に疎通テストを行う

構成ができたら、必ずコンテナー アプリから実機テストを行います。代表的な確認方法は次の通りです。

• シンプルな HTTP/HTTPS アクセス curl https://example.com curl https://www.google.com
• 特定の SaaS API へのアクセス（401/403 OK、タイムアウト NG などで切り分け）
• NVA 側のセッション、NAT テーブル、ポリシーログを確認し、
  • 送信元アドレスが環境サブネットのアドレスになっているか
  • SNAT が実施されているか
  • セキュリティポリシーで許可されているか

ここまで確認して初めて、「コンテナー アプリ → 環境サブネット → ILB → NVA → インターネット」の経路設計が正しく機能している、と言えます。

プライベート エンドポイントのサブネットに UDR を当ててもアウトバウンドが流れない理由

ここまで読むと、「そもそもなぜ PE サブネット側の UDR ではダメなのか？」という疑問がよりクリアになってきます。改めて整理すると、次のようになります。

観点	プライベート エンドポイント（PE）	環境サブネット（VNet 統合）
主な用途	PaaS へのプライベートな「入口」を作る	アプリやサービスの実体が属するネットワーク
トラフィックの方向	クライアント → PaaS（インバウンド中心）	アプリ → 各種宛先（アウトバウンド含む双方向）
UDR の影響範囲	PE を 送信元 とするトラフィックの経路	コンテナー アプリなど、サブネット内リソースのトラフィック全体
コンテナー アプリのアウトバウンド	そもそもここを経由しない	このサブネットの UDR で経路が決まる

イメージとしては、

• PE は「お客様入口」
• 環境サブネットは「厨房」

のような関係です。厨房から仕入れ先（インターネット）に電話したいときに、お客様入口にあるインターホンの配線をいじっても仕方がない、というイメージを持つと理解しやすくなります。

よくある落とし穴とトラブルシュートのポイント

パターン1：PE サブネットにしか UDR を紐づけていない

もっとも典型的な誤りがこれです。症状としては次のようなものが多く見られます。

• PE を経由するクライアントからのアクセスは問題なく動く
• しかしコンテナー アプリから外部へのアクセスはタイムアウトする
• NVA のログにはコンテナー アプリ由来のセッションが全く現れない

この場合は落ち着いて、環境サブネットに UDR が設定されているか を確認しましょう。もし関連付けが PE サブネットだけであれば、それを環境サブネットに付け替えるだけで解決することがあります。

パターン2：NAT（SNAT）未設定による非対称ルーティング

NVA 側で SNAT を設定していない場合、次のような現象が起きることがあります。

• 外向きパケットは NVA を経由して出ていく
• しかし戻りパケットは、別の経路（例えば Azure の既定のインターネット出口）から返ってくる
• 結果として、コンテナー アプリからは返信が見えず、タイムアウトする

クラウド環境ではルーティングの自由度が高い分、戻り経路も含めて対称に設計 することが重要です。NVA での SNAT を基本とし、すべてのインターネット戻り通信が必ず NVA を通るように設計することで、トラブルを大幅に減らせます。

パターン3：ILB のプローブ／HA ポート設定不備

ILB を経由する設計では、プローブとルールの設定不備もよくある原因です。

• ヘルスプローブのポートに NVA がリッスンしていない
• HA ポートではなく特定ポートのみを許可してしまい、想定外のポートが落ちる
• バックエンド プールに 2 台目の NVA が追加されていない

これらは ILB の「バックエンド健全性」メトリックや、Azure Monitor のログを使って確認できます。「UDR までは正しいのに、NVA に届かない」という場合は ILB の設定を重点的に見直すと良いでしょう。

パターン4：DNS 関連の問題

インターネット送信のトラブルシュートでは、DNS を切り分けると効率が上がります。

• IP 直接指定では疎通するが、FQDN では失敗 → DNS 設定を疑う
• 特定ドメインだけ解決できない → カスタム DNS サーバーのフォワーダー設定や ACL を確認
• DNS サーバー自身がインターネットに出られない → NVA 側のポリシー漏れ・UDR 競合を確認

DNS はトラフィック量が少ない割に影響範囲が広いため、まず最初に切り分けるべきポイント として位置づけておくと良いでしょう。

代替案：NAT ゲートウェイや Azure Firewall を使ったシンプルな設計

ここまで NVA（Palo Alto など）を前提にした構成を説明してきましたが、要件によっては NAT ゲートウェイ や Azure Firewall を使った設計の方がシンプルになる場合もあります。

NAT ゲートウェイ：検査不要なシンプル egress 固定

「インターネット宛ての通信は特に詳細な検査をしないが、固定の送信元グローバル IP は欲しい」という場合には、NAT ゲートウェイ が有力な選択肢です。

• 環境サブネットに NAT ゲートウェイを関連付けるだけで、シンプルにインターネット送信を実現
• 送信元 IP を 1 つまたは少数のグローバル IP に固定できる
• UDR や NVA を組み合わせた複雑な経路制御が不要

ただし、L7 の詳細なセキュリティ検査やアプリケーション制御は行えないため、セキュリティ要件が厳しい環境には向きません。用途が限定されている場合や、検査はオンプレミス側に任せる場合などに適した構成です。

Azure Firewall：マネージドなセキュリティ ハブとして利用

より高度なセキュリティ制御が必要だが、NVA の運用は避けたい場合には、Azure Firewall を採用する設計も一般的です。

• UDR で環境サブネットのトラフィックを Azure Firewall に集約
• アプリケーション ルールで、FQDN ベースの許可 / 拒否を定義
• Threat Intelligence / IDPS などの高度なセキュリティ機能を活用
• ログを Azure Monitor / SIEM に集約しやすい

運用コストや機能要件を加味して、NVA・NAT ゲートウェイ・Azure Firewall を組み合わせると、より柔軟かつ拡張性の高いネットワーク設計が可能になります。

方式	特徴	向いているケース
NVA（Palo Alto など）	既存運用の延長で高度なセキュリティ制御が可能	オンプレと同一ポリシーで統一したい、既存ノウハウを活かしたい場合
NAT ゲートウェイ	シンプルで安定したアウトバウンド NAT、構成が容易	検査不要で、ただ egress IP を固定したいだけの場合
Azure Firewall	マネージドな L3〜L7 セキュリティ、ログ統合が容易	クラウドネイティブなセキュリティハブを構築したい場合

実装ステップ例：既存構成を「正しい」アウトバウンド設計にリファクタリングする

最後に、すでに「PE サブネットに UDR を当ててしまっている」環境を、今回解説した正しい構成に移行する際のステップ例を示します。

1. 現状構成の棚卸し
   • 環境サブネット、PE サブネット、それぞれのアドレス範囲と UDR を確認
   • ILB のフロントエンド IP、バックエンド、ルール、プローブ設定を確認
   • NVA のルーティング、SNAT、セキュリティポリシーを確認
2. 環境サブネットの特定
   • コンテナー アプリ環境の VNet 統合設定から、対象サブネットを特定
   • そのサブネットに既に UDR が紐づいているか確認
3. ルート テーブルの設計・作成
   • 既定ルート 0.0.0.0/0 → ILB フロントエンド を持つルート テーブルを作成
   • 必要に応じて、特定のプレフィックス（オンプレミスなど）向けルートも追加
4. 環境サブネットへの UDR 関連付け
   • 既存の UDR がある場合は影響範囲を事前に評価
   • メンテナンス時間帯に切り替えを行うのが安全
5. テスト用コンテナー アプリで疎通確認
   • 簡単なテストアプリ（curl / ping ツール入りコンテナー）をデプロイ
   • インターネット宛ての疎通、DNS 名前解決、NVA ログを確認
6. 本番アプリへの反映と監視
   • 本番環境のコンテナー アプリから同様のテストを実施
   • Application Insights、NVA ログ、NSG フローログなどでエラー有無をモニタリング

このように、「環境サブネット側に責任を寄せる」 形でアウトバウンド設計を見直すことで、構成の意図が明確になり、トラブルシュートもしやすくなります。

まとめ：PE は入口、インターネット送信は環境サブネットで設計する

この記事では、Azure Container Apps をプライベート エンドポイントで公開している環境で、コンテナー アプリからインターネット送信を行う設計について解説しました。最後に重要なポイントを整理します。

• コンテナー アプリからのインターネット送信は可能 だが、プライベート エンドポイントはアウトバウンド経路にならない
• アウトバウンド制御は、VNet 統合されたコンテナー アプリ環境のサブネット に対する UDR / NSG / NVA（または NAT Gateway / Azure Firewall） で行う
• 「PE のサブネットに UDR を当てても何も変わらない」のは、そもそもコンテナー アプリの送信トラフィックが PE を経由しないため
• ILB の HA ポート・プローブ、NVA の SNAT・セキュリティポリシー、DNS の設定が、安定したインターネット送信には不可欠
• 要件に応じて、NVA だけでなく NAT ゲートウェイや Azure Firewall を組み合わせることで、よりシンプルかつ安全な設計も可能
• 最終的には、curl などの実機テストとログ確認 によって、設計どおりの経路でトラフィックが流れているかを検証することが重要

プライベート エンドポイントは「入口」、環境サブネットは「アプリの居場所」、NVA や NAT ゲートウェイは「出口」として役割をはっきり分けて設計することで、Azure Container Apps のネットワーク構成はぐっとわかりやすく、運用しやすくなります。これからコンテナー アプリの本番導入やネットワーク強化を検討している方は、ぜひ本記事の内容を自社環境に当てはめて見直してみてください。