AWS WAFのログ出力先の選択肢と用途別の最適解とは

1. はじめに：AWS WAF運用で直面する3つのログ課題

AWS WAFを運用していると、以下のような課題に直面します。

課題1: 「昨日のアクセスログが見つからない」（保存期間の制約）

AWS WAFの管理コンソールでは、直近のサンプルリクエストしか保持されません。「先週発生したアクセス急増の原因を調査したい」であったり、「誤検知（False Positive）が発生したので、ブロックされたリクエストの詳細を見たい」と思っても、ログが既に消えている…というケースは珍しくありません。

課題2: 「ログ保存だけで月額コストが膨らんでいる」（コストの圧迫）

ログを外部サービスに保存すると、データ量に応じて従量課金されます。大規模なサービスでは、月間数百GBのログが生成されることもあり、「気づいたらログのコストだけで月数万円」という事態も。

課題3: 「既存の監視ツールと統合したい」（外部連携）

DatadogやSplunkで既にAWS全体を監視している場合、WAFログだけ別の場所に出力すると管理が煩雑になります。できれば一元化したいところです。

AWS WAFはこれらの課題に対して、要件やニーズに合わせて3つの出力先が選択可能です。

AWS WAFの導入・運用代行に関するご相談はこちら！

2. AWS WAFログの3つの出力先：機能とコスト比較

比較イメージを以下にまとめます。

• 横にスクロールします

2-1. Amazon CloudWatch Logs

• 特徴: ログ収集と分析機能がセットになったマネージドサービスです。
• メリット:
  • Logs Insightsで SQLライクなクエリを実行でき、「特定のIPからのアクセス数」「ブロックされたリクエスト一覧」などを数秒で可視化できます。
  • 設定が非常に簡単で、運用開始までのハードルが低い。
• コスト: 取り込み $0.76/GB、保存 $0.033/GB/月（ap-northeast-1の場合）
• デメリット: 大量のログを長期保存するとコストが高額になる

2-2. Amazon S3

• 特徴: オブジェクトストレージサービス。圧倒的な低コストで大量データを保存可能。
• メリット:
  • Standard ストレージクラスで $0.25/GB/月と、CloudWatchの1/10のコスト。（Athenaでクエリを実行した場合はスキャン量に対して $0.005/GB が追加されますが、それでも $0.03 程度）
  • Glacier や Glacier Deep Archive に移行すればさらに低コストが望めます。
• デメリット:
  • S3自体に検索機能はなく、分析には Amazon Athena（標準SQLでS3データをクエリ）などの追加サービスが必要。
  • ログ出力まで数分のタイムラグが発生する。

2-3. Amazon Data Firehose

• 特徴: ストリーミングデータを他のサービス（S3, Redshift, OpenSearch Service, Splunk, Datadogなど）に配送するサービス。
• メリット:
  • DatadogやSplunkなどのサードパーティ製監視ツールに直接ログを流し込める。
  • Lambda関数を挟んでデータ変換も可能（不要なフィールドの削除など）。
• コスト: データ転送 $0.029/GB（最初の500TB/月）+ 転送先サービスの料金
• 注意点: ストリーミングの機能であり、ログ保管コストはログ保存先に依存します。

AWS WAFの導入・運用代行に関するご相談はこちら！

3. ユースケース別：最適な出力先の選び方

それぞれの特徴を踏まえた「選び方」のガイドラインは以下の通りです。

ケース1: 「とりあえずログを見れるようにしたい、調査も楽にしたい」 →CloudWatch Logs が正解

多少コストはかかりますが、Logs Insightsの分析のしやすさは運用負荷を劇的に下げてくれます。アクセス数がそれほど多くない立ち上げ当初の（またはコストが許容できる）場合は、まずこれを検討してください。

ケース2: 「今は分析しないが、コンプライアンス要件で長期保存しておきたい」 → S3 が正解

「念のため保存」レベルであれば、S3に入れておくのが最も安上がりです。必要になった時だけAthenaで検索すればOKです。必要時のみAthenaを実行する運用であれば、コストも数ドル程度で済みます。

ケース3: 「既にDatadogやSplunkで監視基盤がある」 →Data Firehoseが正解

既存の監視フローに統合することで、WAFログを一元管理できます。CloudWatchやS3を経由せず、WAFから直接Datadogへストリーム配信されるため、リアルタイム性の高いシステムを構築することができます。

AWS WAFの導入・運用代行に関するご相談はこちら！

4. コスト最適化を考慮した設定ハンズオン

4-1. ハイブリッド構成の設計

それでは、上記でご紹介したケースを踏まえ、コスト最適化を考慮したハイブリッドな設計を考えてみます。WAFログをCloudWatch Logsに出力（保持期間7日）し、合わせてS3バケットを長期保存用のアーカイブ先とすることで、リアルタイム性と低コストを両立した運用をめざしていきたいと思います。

4-2. Step 1: 宛先リソースの確認

まず、ログの出力先となる ロググループを作成します。ここで重要なポイントがあります。 AWS WAFのログ出力先として指定するためには、リソース名（ロググループ名/バケット名）が aws-waf-logs- で始まっている必要があります。

• ロググループ名の例: aws-waf-logs-my-web-acl
• (S3への直接出力の場合)バケット名の例: aws-waf-logs-archive-2024

4-3. Step 2: CloudWatch Logsへの出力設定

設定手順

1. 「CloudWatch」 → 「ログ管理」 → 「ロググループを作成」をクリックし、上記命名規則に従ったロググループを作成します。

2. 保持期間を「7日間」に設定してコストを最適化します。

3. AWS WAFのマネジメントコンソールで、対象のWeb ACLを開きます。

4. 「保護パック（ウェブACL）」→ [当該WAF名] に遷移します。

5. 右側のペインから「ログ記録とサンプルリクエストを設定」をクリックします。

6. 「ログ記録」から「有効化」→「ログ記録送信先」をクリックします。

7. 「Amazon CloudWatch Logs ロググループ」から先ほど作ったロググループを指定します。

8. ステータスが有効になっていれば完了です。

9. ログが出力されているかを確認するには、CloudWatchのページへ移動し、作成されているログストリームへ遷移します。

10. 任意でインサイトを得るため、「Logs Insightsで表示」から、便利なクエリ検索が利用できます。

4-4. Step 3: S3への長期保存設定

続いてS3設定を実施します。

1. エクスポート先のS3バケットを作成します。

2. 作成したバケットのライフサイクルを任意で設定します

(例)

30日後: Standard-IA（低頻度アクセス）へ移行

90日後: Glacier Flexible Retrievalへ移行

365日後: 削除（または Glacier Deep Archive）

3. 次に、CloudWatch LogsからS3へエクスポートするためのバケットポリシーを追加します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "logs.us-east-1.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::aws-waf-logs-s3-xxxxxx",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "xxxxxxxxxxxx"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:logs:us-east-1:xxxxxxxxxxxx:log-group:aws-waf-logs-xxxxx:*"
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "logs.us-east-1.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::aws-waf-logs-s3-xxxxxx/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control",
                    "aws:SourceAccount": " xxxxxxxxxxxx "
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:logs:us-east-1: xxxxxxxxxxxx:log-group:aws-waf-logs-xxxxx:*"
                }
            }
        }
    ]
}

4. 次に、CloudWatch Logsのエクスポート処理を呼び出すためのLambda用IAMロールを作成します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "logs:CreateLogGroup",
            "Resource": "arn:aws:logs:us-east-1:xxxxxxxxxxxx:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:xxxxxxxxxxxx:log-group:/aws/lambda/ CloudWatchLogExport:*"
            ]
        }
    ]
}

5. Lambda関数を作成します。

  import boto3
import os
from datetime import datetime, timedelta

logs = boto3.client('logs')

def lambda_handler(event, context):
    # 1. 環境変数の取得
    GROUP_NAME = os.environ['LOG_GROUP_NAME']
    BUCKET_NAME = os.environ['DESTINATION_BUCKET']
    
    # 2. ログの対象期間（昨日）を計算
    today = datetime.now().replace(hour=0, minute=0, second=0, microsecond=0)
    yesterday = today - timedelta(days=1)
    
    # 3. 【ここがポイント】実行した「今の時間」を名前に組み込む
    # 例: 20260224_193005 (2026年2月24日 19時30分05秒)
    now_str = datetime.now().strftime('%Y%m%d_%H%M%S')
    
    # S3のフォルダ名を「ログの日付/実行時間」という階層にする
    # 例: exported-logs/2026-02-23/run_193005
    custom_prefix = f"exported-logs/{yesterday.strftime('%Y-%m-%d')}/run_{now_str}"

    try:
        response = logs.create_export_task(
            # コンソール上で見分けやすくするための名前
            taskName      = f"test-export_{now_str}",
            logGroupName  = GROUP_NAME,
            fromTime      = int(yesterday.timestamp() * 1000),
            to            = int(today.timestamp() * 1000),
            destination   = BUCKET_NAME,
            # S3上の保存先フォルダパス
            destinationPrefix = custom_prefix
        )
        print(f"New Task Created: {response['taskId']}")
        print(f"Check S3 Folder: {custom_prefix}")
        return "OK"

    except Exception as e:
        print(f"Error: {str(e)}")
        raise e

6. Lambdaの環境変数を設定します

• LOG_GROUP_NAME : WAFのロググループ名
• DESTINATION_BUCKET : ステップ1で作成したS3バケット名
• TZ：Asia/Tokyo

7. 次にLambdaを定期実行するためのスケジュールを設定します。

「設定」→「トリガー」→「トリガーを追加」→「EventBridge (CloudWatch Events)」を設定

Sculedule Expression: cron(5 15 * * ?*)

以上で準備は完了です。

4-5. Step 4: 動作確認

1. CloudWatch LogsからS3格納のためのバケットポリシーの正当性を確認するため、まずは手動でエクスポートを実施してください。

2. ステータスが問題ないことを確認します。

3. 次に、作成したLambdaのテストを実施します。

4. 結果はログから確認できます。

5. 最後にEventBridgeの実行を待って、当該時刻のS3バケット上にオブジェクトが格納されていることを実際に確認できたら完了です。

AWS WAFの導入・運用代行に関するご相談はこちら！

5. まとめ：自社環境に合ったログ設計を

AWS WAFのログ管理は、「コスト」「検索性」「リアルタイム性」のトレードオフを理解し、自社のニーズに合わせた構成を選定することが重要です。 迷ったら、まずは CloudWatch Logs で7日保存から始め、余力があればS3連携で長期保存 のハイブリッド構成から始めることをおすすめします。運用しながらコストと使い勝手を見極め、最適化していくのが現実的なアプローチです。

AWS WAFの導入・運用代行に関するご相談はこちら！

• Amazon Web Services（AWS）およびその他のAWS 商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。