AWS Network FirewallのHTTPとHTTPSのアクセス先ドメインリストレポート機能を使ってみた
アクセス先のドメインリストの整理をコストをかけずに楽に行いたい
こんにちは、のんピ(@non____97)です。
皆さんはアクセス先のドメインリストの整理をコストをかけずに楽に行いたいなと思ったことはありますか? 私はあります。
ドメインベースでAWS Network FirewallのAllow ListやDeny Listを作成する際に、現在どのようなドメインにアクセスしているのか気になるところです。
Flow LogsをCloudWatch LogsやS3バケットに出力しているのであれば、CloudWatch Logs InsightsやAthenaを使うことで集計は可能です。ただし、実行するクエリを考えたり、いずれの手法もスキャン量で課金がかかるため長期間のログをクエリする際には料金が気になります。
そんな時に便利なのがAWS Network Firewallのドメインリストレポート機能です。
AWS Blogsにも投稿されています。
こちらの機能を用いることで、過去30日間のHTTP/HTTPSのアクセス先のドメインリストをレポートしてくれます。
しかもCloudWatch Logs InsightsやAthenaが裏側で動くような仕組みではないため、料金は無料です。
これは最高ですね。
実際に触ってみます。
仕様の確認
まず、ドキュメントから仕様を確認します。
対象のドキュメントは以下です。
こちらのドキュメントに記載されていることをまとめると、以下のとおりです。
- アクセス先からドメインリストをレポートするためにはAWS Network Firewallでトラフィック分析モードを有効化する必要がある
- 分析範囲はトラフィック分析モードを有効化してから最大30日間
- トラフィック分析モードを有効にする前のトラフィックは分析対象外
- 分析対象のプロトコルはHTTPとHTTPSのみ
- 各プロトコルごとに再生成するには30日経過する必要がある
- 30日経過したレポートは自動的に削除する
- レポートあたりの結果の最大件数は1000件
- レポートに含まれる情報は以下
- 最も頻繁にアクセスされるドメイン
- 観測された各ドメインへのアクセス試行回数
- 観測された各ドメインに接続する一意のソースIPの数
- ドメインが最初にアクセスされた日時
- ドメインが最後にアクセスされた日時
- ドメインのトラフィックで使用されるプロトコル
レポートに含まれるドメイン数が1,000となっている場合、これを元にドメインのAllow Listを作るのは注意が必要ですね。
やってみた
検証環境
実際に触ってみます。
検証環境は以下のとおりです。
AWS Network Firewallでは既にトラフィック分析モードは有効にしています。
また、以下のように.comと.jpのみを許可するルールグループを適用しています。
ルールの評価順序はStrict Orderで、デフォルトアクションはDrop establishedにしています。
アクセス
EC2インスタンスから外部のドメインにアクセスします。
curlを用いて以下ドメインにHEADやGETでアクセスします。
- dev.classmethod.jp
- classmethod.jp
- aws.amazon.com
- www.google.com
- google.com
- wwww.non-97.net
- ja.wikipedia.org
例)
$ curl https://www.google.com -I -m 10 -X GET
HTTP/2 200
date: Tue, 07 Oct 2025 20:30:00 GMT
expires: -1
cache-control: private, max-age=0
content-type: text/html; charset=ISO-8859-1
content-security-policy-report-only: object-src 'none';base-uri 'self';script-src 'nonce-ht08EgT6bTThty83_PQt9w' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
accept-ch: Sec-CH-Prefers-Color-Scheme
p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
server: gws
x-xss-protection: 0
x-frame-options: SAMEORIGIN
set-cookie: AEC=AaJma5vBJueWBI3GHxFiMnCpYr9JJIxHIzQtGz03PWV3y9lWRUZkblwv8A; expires=Sun, 05-Apr-2026 20:30:00 GMT; path=/; domain=.google.com; Secure; HttpOnly; SameSite=lax
set-cookie: NID=525=R1-ZquSu80iUh4GDoXf99HMJ_vt4oNNzn8009wDLJXUm1dESW9cw_qgNLsrYCquRsHw9fXRyc_szA1VoRrP6jehtcoA0XkM00vpMPM8bGAi6pHA-k6Kqntq6_nYVURDrnD61zIXByiRnTjBqQmyDfAuw_xC1VZhdGLrR_d-B216d94bQJWptrQqyZLLf-zLzGXwxpOLnTxm7S0JAq9ez0NDn; expires=Wed, 08-Apr-2026 20:30:00 GMT; path=/; domain=.google.com; HttpOnly
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
accept-ranges: none
vary: Accept-Encoding
また、EC2インスタンスではSSM Agentが動作しており、VPCエンドポイントは何も用意していないためAWS Network Firewallを経由して、SSMのサービスエンドポイントにアクセスしていす。
レポートの生成
それではドメインリストのレポートを生成します。
HTTPとHTTPSのレポートを生成します。30日間待つ必要があると記載がありますね。
モニタリングとオブザーバビリティタブを確認すると、HTTPとHTTPSのレポートがそれぞれ生成されていました。
リクエストしてから生成されるまではは体感1分もかかっていません。
HTTPSのレポートを確認します。
.comと.jpと、許可されているドメインのみ表示されていますね。AWS Network Firewallでドロップされたアクセスについては分析されないようです。
HTTPのレポートは以下のとおりです。
CSV形式で出力されたレポートの確認
CSV形式で出力されたレポートも確認します。
AnalysisType,StartTime,EndTime,Protocol,Domain,FirstAccessed,LastAccessed,Hits,UniqueSources
TLS_SNI,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,ssm.us-east-1.amazonaws.com,"2025年10月8日, 05:15 (UTC+09:00)","2025年10月8日, 06:06 (UTC+09:00)",31,1
TLS_SNI,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,logs.us-east-1.amazonaws.com,"2025年10月8日, 05:17 (UTC+09:00)","2025年10月8日, 05:31 (UTC+09:00)",17,1
TLS_SNI,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,aws.amazon.com,"2025年10月8日, 05:21 (UTC+09:00)","2025年10月8日, 05:21 (UTC+09:00)",7,1
TLS_SNI,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,ec2messages.us-east-1.amazonaws.com,"2025年10月8日, 05:15 (UTC+09:00)","2025年10月8日, 05:16 (UTC+09:00)",4,1
TLS_SNI,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,www.google.com,"2025年10月8日, 05:29 (UTC+09:00)","2025年10月8日, 05:30 (UTC+09:00)",4,1
TLS_SNI,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,classmethod.jp,"2025年10月8日, 05:22 (UTC+09:00)","2025年10月8日, 05:24 (UTC+09:00)",4,1
TLS_SNI,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,ssmmessages.us-east-1.amazonaws.com,"2025年10月8日, 05:15 (UTC+09:00)","2025年10月8日, 05:17 (UTC+09:00)",4,1
TLS_SNI,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,google.com,"2025年10月8日, 05:29 (UTC+09:00)","2025年10月8日, 05:29 (UTC+09:00)",2,1
TLS_SNI,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,dev.classmethod.jp,"2025年10月8日, 05:18 (UTC+09:00)","2025年10月8日, 05:24 (UTC+09:00)",2,1
AnalysisType,StartTime,EndTime,Protocol,Domain,FirstAccessed,LastAccessed,Hits,UniqueSources
HTTP_HOST,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,aws.amazon.com,"2025年10月8日, 05:21 (UTC+09:00)","2025年10月8日, 05:22 (UTC+09:00)",7,1
HTTP_HOST,"2025年9月8日, 06:00 (UTC+09:00)","2025年10月8日, 06:00 (UTC+09:00)",TCP,dev.classmethod.jp,"2025年10月8日, 05:18 (UTC+09:00)","2025年10月8日, 05:18 (UTC+09:00)",1,1
確認できる情報はマネジメントコンソールと同じですね。
CSV形式なので、継続して許可するべきドメインなのかの判定をために生成AIに渡す際に役立ちそうですね。
レポートからドメインリストルールを作成
生成されたレポートからドメインリストルールの作成しようとしてみます。
すると、ドメインリストルールのドメイン名にレポートに含まれていたドメイン名が全てテキストエリアに記載されていました。
これは便利ですね。
レポートの再生成
レポートを生成する際に以下の文言が気になりました。
一度使用すると、このタイプの別の無料レポートを生成するには、30 日間待つ必要があります。
裏を返すと、お金を払えば30日待たなくともレポートを生成することができるのでしょうか。
しかし、2025/10/11時点でレポートに関わる料金の記載は料金ページに記載ありませんでした。
実際に再生成しようとしてみます。
はい、プロトコルがグレーアウトしてしまい、レポートの生成をすることができませんでした。
AWS CLIでもトライします。
> aws network-firewall start-analysis-report \
--firewall-name non-97-nfw \
--analysis-type TLS_SNI
An error occurred (InvalidRequestException) when calling the StartAnalysisReport operation: Exceeded maximum number of TLS_SNI reports allowed in a 30-day period. Next report can be run at 2025-11-10 05:43:59.527 UTC.
やはりダメでした。30日待ちましょう。
ドメインリストの定期的な更新のお供に
AWS Network FirewallのHTTPとHTTPSのアクセス先ドメインリスト生成機能を使ってみました。
ドメインリストの定期的な更新のお供として非常に頼りになる存在ですね。
初期導入のタイミングからAllow Listで対応するのは難しいと思います。稼働してからしばらく経った後にこの機能を使って絞り込みを行いましょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
