Azure Container Apps を仮想ネットワークに統合し、Azure Firewall でアウトバウンド通信を制御すると、公式ドキュメントに載っていない FQDN への通信が突然ブロックされて戸惑うことがあります。本記事では、acs-mirror.azureedge.net や management.azure.com、Service Bus などの通信が遮断される理由と、その対処方法・運用ベストプラクティスを詳しく解説します。
Azure Container Apps と Azure Firewall 連携で起きる「想定外ブロック」
Azure Container Apps（以下、Container Apps）はフルマネージドなコンテナ実行基盤ですが、その内部では Azure Kubernetes Service（AKS）をベースにしたインフラが動いています。
そのため、Container Apps 環境を仮想ネットワーク（VNet）に統合し、ユーザー定義ルート（UDR）でインターネット向きのトラフィックを Azure Firewall に迂回させると、次のような現象が発生することがあります。
- ドキュメントどおりに
AzureContainerRegistryや制御プレーン関連の FQDN に対する「許可」ルールを作成したにもかかわらず、デプロイやスケーリング、ログ収集時にエラーが出る - Azure Firewall のログを見ると、以下のような FQDN への通信がブロックされている
acs-mirror.azureedge.netmanagement.azure.com*.servicebus.windows.net（例:gsm1776064220eh.servicebus.windows.net）packages.aks.azure.com
- Container Apps のドキュメントに「必要な宛先」として書かれておらず、特に Service Bus は「そもそもどこから呼ばれているのか分からない」状態になる
結果として、
- 新しい revision がデプロイできない
- スケールアウト・スケールインが期待どおりに動かない
- ログやメトリックが欠落する
といった事象につながります。
なぜドキュメントに載っていない FQDN が必要になるのか
ポイントは、Container Apps が「AKS ベースのフルマネージドサービス」であるという点です。ユーザーが直接 AKS クラスターを意識することはありませんが、裏側では以下のようなコンポーネントが動いています。
- Kubernetes コントロールプレーンとそのエージェント
- Container Apps 向けの専用インフラコンポーネント
- ログ・メトリック・イベントを集約する内部メッセージング
- 制御プレーン API（ARM / Resource Provider）へのアクセス
このとき、AKS 共通のエンドポイントや、Container Apps の内部実装で利用されるエンドポイントに対しても通信が発生しますが、それらが Container Apps の「ファイアウォール設定ガイド」にすべて列挙されているとは限りません。
今回問題になっている FQDN は、概ね次のような用途で使われています。
| FQDN | 主な用途 | 誰が通信しているか |
|---|---|---|
acs-mirror.azureedge.net | コンテナ実行環境や関連コンポーネントのイメージ配布・キャッシュ | Container Apps の基盤インフラ |
management.azure.com | ARM / Resource Provider との制御プレーン通信 | Container Apps プラットフォーム、エージェント |
*.servicebus.windows.net | 内部メッセージング、イベント配信、ログ・テレメトリの収集 | Container Apps プラットフォームコンポーネント |
packages.aks.azure.com | Kubernetes / Container Apps 関連コンポーネントの取得・更新 | AKS ベースの制御プレーン・エージェント |
つまり、これらは「ユーザーアプリケーションが直接アクセスしている」というよりも、
- Container Apps を支えるインフラやエージェントが裏側で必要とする通信
- スケーリングやログ収集など、PaaS としての機能を実現するための制御系通信
と捉えるのが正確です。
Azure Firewall に追加すべきアウトバウンド許可ルール
上記の FQDN への通信がブロックされる場合、Azure Firewall のアプリケーション規則（Outbound）に、次のようなルールを追加することで解消できます。
推奨アプリケーション規則の一覧
| 優先度 | 宛先 FQDN / タグ | プロトコル / ポート | 用途 | 推奨アクション |
|---|---|---|---|---|
| 100 | acs-mirror.azureedge.net | HTTPS / 443 | コンテナイメージ・関連コンポーネントの取得 | 許可 |
| 110 | management.azure.com | HTTPS / 443 | ARM / 制御プレーン API へのアクセス | 許可 |
| 120 | *.servicebus.windows.net | HTTPS / 443、AMQP / 5671 など | 内部メッセージング・イベント・ログ収集 | ワイルドカードで許可 |
| 130 | packages.aks.azure.com | HTTPS / 443 | Kubernetes / ACA コンポーネントの取得 | 許可 |
ソースアドレスは、基本的には Container Apps 環境が属するサブネット（例: subnet-containerapps）を指定します。Container Apps Environment を VNet 統合している場合、その環境専用サブネットから Azure Firewall にルーティングされるためです。
FQDN タグの活用
Azure Firewall のアプリケーションルールでは、FQDN だけでなく「FQDN タグ」を使って宛先をグルーピングできます。AKS/Container Apps 関連では、例えば次のようなタグの利用を検討できます。
- AzureKubernetesService：AKS 制御プレーン関連のエンドポイントをまとめて許可する目的で利用
- その他、Container Registry や監視系のタグ：Container Apps の利用形態に応じて追加
すべてを FQDN 個別指定にすると管理コストが高くなり、Microsoft 側でエンドポイントが追加されたときに追随しづらくなります。可能な範囲で FQDN タグを併用し、どうしてもタグでカバーしきれない部分だけを個別 FQDN / ワイルドカードで補う構成が現実的です。
Service Bus への通信元はどこか ― 「怪しい通信」ではない理由
*.servicebus.windows.net へのアウトバウンド通信は、一見すると「アプリケーションが勝手に外部の Service Bus に接続しているのでは？」と疑いたくなりますが、実際には Container Apps プラットフォームや AKS の制御系コンポーネントが利用しているケースがほとんどです。
代表的な用途としては、
- Container Apps のスケーリングや状態管理のための内部イベントバス
- ログ・メトリック・テレメトリを集約するための中継ポイント
- プラットフォーム側のジョブ管理・キュー処理
といった「サービス内部のメッセージング基盤」としての利用が考えられます。
したがって、これらの通信を完全に遮断してしまうと、
- Container Apps がスケールしなくなる / 勝手に止まるように見える
- 診断ログが欠損し、トラブルシュートが困難になる
- マネージドルンタイムの更新や内部タスクが滞る
といった副作用が発生します。逆に言えば、*.servicebus.windows.net への通信は「プラットフォームが生きている証拠」であり、原則として適切に許可しておくべき通信です。
実際の Azure Firewall 設定イメージ
ここでは、Azure Portal または IaC（Bicep / ARM / Terraform など）で構成する場合をイメージしながら、ルールの考え方を整理します。
アプリケーションルール コレクションの例
| 項目 | 設定例 |
|---|---|
| コレクション名 | aca-outbound-required |
| 優先度 | 100 |
| アクション | Allow |
| ソース | Container Apps サブネット（例: 10.10.0.0/24） |
| 宛先 | FQDN / FQDN タグ（下記ルールを複数定義） |
上記コレクション内に、次のようなルールを作成します。
allow-aca-acs-mirror：acs-mirror.azureedge.netallow-aca-management：management.azure.comallow-aca-servicebus：*.servicebus.windows.netallow-aca-aks-packages：packages.aks.azure.comallow-aks-tag：FQDN タグAzureKubernetesServiceなど
アプリケーションルールの優先度は、「Container Apps 用に必要なもの」ほど数値を小さくしておくと、将来ルールが増えたときにも整理しやすくなります。
通信元を特定する具体的な手順
「本当に Container Apps から出ている通信なのか？」「どのアプリケーション / Pod が発信元なのか？」を確認したい場合は、次の手順で調査できます。
1. Azure Firewall 診断ログ（ApplicationRuleLog）の確認
まずは Azure Firewall の診断設定で、ログを Log Analytics ワークスペースなどに送信します。そのうえで、ApplicationRuleLog を確認することで、ブロックされた FQDN と送信元 IP を特定できます。
代表的な項目は次のとおりです。
| フィールド名 | 内容 |
|---|---|
srcIp_s | 送信元 IP アドレス（Container Apps サブネット内かを確認） |
dstIp_s | 宛先 IP アドレス |
fqdn_s | アクセス先 FQDN（例: gsm1776064220eh.servicebus.windows.net） |
action_s | Allow / Deny などの判定結果 |
rule_s | 該当した Azure Firewall のルール名（何にマッチしたか） |
送信元 IP が Container Apps 用サブネットに含まれていれば、ほぼ確実に Container Apps 環境から出ているトラフィックと判断できます。
2. Network Watcher での Connection Monitor / Packet Capture
より踏み込んで、「どの Pod / アプリケーションが通信しているか」まで知りたい場合は、Network Watcher の機能を併用します。
- Connection Monitor：特定の宛先（例:
*.servicebus.windows.net）への疎通状況をモニタリング - Packet Capture：Container Apps サブネットに紐付けてパケットキャプチャを行い、トラフィックの詳細を解析
キャプチャしたパケットを解析することで、Source Port やタイミングなどから「特定のアプリケーション実行直後に発生している通信」なのか、「Container Apps 環境が定期的に行っている通信」なのか、といった特徴を見極めることができます。
3. Container Apps 側のログとの突き合わせ
上記のネットワークログに加え、Container Apps 環境や各アプリケーションのログ（コンテナログ、プラットフォームログ）を確認し、時間軸で突き合わせると、より高精度に原因を特定できます。
- Container Apps のスケールアウト / 新規 revision デプロイのタイミングで Service Bus 通信が増えていないか
- ログ送信や診断情報の有効化・無効化に応じて、Service Bus 宛の通信が変化していないか
これらを総合すると、「特定のユーザーアプリケーションではなく、プラットフォームコンポーネントが通信している」ということが見えてくるはずです。
実トラフィックに基づくルール設計のすすめ
Container Apps に限らず、PaaS サービスを Azure Firewall 配下で利用する際には、「最初から完璧な最小権限ルール」を作ろうとすると高確率でハマります。実運用に耐えるルールを作るためには、次のようなステップを踏むのが現実的です。
ステップ 1：広めの許可ルールで一旦稼働させる
まずは、以下のような方針で「広めの許可ルール」を用意します。
- Container Apps サブネットからのインターネット向け HTTPS を、主な Azure サービス用 FQDN タグでまとめて許可
- 判明している FQDN（ドキュメントに記載のもの）はすべて許可
- ログを必ず有効化し、ApplicationRuleLog / NetworkRuleLog を保存
この状態で数日〜数週間ほど実運用に近い負荷をかけると、「実際にどの FQDN にどれくらいアクセスしているか」が見えてきます。
ステップ 2：ログから実際に利用している FQDN を抽出する
次に、Log Analytics などで集計を行い、Container Apps サブネットからの通信先 FQDN を一覧化します。
- 頻繁にアクセスされる Azure サービス関連の FQDN
- たまにしかアクセスされないものの、重要な制御系通信と思われる FQDN
- アプリケーション固有の外部 API ドメイン
これらをカテゴリー毎にグルーピングし、目的別にルールを整理します。
ステップ 3：最小構成のルールに絞り込む
抽出した FQDN / FQDN タグをもとに、徐々に許可範囲を絞り込んでいきます。
- Azure 共通・プラットフォーム用：FQDN タグやワイルドカードで包括的に許可
- Container Apps 固有：今回挙げたような
acs-mirror.azureedge.net、management.azure.com、*.servicebus.windows.net、packages.aks.azure.comなど - アプリケーション固有：外部 API・SaaS・自社サービスのドメイン
このとき、Container Apps の基盤が利用する FQDN は「プラットフォームを成立させるための必須通信」として扱い、アプリケーション固有の通信とは分けて管理すると整理しやすくなります。
ステップ 4：定期的にルールをレビューする
Azure の PaaS サービスは頻繁に機能拡張・改善が行われるため、必要な FQDN / エンドポイントも将来的に変化し得ます。少なくとも半年〜1 年に一度は、次のようなレビューを実施すると安心です。
- 最近ブロックされている FQDN に、Container Apps 関連と思しきものがないか
- 不要になったルール（古いドメインなど）が残っていないか
- 新しい Container Apps 機能（例：Dapr、ジョブ、マネージド ID 利用拡大など）で追加された通信がないか
運用を通じてルールセットを育てていくイメージで管理するのが、長期的にはもっともコストが低く、安定した構成になります。
よくあるハマりポイントとその回避策
DNS 解決の問題で「通信できないように見える」ケース
Azure Firewall 経由の構成では、DNS の扱いを誤ると「Firewall のルールを許可しているのに名前解決で失敗する」ということが起きがちです。
- Container Apps サブネットからの DNS クエリが、正しく Azure DNS / カスタム DNS に届いているか
- Azure Firewall を DNS プロキシとして利用している場合、DNS 用の Network ルールが正しく設定されているか
- FQDN ベースのアプリケーションルールを使う場合、Azure Firewall が名前解決できるようになっているか
これらを確認しないと、*.servicebus.windows.net を許可しているつもりでも、実際には IP アドレスに解決できず通信が失敗する、といった状況に陥ります。
Private Endpoint / Private Link と組み合わせたときの注意点
Container Apps 自体は現時点では完全な「閉域のみ」という構成が難しいケースもあり、どうしても一部はパブリックエンドポイント向きの通信が必要になります。その一方で、アプリケーションのバックエンド（Database、Storage、Key Vault など）は Private Endpoint / Private Link で閉じる、という構成が一般的です。
このとき、
- アプリケーション用の Private Endpoint 向けトラフィックは、Firewall 経由の UDR ではなく VNet 内ルーティングで完結させる
- Container Apps 基盤が必要とするパブリックエンドポイント向けトラフィックのみ、Firewall 経由にする
といったルート設計を行うことで、
- セキュリティを確保しつつ
- Container Apps の PaaS 機能も維持し
- 不要なレイテンシや単一障害点を避ける
というバランスが取りやすくなります。
まとめ：Container Apps × Azure Firewall では「プラットフォームの声」を聞く
Container Apps を Azure Firewall 配下で利用する場合、ドキュメントに載っている FQDN だけを許可しても、実際には動作に必要な通信がまだ残っていることがあります。本記事で取り上げたように、
acs-mirror.azureedge.netmanagement.azure.com*.servicebus.windows.netpackages.aks.azure.com
といったエンドポイントは、Container Apps の裏側で動く AKS / プラットフォームコンポーネントが利用しているため、「アプリケーションコードには見えないが、サービス運用には必須の通信」です。
これらを正しく許可するためには、
- Azure Firewall の診断ログで実トラフィックを観測する
- Network Watcher やコンテナログと組み合わせて、誰が何の目的で通信しているかを理解する
- 広めの許可 → ログから絞り込み → 最小構成、というステップでルールを育てる
という運用スタイルが有効です。
Container Apps は「基盤を意識せずにコンテナアプリを動かせる」ことが最大の魅力ですが、ネットワークを完全にコントロールしたい場面では、裏側の AKS 的な側面を理解することが不可欠です。Azure Firewall のログを「プラットフォームの声」として捉え、実トラフィックを起点に設計・運用することで、セキュアかつ安定した Azure Container Apps 環境を構築していきましょう。
コメント