WAFログをS3に保存する方法について

AWS WAFのログは、Web ACLが評価したリクエストの内容や、どのルールに一致したか、最終的に許可・ブロック・カウントされたかなどを確認するために利用できます。

WAFログの保存先には、主に以下の3つがあります。

Amazon CloudWatch Logs
Amazon S3
Amazon Data Firehose

このうち、ログを長期保管したい場合や、Athenaで後から分析したい場合は、Amazon S3への保存 がよく使われます。

WAFログをS3に保存する方法は、大きく分けて以下の2種類です。

AWS WAF → S3へ直接保存
AWS WAF → Amazon Data Firehose → S3へ保存

基本的には、単純にログを保管したいだけであれば S3直接保存 がシンプルです。

一方で、ログを加工したい、S3の保存パスを柔軟に設計したい、SIEMや分析基盤と連携したい場合は、Data Firehose経由 を検討します。

WAFログをS3に直接保存する方法

S3直接保存の概要

最もシンプルな構成は、AWS WAFからS3バケットへ直接ログを出力する方法です。

CloudFront / ALB / API Gateway など
        ↓
AWS WAF Web ACL
        ↓
Amazon S3

この方法では、Amazon Data Firehoseを作成する必要がありません。

そのため、設定項目が少なく、WAFログをまず保存したい場合に向いています。

主な用途は以下の通りです。

WAFログの保管
BLOCKされたリクエストの確認
攻撃元IPの調査
誤検知の確認
監査対応
Athenaによる後日分析

S3バケットを作成する

まず、WAFログ保存用のS3バケットを作成します。

ここで重要なのは、S3バケット名を aws-waf-logs- で始める必要がある という点です。

たとえば、以下のようなバケット名にします。

aws-waf-logs-123456789012-ap-northeast-1-prod
aws-waf-logs-company-prod
aws-waf-logs-cloudfront-prod
aws-waf-logs-alb-prod

反対に、以下のようなバケット名はWAFログの出力先として使えません。

company-waf-logs-prod
waf-logs-prod
security-logs-waf

S3直接保存を利用する場合は、バケット名の先頭が必ず aws-waf-logs- になっているか確認してください。

S3バケットの推奨設定

WAFログには、リクエスト情報やヘッダー、URI、クエリ文字列などが含まれる可能性があります。

そのため、S3バケットはセキュリティを意識して設定する必要があります。

最低限、以下の設定をおすすめします。

パブリックアクセス：すべてブロック
暗号化：SSE-S3 または SSE-KMS
バージョニング：必要に応じて有効化
ライフサイクルルール：保存期間に応じて設定
アクセス制御：必要最小限のIAM権限にする

シンプルに始める場合は、暗号化は SSE-S3 で問題ありません。

より厳格に管理したい場合は、SSE-KMSのカスタマー管理キー を利用します。

ただし、SSE-KMSを使う場合は、KMSキーポリシーの設定が必要です。

注意点として、AWS WAFログのS3保存では、AWS管理KMSキーはサポートされません。

SSE-KMSを使う場合は、カスタマー管理キーを利用してください。

AWS WAFでログ出力を有効化する

S3バケットを作成したら、AWS WAF側でログ出力を有効化します。

AWSマネジメントコンソールでは、以下の流れで設定できます。

AWS WAF & Shield コンソール
  ↓
Web ACLs
  ↓
対象のWeb ACLを選択
  ↓
Logging and metrics
  ↓
Enable logging
  ↓
Logging destinationでAmazon S3 bucketを選択
  ↓
作成したS3バケットを選択
  ↓
保存

ここで選択するS3バケットは、先ほど作成した aws-waf-logs- で始まるバケットです。

設定後、すぐにログが出力されない場合があります。

S3直接保存では、WAFログは通常 5分間隔 で出力されます。

S3に保存されるログのパス

WAFログは、S3バケット内に以下のような階層で保存されます。

s3://aws-waf-logs-xxxx/
  AWSLogs/
    <account-id>/
      WAFLogs/
        <region>/
          <web-acl-name>/
            YYYY/
              MM/
                dd/
                  HH/
                    mm/
                      <account-id>_waflogs_<region>_<web-acl-name>_<timestamp>_<hash>.log.gz

たとえば、以下のようなパスになります。

s3://aws-waf-logs-123456789012-prod/
AWSLogs/123456789012/WAFLogs/ap-northeast-1/my-web-acl/2026/05/19/10/00/
123456789012_waflogs_ap-northeast-1_my-web-acl_20260519T1000Z_xxxxx.log.gz

ログファイルはgzip形式で圧縮されています。

ローカルで確認する場合は、ダウンロードして展開する必要があります。

S3プレフィックスを指定する場合

S3直接保存でも、AWS CLI、API、CloudFormationを使う場合は、S3バケットだけでなく プレフィックス付きの保存先 を指定できます。

例

s3://aws-waf-logs-company-prod/cloudfront/
s3://aws-waf-logs-company-prod/alb/
s3://aws-waf-logs-company-prod/prod/

ただし、コンソールではプレフィックス指定に対応していない場合があります。

プレフィックスを細かく分けたい場合は、AWS CLIやCloudFormationで設定する方法を検討してください。

WAFログの出力間隔

S3直接保存では通常5分間隔で出力される

WAFログをS3へ直接保存する場合、ログファイルは通常 5分間隔 でS3に出力されます。

各ログファイルには、直前5分間のリクエストログが含まれます。

そのため、ログ設定を有効化した直後にS3を確認しても、まだファイルが表示されていないことがあります。

設定後は、数分待ってからS3バケットを確認してください。

ファイルサイズが大きい場合は5分未満で出力されることがある

S3直接保存では、基本的には5分間隔でログが出力されます。

ただし、ログファイルが一定サイズに達した場合は、5分を待たずに新しいログファイルとして出力されることがあります。

トラフィック量が多いWebサイトでは、短時間に複数のログファイルが作成される場合があります。

IAM権限とS3バケットポリシー

ログ設定を行うユーザーに必要な権限

AWS WAFでログ設定を有効化するユーザー、またはIAMロールには、ログ設定を変更するための権限が必要です。

代表的には、以下のような権限が必要です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WAFLoggingConfiguration",
      "Effect": "Allow",
      "Action": [
        "wafv2:PutLoggingConfiguration",
        "wafv2:DeleteLoggingConfiguration"
      ],
      "Resource": "*"
    },
    {
      "Sid": "LogDelivery",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogDelivery",
        "logs:DeleteLogDelivery"
      ],
      "Resource": "*"
    },
    {
      "Sid": "S3BucketPolicyAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketPolicy",
        "s3:PutBucketPolicy"
      ],
      "Resource": "arn:aws:s3:::aws-waf-logs-example"
    }
  ]
}

ログ設定を行うIAMユーザーやロールに十分な権限がない場合、S3バケットを選択できなかったり、ログ設定時にエラーになったりします。

S3バケット側で必要な権限

WAFログをS3へ配信する主体は、ログ配信サービスです。

S3バケットポリシーでは、以下のサービスプリンシパルに対して書き込みを許可します。

delivery.logs.amazonaws.com

代表的なバケットポリシーの考え方は以下です。

{
  "Sid": "AWSLogDeliveryWrite",
  "Effect": "Allow",
  "Principal": {
    "Service": "delivery.logs.amazonaws.com"
  },
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::aws-waf-logs-example/AWSLogs/123456789012/*",
  "Condition": {
    "StringEquals": {
      "s3:x-amz-acl": "bucket-owner-full-control",
      "aws:SourceAccount": "123456789012"
    },
    "ArnLike": {
      "aws:SourceArn": "arn:aws:logs:ap-northeast-1:123456789012:*"
    }
  }
}

また、バケットACLの確認用に以下の権限も必要です。

s3:GetBucketAcl

CloudTrail上のAccessDeniedを避けたい場合は、必要に応じて以下も許可します。

s3:ListBucket

バケットポリシーは自動追加される場合がある

ログ設定を行うユーザーがS3バケットに対して十分な権限を持っている場合、AWS側で必要なバケットポリシーが自動的に追加されることがあります。

ただし、以下のような場合は手動でバケットポリシーの調整が必要になることがあります。

ログ設定者にs3:PutBucketPolicyがない
別アカウントのS3バケットを使う
S3バケットポリシーを厳格に管理している
SSE-KMSを利用している
OrganizationsやSCPで制限している

ログ設定に失敗する場合は、IAM権限とS3バケットポリシーの両方を確認してください。

SSE-KMSを使う場合の注意点

カスタマー管理キーを使う

WAFログ保存用のS3バケットでSSE-KMSを利用する場合は、カスタマー管理KMSキー を使います。

AWS管理KMSキーはサポートされないため、注意が必要です。

KMSキーポリシーを設定する

SSE-KMSを使う場合、KMSキーポリシーでログ配信サービスに対して必要な権限を許可します。

代表的には、以下のような権限が必要です。

kms:GenerateDataKey*

対象のサービスプリンシパルは以下です。

delivery.logs.amazonaws.com

KMSキーポリシーが不足していると、S3バケット側の権限が正しくてもログ配信に失敗することがあります。

CloudFront用WAFログの注意点

CloudFrontスコープのWeb ACLはus-east-1を意識する

CloudFrontに紐づけるAWS WAFのWeb ACLは、リージョナルリソースではなく グローバルスコープ のWeb ACLとして扱われます。

AWS CLIやAPIでCloudFrontスコープのWeb ACLを操作する場合は、基本的に us-east-1 を使います。

たとえば、CloudFront用Web ACLのログ設定をCLIで行う場合は、--region us-east-1 を指定します。

S3バケットを必ずus-east-1に置くという意味ではない

CloudFront用WAFで us-east-1 を意識する必要がある、という説明は、主に WAFv2 API操作やFirehose作成リージョン の話です。

S3直接保存の場合、S3バケットそのものを必ず us-east-1 に作成しなければならない、という意味ではありません。

誤解しやすいポイントなので、以下のように整理するとわかりやすいです。

CloudFront用Web ACLをCLI/APIで操作する場合：us-east-1を使う
CloudFront用WAFログをFirehose経由で出す場合：Firehoseはus-east-1に作成する
S3直接保存先のS3バケット：必ずus-east-1でなければならない、とは限らない

Amazon Data Firehose経由でS3に保存する方法

Firehose経由の概要

WAFログをS3へ保存するもう1つの方法が、Amazon Data Firehoseを経由する方法です。

構成は以下のようになります。

AWS WAF
  ↓
Amazon Data Firehose
  ↓
Amazon S3

Firehose経由にすると、S3直接保存よりも構成は複雑になります。

その代わり、ログの配送や保存形式をより柔軟に設計できます。

Firehose経由が向いているケース

以下のような要件がある場合は、Firehose経由を検討します。

S3の保存プレフィックスを柔軟に設計したい
ログをLambdaで加工してから保存したい
バッファサイズやバッファ間隔を調整したい
OpenSearchやSIEMと連携したい
分析基盤に取り込みやすい構成にしたい
高トラフィック環境でログ配信を細かく制御したい

単純なログ保管だけであればS3直接保存で十分ですが、セキュリティ分析や運用基盤に組み込む場合はFirehose経由が便利です。

Firehose delivery streamを作成する

WAFログをFirehoseへ送る場合、Firehose delivery streamにはいくつかの条件があります。

Web ACLと同じアカウントに作成する
Web ACLと同じリージョンに作成する
CloudFront用WAFログの場合はus-east-1に作成する
Delivery stream名をaws-waf-logs-で始める
SourceはDirect PUTにする
Kinesis streamをソースにしない

Firehose名の例は以下です。

aws-waf-logs-cloudfront-prod
aws-waf-logs-alb-prod
aws-waf-logs-api-prod

S3直接保存ではS3バケット名が aws-waf-logs- で始まる必要があります。

Firehose経由では、Firehose delivery stream名を aws-waf-logs- で始める必要があります。

FirehoseのS3保存プレフィックス例

Firehose経由では、S3への保存プレフィックスを柔軟に設計できます。

Athenaで分析しやすくするなら、以下のような日付パーティションを意識したプレフィックスがおすすめです。

AWSLogs/waf/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/

エラーログ用には、以下のようなプレフィックスを設定できます。

AWSLogs/waf-error/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/!{firehose:error-output-type}/

このように設計しておくと、後からAthenaやGlueで分析する際に扱いやすくなります。

WAF側でログ出力先にFirehoseを指定する

Firehose delivery streamを作成したら、WAF側でログ出力先にFirehoseを指定します。

AWS WAF
  ↓
Web ACLs
  ↓
対象Web ACL
  ↓
Logging and metrics
  ↓
Enable logging
  ↓
Amazon Data Firehose delivery stream
  ↓
作成したFirehoseを選択
  ↓
保存

CloudFront用WAFログの場合は、Firehose delivery streamを us-east-1 に作成しているか確認してください。

Firehose経由の注意点

WAFログ1件はFirehoseレコード1件として扱われる

Firehose経由の場合、WAFログ1件はFirehoseの1レコードとして扱われます。

たとえば、フルログを有効化していて秒間10,000リクエストがある場合、Firehose側も秒間10,000レコードを処理できる必要があります。

Firehoseのスループットが不足していると、すべてのWAFログを記録できない可能性があります。

高トラフィックサイトでは、以下を確認してください。

Firehoseのクォータ
秒間レコード数
秒間データ量
バッファサイズ
バッファ間隔
S3 PUT数
圧縮設定
コスト

Firehose経由はコストと運用が増える

Firehose経由は柔軟ですが、S3直接保存よりも構成要素が増えます。

AWS WAF
Amazon Data Firehose
Amazon S3
必要に応じてLambda
必要に応じてGlue / Athena / OpenSearch

そのため、ログ保管だけが目的であれば、まずはS3直接保存から始める方がよいです。

S3直接保存とFirehose経由の比較

構成の違い

項目	S3直接保存	Firehose経由
構成	シンプル	やや複雑
初期設定	簡単	Firehose作成が必要
ログ保存先	S3	Firehose経由でS3
S3プレフィックス設計	制限あり。ただしCLI/APIなら指定可能	柔軟
ログ加工	基本的に不可	Lambda変換などが可能
分析基盤連携	可能	より柔軟
運用負荷	低い	やや高い
おすすめ用途	保管・監査・簡易分析	加工・高度分析・SIEM連携

選び方の目安

通常は、以下の基準で選ぶとよいです。

ログを保存したいだけ：S3直接保存
Athenaでたまに分析したい：S3直接保存
ログ保存パスを細かく制御したい：Firehose経由
Lambdaでログを加工したい：Firehose経由
SIEMやOpenSearchに連携したい：Firehose経由
大規模なセキュリティ分析基盤に組み込みたい：Firehose経由

迷った場合は、まずS3直接保存で始めるのがおすすめです。

WAFログに含まれる主な情報

代表的なログ項目

AWS WAFログには、主に以下のような情報が含まれます。

timestamp
formatVersion
webaclId
terminatingRuleId
terminatingRuleType
action
httpSourceName
httpSourceId
ruleGroupList
rateBasedRuleList
nonTerminatingMatchingRules
httpRequest
  clientIp
  country
  headers
  uri
  args
  httpVersion
  httpMethod
  requestId

これらの情報を使うことで、どのリクエストがどのルールに一致したのかを確認できます。

WAFログで確認できること

WAFログを保存しておくと、以下のような調査に役立ちます。

BLOCKされたリクエストの確認
SQLインジェクション検知の確認
XSS検知の確認
Botアクセスの傾向確認
攻撃元IPの特定
国別アクセスの確認
誤検知の調査
レートベースルールの調整
特定URIへの攻撃傾向分析

特に、WAFルールを本番環境に適用する場合は、いきなりBLOCKにするのではなく、まずCOUNTモードでログを確認し、誤検知がないか確認する運用が安全です。

Redacted fieldsで機密情報をマスクする

WAFログには機密情報が含まれる可能性がある

WAFログには、リクエストヘッダー、URI、クエリ文字列などが記録される場合があります。

そのため、以下のような情報がログに含まれる可能性があります。

Cookie
Authorizationヘッダー
X-Api-Key
セッションID
メールアドレス
検索キーワード
URLパラメータ内の個人情報

これらをそのままログに残すと、セキュリティや個人情報保護の観点で問題になる場合があります。

Redacted fieldsで指定できる項目

AWS WAFでは、ログに出したくない項目を Redacted fields でマスクできます。

ただし、Redacted fieldsで指定できる項目には制限があります。

主に指定できるのは以下です。

UriPath
QueryString
SingleHeader
Method

CookieやAuthorizationヘッダーをマスクしたい場合は、SingleHeader として指定します。

例：

SingleHeader: cookie
SingleHeader: authorization
SingleHeader: x-api-key

ログ保管を始める前に、どの情報をマスクすべきかを確認しておくことが重要です。

1つのWeb ACLに設定できるログ出力先

ログ出力先は1つだけ

AWS WAFのログ設定では、1つのWeb ACLに設定できるログ出力先は1つ です。

つまり、同じWeb ACLのログを以下のように同時出力することは基本的にできません。

CloudWatch LogsとS3に同時出力
S3とFirehoseに同時出力
複数のS3バケットに同時出力

複数の用途でログを使いたい場合は、FirehoseやS3イベント、Glue、Lambda、Security Lake、SIEM連携などを組み合わせて設計します。

AWS CLIでWAFログをS3に保存する設定例

S3直接保存のCLI例

リージョナルWeb ACLのログをS3へ直接保存する場合は、以下のように設定します。

aws wafv2 put-logging-configuration \
  --logging-configuration '{
    "ResourceArn": "arn:aws:wafv2:ap-northeast-1:123456789012:regional/webacl/example-web-acl/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "LogDestinationConfigs": [
      "arn:aws:s3:::aws-waf-logs-123456789012-ap-northeast-1-prod"
    ]
  }' \
  --region ap-northeast-1

S3プレフィックスを指定する場合は、以下のように指定します。

aws wafv2 put-logging-configuration \
  --logging-configuration '{
    "ResourceArn": "arn:aws:wafv2:ap-northeast-1:123456789012:regional/webacl/example-web-acl/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "LogDestinationConfigs": [
      "arn:aws:s3:::aws-waf-logs-123456789012-ap-northeast-1-prod/cloudfront/"
    ]
  }' \
  --region ap-northeast-1

CloudFront用Web ACLのCLI例

CloudFrontスコープのWeb ACLに対してログ設定を行う場合は、--region us-east-1 を指定します。

aws wafv2 put-logging-configuration \
  --logging-configuration '{
    "ResourceArn": "arn:aws:wafv2:us-east-1:123456789012:global/webacl/example-cloudfront-web-acl/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "LogDestinationConfigs": [
      "arn:aws:s3:::aws-waf-logs-123456789012-cloudfront-prod"
    ]
  }' \
  --region us-east-1

CloudFront用Web ACLでは、ResourceArnに global/webacl が含まれます。

Firehose経由のCLI例

Firehose経由でWAFログをS3に保存する場合は、ログ出力先にFirehose delivery streamのARNを指定します。

aws wafv2 put-logging-configuration \
  --logging-configuration '{
    "ResourceArn": "arn:aws:wafv2:us-east-1:123456789012:global/webacl/example-cloudfront-web-acl/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "LogDestinationConfigs": [
      "arn:aws:firehose:us-east-1:123456789012:deliverystream/aws-waf-logs-cloudfront-prod"
    ]
  }' \
  --region us-east-1

Firehose名は aws-waf-logs- で始める必要があります。

S3保存後にAthenaで分析する方法

Athena分析の概要

WAFログをS3に保存しておくと、Amazon Athenaを使ってSQLで分析できます。

Athenaを使えば、以下のような分析が可能です。

BLOCKされたリクエストの一覧化
攻撃元IPランキング
国別アクセス数
URI別ブロック数
特定ルールに一致したリクエストの調査

WAFログを継続的に保存する場合は、後からAthenaで分析できるように、S3の保存パスやライフサイクル設計もあわせて考えておくと便利です。

BLOCKされたリクエストを確認するSQL例

SELECT
  from_unixtime(timestamp / 1000) AS time,
  httprequest.clientip,
  httprequest.country,
  httprequest.uri,
  terminatingruleid,
  action
FROM waf_logs
WHERE action = 'BLOCK'
ORDER BY time DESC
LIMIT 100;

攻撃元IPを集計するSQL例

SELECT
  httprequest.clientip,
  count(*) AS request_count
FROM waf_logs
WHERE action = 'BLOCK'
GROUP BY httprequest.clientip
ORDER BY request_count DESC
LIMIT 50;

URI別にブロック数を集計するSQL例

SELECT
  httprequest.uri,
  count(*) AS block_count
FROM waf_logs
WHERE action = 'BLOCK'
GROUP BY httprequest.uri
ORDER BY block_count DESC
LIMIT 50;

国別アクセス数を集計するSQL例

SELECT
  httprequest.country,
  count(*) AS request_count
FROM waf_logs
GROUP BY httprequest.country
ORDER BY request_count DESC;

S3ライフサイクル設定の考え方

WAFログは保存期間を決めて管理する

WAFログは継続的に増えていきます。

そのため、S3に保存したまま放置すると、ストレージコストが増加します。

あらかじめ、保存期間に応じてライフサイクルルールを設定しておくことが重要です。

保存期間の目安

保存期間は、セキュリティポリシーや監査要件によって変わります。

一般的には、以下のような考え方ができます。

短期調査目的：30〜90日
セキュリティ監査：180日〜1年
内部統制・法令対応：1年以上

ライフサイクルルールの例

たとえば、以下のようなライフサイクルを設定できます。

0〜30日：S3 Standard
31〜180日：S3 Standard-IA または Glacier Instant Retrieval
181日〜1年：Glacier Flexible Retrieval
1年後：削除または Deep Archive

すぐに検索・分析する可能性がある期間はS3 Standardに置き、古いログは低コストなストレージクラスへ移行すると、コストを抑えやすくなります。

よくあるエラーと対処法

S3バケットが選択肢に表示されない

S3バケットがWAFログの出力先として表示されない場合、まずバケット名を確認します。

WAFログ用のS3バケット名は、aws-waf-logs- で始まる必要があります。

OK: aws-waf-logs-company-prod
NG: company-waf-logs-prod

そのほか、以下も確認してください。

対象Web ACLとアカウントの関係が正しいか
ログ設定者に必要なIAM権限があるか
CloudFrontスコープとリージョナルスコープを間違えていないか

S3にログが出力されない

ログ設定後にS3へログが出力されない場合は、以下を確認します。

WAFのLoggingが有効になっているか
対象Web ACLに実際のトラフィックがあるか
S3バケット名がaws-waf-logs-で始まっているか
S3バケットポリシーが正しいか
KMSキーポリシーが正しいか
数分待っているか

S3直接保存では通常5分間隔でログが出力されるため、設定直後はログファイルがまだ作成されていない可能性があります。

AccessDeniedが発生する

AccessDeniedが発生する場合は、主に以下が原因です。

ログ設定者にs3:GetBucketPolicyがない
ログ設定者にs3:PutBucketPolicyがない
S3バケットポリシーでdelivery.logs.amazonaws.comを許可していない
S3バケットポリシーのaws:SourceAccountが誤っている
S3バケットポリシーのaws:SourceArnが誤っている
SSE-KMSのキーポリシーが不足している
OrganizationsやSCPで制限されている

SSE-KMSを使っている場合は、S3だけでなくKMSキーポリシーも確認してください。

Firehoseにログが流れない

Firehose経由でログが流れない場合は、以下を確認します。

Firehose名がaws-waf-logs-で始まっているか
FirehoseのSourceがDirect PUTになっているか
Web ACLと同じアカウントにFirehoseがあるか
Web ACLと同じリージョンにFirehoseがあるか
CloudFront用の場合はFirehoseがus-east-1にあるか
FirehoseのS3配信先権限が正しいか
Firehoseのスループットが不足していないか

Firehose経由は設定箇所が増えるため、WAF側、Firehose側、S3側の権限を分けて確認すると原因を特定しやすくなります。

実務でおすすめの構成

小〜中規模サイトの場合

小〜中規模サイトで、WAFログを保管して必要なときに確認する程度であれば、S3直接保存がおすすめです。

AWS WAF
  ↓
Amazon S3
  ↓
Amazon Athena

おすすめ設定は以下です。

S3バケット名：aws-waf-logs-<account-id>-<env>
暗号化：SSE-S3
ログ保存期間：90日〜180日
分析：Athena
Redacted fields：cookie / authorization / query string などを必要に応じて設定

まずはこの構成で十分です。

大規模サイト・セキュリティ運用がある場合

大規模サイトやセキュリティ運用基盤に組み込む場合は、Firehose経由を検討します。

AWS WAF
  ↓
Amazon Data Firehose
  ↓
Amazon S3
  ↓
Athena / OpenSearch / SIEM

おすすめ設定は以下です。

Firehose名：aws-waf-logs-<service>-<env>
Source：Direct PUT
圧縮：GZIP
S3プレフィックス：year/month/day/hourで分割
保存期間：180日〜数年
ログ加工：必要に応じてLambda
分析：Athena / OpenSearch / SIEM

Firehose経由にすることで、ログ分析や外部連携の自由度が高くなります。

設定前のチェックリスト

S3直接保存のチェックリスト

□ S3バケット名がaws-waf-logs-で始まっている
□ S3バケットのパブリックアクセスをブロックしている
□ S3バケットの暗号化を設定している
□ 必要に応じてS3ライフサイクルルールを設定している
□ WAFのLoggingを有効化している
□ ログ出力先にS3バケットを指定している
□ ログ設定者にwafv2:PutLoggingConfigurationがある
□ ログ設定者にs3:GetBucketPolicy / s3:PutBucketPolicyがある
□ delivery.logs.amazonaws.comがS3に書き込める
□ SSE-KMS利用時はKMSキーポリシーを設定している
□ Redacted fieldsで機密情報をマスクしている
□ CloudFront用Web ACLの場合はus-east-1を意識している

Firehose経由のチェックリスト

□ Firehose名がaws-waf-logs-で始まっている
□ FirehoseのSourceがDirect PUTになっている
□ FirehoseがWeb ACLと同じアカウントにある
□ FirehoseがWeb ACLと同じリージョンにある
□ CloudFront用の場合はFirehoseがus-east-1にある
□ Firehoseの配信先S3バケットが正しく設定されている
□ FirehoseのIAMロールにS3書き込み権限がある
□ Firehoseのスループットがトラフィック量に合っている
□ エラー出力用プレフィックスを設定している
□ 必要に応じてLambda変換を設定している

まとめ

AWS WAFログをS3に保存する方法は、主に S3直接保存 と Data Firehose経由 の2つです。

単純にWAFログを保管したい場合は、S3直接保存が最もシンプルです。

S3バケット名を aws-waf-logs- で始め、WAFのLogging設定で出力先にS3を指定すれば、WAFログをS3に保存できます。

一方で、ログ加工、柔軟なプレフィックス設計、SIEM連携、分析基盤への取り込みなどを行いたい場合は、Data Firehose経由が向いています。

実務では、まず以下のように考えるとよいです。

保管・監査・簡易分析が目的：S3直接保存
加工・高度分析・外部連携が目的：Firehose経由

また、WAFログにはCookie、Authorizationヘッダー、クエリ文字列などの機密情報が含まれる可能性があります。

そのため、Redacted fieldsによるマスク、S3バケットの暗号化、ライフサイクル管理、アクセス権限の最小化をあわせて設定することが重要です。

以上、WAFログをS3に保存する方法についてでした。

最後までお読みいただき、ありがとうございました。