【Azure Firewall】FQDN許可しているのにAWS S3への通信がDenyされる原因と対策
Azure 上の仮想マシン（VM）から AWS S3 などの外部クラウドサービスへデータを送信する際、「Azure Firewall の Network Rule で FQDN を許可しているのに、なぜか通信が失敗する（ごく稀に成功する）」という現象に遭遇したことはないでしょうか？
ログを確認すると Azure Firewall で Deny が記録されており、「ルールは通したはずなのに…」と頭を抱えるケースが少なくありません。
今回は、この現象が起こる技術的な背景と、確実に問題を解決するためのベストプラクティスを解説します。
1. 発生する現象
-
環境: Azure 仮想ネットワーク（VNet）内の VM から、Azure Firewall 経由で AWS S3（
*.amazonaws.com）へ HTTPS 通信を行う。 -
設定: Azure Firewall の Network Rule（L4） にて、S3 や STS の FQDN（例:
s3.test.amazonaws.com）に対する HTTPS (443) 通信を許可。DNS Proxy も有効化済み。 -
症状: S3 へのファイルアップロードが高確率でタイムアウトや接続エラーになり失敗する。Azure Firewall のログには
Denyが記録されている。
2. なぜ Deny されるのか？（根本原因）
結論から言うと、「AWS S3 の IP アドレスが動的かつ多数存在する仕様」と「Azure Firewall の Network Rule（L4）による FQDN 制御の仕組み」がバッティングしていることが原因です。
① Network Rule（L4）における FQDN 制御の仕組み
Azure Firewall の Network Rule は、本質的には L4（IP アドレス + ポート番号） でフィルタリングを行います。FQDN を指定した場合、Azure Firewall は内部で以下のように動きます。
- DNS Proxy などを通じて対象 FQDN の IP アドレスを解決する。
- 解決された IP アドレスを動的に L4 の許可リストに登録する。
② S3（CDN / 大規模プラットフォーム）の DNS 仕様
AWS S3 などの巨大なクラウドサービスは、負荷分散や高可用性のために以下の特徴を持っています。
- 膨大な IP アドレスプール: 1つの FQDN に対して多数の IP アドレスが存在する。
- DNS レスポンスのランダム性: クライアントが DNS 問い合わせを行うたびに、返ってくる IP アドレスの組み合わせや順番が変わる（Round-Robin など）。
- 極めて短い TTL: DNS ログの有効期限（TTL）が数十秒〜数分程度と短い。
③ 発生するタイムラグ（Race Condition）
これにより、以下のような「IP アドレスの認識のズレ」が発生します。
[ VM ] ----(1) DNS解決: S3のIPは「IP-A」---> [ DNS / AzFW ]
|
|---(2) IP-A 宛に TCP/HTTPS 接続を開始 ---> [ Azure Firewall ]
|
|-- (3) AzFWが保持する現在の許可リスト:
「IP-B, IP-C」
※AzFW側で直近に解決されたIP
|
v
【 判定：Deny 】
VM が通信しようとした瞬間の IP アドレス（IP-A）と、Azure Firewall がその時点で「この FQDN の IP である」と認識・保持している IP アドレス（IP-B）が一致しないため、防火墙は未知の IP へのアクセスと判断して通信を遮断（Deny）してしまいます。
また、大きなファイルをマルチパートアップロードする際、途中で接続が再確立されると別の IP へ切り替わり、処理の途中で Deny になるケースも多く見られます。
3. 解決策：Application Rule（L7）を使用する
この問題を根本から解決するには、Network Rule（L4）ではなく Application Rule（L7）を使用するのがベストプラクティスです。
なぜ Application Rule なら解決できるのか？
Application Rule は L7（アプリケーション層）で通信を制御します。HTTPS 通信の開始時に交わされる SSL/TLS 握手の SNI（Server Name Indication / クライアントがアクセスしたいホスト名） を直接読み取って判定します。
- IP アドレスに依存しない: 宛先 IP アドレスがどれだけ頻繁に変化しても関係ありません。
- FQDN を直接評価: HTTP ヘッダーや TLS SNI の FQDN が許可リストに一致していれば通信を通します。
4. 推奨される設定手順
Azure Firewall の設定変更
- 既存の Network Rule から該当の FQDN 規則を削除（または無効化） します。
- Application Rule コレクション に新規ルールを追加します。
| 項目 | 設定例 |
|---|---|
| ソース | 該当 VM の IP アドレス（またはサブネット） |
| プロトコル | https:443 |
| ターゲット FQDN |
s3.test.amazonaws.com |
*.s3.test.amazonaws.com（※バケット指定のワイルドカード）
ポイント: S3 へのアクセスは、バケット名がホスト名に含まれる形式（例:
bucket-name.s3.region.amazonaws.com）でリクエストが飛ぶことが一般的です。そのため、*.s3.region.amazonaws.comのようにワイルドカードを含めて許可しておくことで、サブドメインの揺れによる通信エラーを防ぐことができます。
まとめ
- Network Rule（L4）の FQDN 指定は、固定 IP に近い単一の FQDN に適しており、S3 や CDN などの「多重 IP / 短 TTL」なサービス相手では通信が不安定になります。
- HTTPS 通信であれば、迷わず Application Rule（L7）を使用することで、IP 変動による不揃いを完全に回避できます。
クラウドネイティブなサービス同士を接続する際は、ネットワーク層（L4）とアプリケーション層（L7）のどちらで制御すべきかを意識することが、トラブルシューティングの近道となります。