CloudFront WAF モニタリング・アラート設計書（Datadog）

バージョン: 1.0 最終更新日: 2026-03-19 担当チーム: SRE ステータス: Draft

概要

目的

本ドキュメントは、fastdoctor.jp の CloudFront Distribution に適用される AWS WAF のモニタリングとアラートを Datadog で実装するための設計書です。

主な目的:

WAF のブロック/カウント動作をリアルタイムで可視化
攻撃パターンの早期検出と対応
誤検知（False Positive）の迅速な発見と除外設定
CloudFront のエラー率異常の検知
SRE チームへの効果的なアラート通知

スコープ

対象環境:

本番環境: fastdoctor.jp (Production CloudFront Distribution + WAF Web ACL)
ステージング環境: test.fastdoctor.jp (Staging CloudFront Distribution + WAF Web ACL)
開発環境: infra-dev 環境（必要に応じて）

対象リソース:

AWS WAF v2 Web ACL（CloudFront スコープ）
CloudFront Distribution
Kinesis Data Firehose（WAF ログ）
Datadog Logs, Metrics, Monitors, Dashboards

モニタリング方針

基本方針

メトリクスとログの統合監視:
- CloudWatch メトリクス（WAF、CloudFront）を Datadog AWS 統合で収集
- WAF ログを Kinesis Firehose 経由で Datadog に転送
- 同一ダッシュボードでメトリクスとログを相関分析
- 注: CloudFront Real-time Logs による詳細なエラーログ分析は別PR・別ドキュメントで検討
段階的なアラート設定:
- Phase 1（COUNT モード）: アラートは情報通知レベル（Slack 通知のみ、緊急度低）
- Phase 2（BLOCK モード）: アラート強度を上げ、誤検知監視を重点化
- Phase 3（追加ルール）: 新規ルールごとに個別アラート設定
誤検知検出の優先:
- 正規ユーザーのブロックを最優先で検出
- BLOCK されたリクエストの User-Agent、IP、URI パターンを自動分析
- 異常なブロック増加時は即座に Slack 通知
コスト最適化:
- 疎通検証期間（1週間）は別 Datadog アカウントを使用し、ログ量を正確に見積もり
- 本番切り替え後、ログ保持期間を適切に設定（例: 30日）してコストを管理

Datadog アカウント戦略

期間	Datadog アカウント	目的
疎通検証期間（約1週間）	検証用アカウント（別アカウント）	プロダクト系ログ量変動の影響を受けず、WAF ログ量を正確に見積もり
本番運用開始後	本番アカウント	既存の監視基盤と統合し、SRE チームの運用フローに組み込む

メトリクス監視

前提条件: メトリクス監視の設定

WAF Web ACL の visibility_config 設定（必須）

WAF の各ルールで cloudwatch_metrics_enabled = true を設定する必要があります。これが設定されていないと、CloudWatch にメトリクスが送信されず、Datadog AWS 統合でメトリクスを取得できません。

Terraform 設定例

hcl

resource "aws_wafv2_web_acl" "fastdoctor_jp" {
  name  = "fastdoctor-jp-cloudfront-waf"
  scope = "CLOUDFRONT"

  # Web ACL レベルの visibility_config（必須）
  visibility_config {
    cloudwatch_metrics_enabled = true  # CloudWatch メトリクス有効化
    metric_name                = "fastdoctor-jp-waf"
    sampled_requests_enabled   = true  # サンプルリクエスト記録
  }

  # 各ルールにも visibility_config が必要
  rule {
    name     = "force-allow-ip-list"
    priority = -4

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "force-allow-ip-list"
      sampled_requests_enabled   = true
    }

    statement {
      ip_set_reference_statement {
        arn = aws_wafv2_ip_set.force_allow_ipv4.arn
      }
    }

    action {
      allow {}
    }
  }

  rule {
    name     = "core-rule-set"
    priority = 10

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "core-rule-set"
      sampled_requests_enabled   = true
    }

    override_action {
      count {}  # Phase 1 では count モード
    }

    statement {
      managed_rule_group_statement {
        vendor_name = "AWS"
        name        = "AWSManagedRulesCommonRuleSet"
        version     = "Version_1.12"
      }
    }
  }
}

コスト: 無料（WAF の基本料金に含まれる）

CloudFront: デフォルトメトリクスと拡張メトリクス（Phase 1/2で有効化）

CloudFrontには**デフォルトメトリクス（無料、自動有効）と拡張メトリクス（有料、手動有効化）**があります。

重要: Phase 1/2では拡張メトリクスを有効化します。エラー状況の詳細把握のため、ステータスコード別エラー率が必須です。

デフォルトメトリクス（無料、自動有効、設定不要）:

Requests（リクエスト数）
BytesDownloaded / BytesUploaded
4xxErrorRate / 5xxErrorRate（全体のエラー率）
TotalErrorRate（総エラー率）

拡張メトリクス（Phase 1/2で有効化、$1.80/月）:

Phase 1/2で有効化するメトリクス - ステータスコード別エラー率（401, 403, 404, 502, 503, 504）: 6メトリクス

401ErrorRate: 認証エラー率
403ErrorRate: 権限エラー率
404ErrorRate: Not Foundエラー率
502ErrorRate: Bad Gatewayエラー率（オリジン接続問題）
503ErrorRate: Service Unavailableエラー率（オリジン過負荷）
504ErrorRate: Gateway Timeoutエラー率（オリジンタイムアウト）

コスト: 6メトリクス × $0.30 = $1.80/Distribution/月

注: 拡張メトリクスは有効化すると最大8メトリクス（CacheHitRate, OriginLatency含む）が収集されますが、本構成ではステータスコード別エラー率（6メトリクス）のみをDatadog Monitorsで使用します。

Datadog で監視する主要メトリクス

WAF メトリクス（`aws.wafv2.*`）

メトリクス名	説明	用途
`aws.wafv2.allowed_requests`	許可されたリクエスト数	正常トラフィックの傾向分析
`aws.wafv2.blocked_requests`	ブロックされたリクエスト数	攻撃検知、誤検知監視
`aws.wafv2.counted_requests`	COUNT モードでマッチしたリクエスト数	Phase 1 での動作確認、除外候補の特定
`aws.wafv2.captcha_requests`	CAPTCHA を発行したリクエスト数	Bot 検証の効果測定（Phase 3 以降）

タグ:

rule: ルール名（core-rule-set, ip-reputation-list など）
webacl: Web ACL 名（fastdoctor-jp-cloudfront-waf）
region: us-east-1（CloudFront は常に us-east-1）

CloudFront メトリクス（`aws.cloudfront.*`）

デフォルトメトリクス（無料）:

メトリクス名	説明	用途
`aws.cloudfront.requests`	リクエスト総数	トラフィック傾向、異常検知
`aws.cloudfront.4xx_error_rate`	4xx エラー率（%）	クライアントエラー監視（アノマリー検知）
`aws.cloudfront.5xx_error_rate`	5xx エラー率（%）	オリジンエラー監視（閾値アラート）
`aws.cloudfront.total_error_rate`	総エラー率（%）	全体エラー監視
`aws.cloudfront.bytes_downloaded`	ダウンロードバイト数	帯域幅監視
`aws.cloudfront.bytes_uploaded`	アップロードバイト数	帯域幅監視

拡張メトリクス（Phase 1/2で有効化、$1.80/月）:

メトリクス名	説明	用途
`aws.cloudfront.401_error_rate`	401 エラー率（%）	認証エラー監視
`aws.cloudfront.403_error_rate`	403 エラー率（%）	権限エラー監視
`aws.cloudfront.404_error_rate`	404 エラー率（%）	Not Foundエラー監視
`aws.cloudfront.502_error_rate`	502 エラー率（%）	Bad Gatewayエラー監視（オリジン接続問題）
`aws.cloudfront.503_error_rate`	503 エラー率（%）	Service Unavailableエラー監視（オリジン過負荷）
`aws.cloudfront.504_error_rate`	504 エラー率（%）	Gateway Timeoutエラー監視（オリジンタイムアウト）

タグ:

distributionid: CloudFront Distribution ID

ログ監視

WAF ログ

ログソース: source:waf

主要フィールド:

フィールド名	説明	値例
`action`	WAF の最終アクション	`ALLOW`, `BLOCK`, `COUNT`
`terminatingRuleId`	マッチした最終ルール ID	`Default_Action`, `core-rule-set`
`terminatingRuleType`	ルールタイプ	`MANAGED`, `REGULAR`, `RATE_BASED`
`httpRequest.clientIp`	クライアント IP アドレス	`203.0.113.42`
`httpRequest.uri`	リクエスト URI	`/api/users`
`httpRequest.httpMethod`	HTTP メソッド	`GET`, `POST`
`httpRequest.headers`	リクエストヘッダ（User-Agent など）	配列
`ruleGroupList`	マッチしたルールグループのリスト	配列（COUNT ルールを含む）
`labels`	WAF Labels（カスタムタグ）	`awswaf:managed:aws:core-rule-set:...`

Datadog Logs Pipeline

親パイプライン: AWS Web Application Firewall

フィルタ: source:waf

プロセッサ:

Grok Parser: JSON パース
Date Remapper: timestamp フィールドを公式タイムスタンプに設定
Status Remapper: action フィールドをステータスに設定
- ALLOW → info
- BLOCK → error
- COUNT → warn
Category Processor: action でカテゴリ分け

ネストパイプライン 1: COUNT ログ

フィルタ: @action:COUNT

プロセッサ:

Array Processor: ruleGroupList 配列を展開
- ターゲット属性: ruleGroupList
- プロセッサ:
  - Grok Parser でルール ID を抽出
  - Tag Remapper で waf_count_rule:<rule_id> タグを追加

目的: COUNT モードでマッチしたルールを個別タグで検索可能にする

ネストパイプライン 2: BLOCK ログ

フィルタ: @action:BLOCK

プロセッサ:

Grok Parser: User-Agent を抽出
- パターン: User-Agent: %{data:http.useragent}
Tag Remapper:
- waf_rule:<terminatingRuleId> タグを追加
- http.status_code:<statusCode> タグを追加

目的: ブロックされたリクエストの User-Agent、ルール、ステータスコードで分析

アラート定義

アラート優先度

優先度	重大度	通知先	対応時間
P1（緊急）	Critical	Slack (#sre-alert) + PagerDuty	即座（15分以内）
P2（高）	High	Slack (#sre-alert)	1時間以内
P3（中）	Medium	Slack (#sre-monitoring)	営業時間内対応
P4（低）	Low	Slack (#sre-monitoring)	週次レビュー

Phase 1（COUNT モード）のアラート

以下の3つのモニターを Datadog Logs ベースで作成する。Terraform で管理（datadog/services/waf/）。

ディレクトリを waf にした理由:

既存の datadog/services/ は各サービス名でディレクトリを切っている
WAF モニタリングは特定サービスではなくインフラ横断の監視であり、fastdoctor.jp / test.fastdoctor.jp 等の複数ドメインを対象とする
サービス名（例: fastdoctor-jp）にすると、ドメイン追加時にサービスごとにモニターを作成する必要がある
waf にまとめて waf_host タグで group by することで、ドメインが増えても1つのモニター定義で対応可能

定義方針:

モニターテンプレートは datadog/services/waf/<env>/monitor/*.tftpl に配置
モジュールは datadog/service_modules/waf/monitoring/ で共通化
全モニターで waf_host を group by に含め、ドメインごとにアラートが分離される

1. ルール別 COUNT 集中アラート

目的: 特定のルールで大量の COUNT が発生している場合、攻撃または誤検知の可能性を検知

設定:

優先度: P3（Medium）
通知先: Slack
group by: waf_rule, waf_host（ルール × ドメインごとにアラート発火）

2. 同一 IP の COUNT 急増アラート

目的: 同一IPからの大量リクエストを検知（スキャンボット、クローラー、DoS攻撃）

設定:

優先度: P3（Medium）
通知先: Slack
group by: @network.client.ip, waf_host（IP × ドメインごとにアラート発火）

3. 同一 UA の COUNT 急増アラート

目的: 同一User-Agentからの大量リクエストを検知（ボット、クローラー）

設定:

優先度: P3（Medium）
通知先: Slack
group by: @waf_useragent, waf_host（UA × ドメインごとにアラート発火）

閾値: Terraform の変数で管理（datadog/services/waf/<env>/variable.tf）。運用しながら調整する。

BLOCK モード化時のアラート

マネージドルールを count → block に変更する際に、該当ルールの誤検知監視として BLOCK 急増モニターを追加する。

常時の BLOCK 件数監視は不要（ip-blacklist、ua-blacklist 等の既知ブロックで常に発火するため）。

追加タイミングと設定

ルールの block 化時に以下のモニターを追加：

logs("source:waf waf_action:block waf_rule:<block化したルール名>").index("*").rollup("count").by("waf_rule,waf_host").last("10m") > <閾値>

設定:

優先度: P2（High）
通知先: Slack
目的: block 化直後の誤検知を早期検出
運用: block 化後1〜2週間は重点監視。安定したらアラート閾値を調整または無効化

CloudFront エラー率アラート

6. 4xx エラー率異常アラート（アノマリー検知）

目的: favicon やクローラの常時 404 を考慮し、変動ベースで監視

条件:

anomaly(avg:aws.cloudfront.4xx_error_rate{distributionid:XXXXXXXXXXXX}, 'basic', 2)

設定:

優先度: P3（Medium）
通知先: Slack (#sre-monitoring)
アノマリー検知パラメータ:
- アルゴリズム: basic
- 感度: 2（中程度、過去7日間の平均と比較して±20%以上の変動で発火）

メッセージ:

[CloudFront] 4xx エラー率が通常と異なるパターンを示しています

現在のエラー率: {{value}}%

過去7日間の平均と比較して異常な変動が検出されました。
以下を確認してください:
- 新しいページやリソースが削除されていないか
- アプリケーションのデプロイで URI パターンが変更されていないか
- 特定の User-Agent からの404が増加していないか

ログ確認:
https://app.datadoghq.com/logs?query=source%3Acloudfront%20%40sc-status%3A%5B400%20TO%20499%5D

注意事項（コーポレートサイト特有）:

PR発表時・決算発表時: プレスリリースや決算情報公開直後は、アクセス数が急増し、DoS 攻撃に似た正常なトラフィックパターンが発生することがあります
アノマリー検知が誤検知する可能性があるため、事前に SRE チームに共有し、一時的にアラートを無効化またはモニタリングのみに切り替えることを検討

7. 5xx エラー率アラート（絶対値監視）

目的: オリジンサーバーの異常を即座に検出

条件:

avg(last_5m):avg:aws.cloudfront.5xx_error_rate{distributionid:XXXXXXXXXXXX} > 1

設定:

優先度: P1（Critical）
通知先: Slack (#sre-alert) + PagerDuty

メッセージ:

[CloudFront] 5xx エラー率が 1% を超えています（オリジン異常の可能性）

現在のエラー率: {{value}}%

即座に以下を確認してください:
- オリジンサーバー（ECS/ALB/etc）の健全性
- データベースの接続状態
- 最近のデプロイやインフラ変更

ログ確認:
https://app.datadoghq.com/logs?query=source%3Acloudfront%20%40sc-status%3A%5B500%20TO%20599%5D

今後の検討課題: DDoS 検知（リクエスト総数アノマリー）

目的: リクエスト総数の異常な増加から DDoS 攻撃を検知。攻撃パターンを持たない単純な HTTP Flood（正常なGETリクエストの大量送信）は WAF ログに記録されないため、別の方法で検知が必要。

根拠: AWS DDoS Resiliency Whitepaper および AWS Solutions で AllowedRequests のアノマリー検知が推奨されている。

現時点で導入しない理由:

fastdoctor.jp の CloudFront 配下には LP、コーポレートサイト、医療情報ページ等が混在しており、サイトによってリクエストパターンが大きく異なる
WAF 単位（webacl）のアノマリー検知では、サイトごとの正常なトラフィック変動と攻撃を区別しづらい
CloudFront のリクエスト数でサイト単位に監視する方が精度が高い

今後の対応方針:

CloudFront リアルタイムログ導入（#10381）と合わせて、サイト単位の DDoS 検知を検討する

Rate Limiting アラート（Phase 3 以降）

8. Rate Limiting 発動アラート

目的: DoS 攻撃または正規ユーザーの誤検知を検出

条件:

avg(last_5m):sum:aws.wafv2.blocked_requests{webacl:fastdoctor-jp-cloudfront-waf,rule:rate-limiting-global} > 50

設定:

優先度: P2（High）
通知先: Slack (#sre-alert)
注意事項（コーポレートサイト特有）:
- PR 発表時・決算発表時は正規ユーザーからの短時間集中アクセスが発生する可能性
- 事前に分かっている場合は、一時的に Rate Limiting ルールを無効化または閾値を緩和
注意事項（静的ファイルとキャリアNAT）:
- fastdoctor.jp の LP は1ページ読み込みで200リクエスト以上（JS/CSS/フォント/画像等）が発生する
- 携帯キャリアや一部プロバイダではプロバイダ単位の NAT により、多数のユーザーが同一IPで見える
- IP ベースの Rate Limiting を導入する場合、静的ファイル（.js, .css, .woff2, .png, .svg 等）を scope-down statement で評価対象から除外するか、閾値を大幅に引き上げる必要がある

ダッシュボード設計

ダッシュボード 1: WAF Overview

目的: WAF 全体の動作状況を一目で把握

ウィジェット構成:

トップ行: Key Metrics（Timeseries）
- aws.wafv2.allowed_requests（緑）
- aws.wafv2.blocked_requests（赤）
- aws.wafv2.counted_requests（黄）
2行目: ルール別 BLOCK 数（Toplist）
- クエリ: sum:aws.wafv2.blocked_requests{*} by {rule}
- ソート: 降順
- 目的: どのルールでブロックが多いか把握
3行目: ルール別 COUNT 数（Toplist）
- クエリ: sum:aws.wafv2.counted_requests{*} by {rule}
- ソート: 降順
- 目的: Phase 1 での除外候補を特定
4行目: CloudFront エラー率（Timeseries）
- aws.cloudfront.4xx_error_rate（オレンジ）
- aws.cloudfront.5xx_error_rate（赤）
5行目: 最近の BLOCK ログ（Log Stream）
- クエリ: source:waf @action:BLOCK
- 表示フィールド: timestamp, httpRequest.clientIp, httpRequest.uri, terminatingRuleId, httpRequest.headers.User-Agent
- 目的: ブロックされたリクエストの詳細を即座に確認
6行目: 最近の COUNT ログ（Log Stream）
- クエリ: source:waf @action:COUNT
- 表示フィールド: 同上
- 目的: COUNT モードでマッチしたリクエストの詳細を確認

ダッシュボード 2: WAF Attack Analysis

目的: 攻撃パターンの詳細分析

ウィジェット構成:

トップ行: ブロックされた IP Top 10（Toplist）
- ログクエリ: source:waf @action:BLOCK | top httpRequest.clientIp by count
2行目: ブロックされた User-Agent Top 10（Toplist）
- ログクエリ: source:waf @action:BLOCK | top httpRequest.headers.User-Agent by count
3行目: ブロックされた URI Top 10（Toplist）
- ログクエリ: source:waf @action:BLOCK | top httpRequest.uri by count
4行目: ブロックされたリクエストの地理分布（Geomap）
- メトリクス: aws.wafv2.blocked_requests by country（要カスタムタグ設定）
5行目: Labels 分析（Toplist）
- ログクエリ: source:waf @action:BLOCK | top labels by count
- 目的: どの AWS Managed Rule でブロックされているか把握

ダッシュボード 3: CloudFront Performance & Errors

目的: CloudFront のパフォーマンスとエラーの詳細分析

ウィジェット構成:

トップ行: リクエスト数とエラー率（Timeseries）
- aws.cloudfront.requests（青）
- aws.cloudfront.4xx_error_rate（オレンジ）
- aws.cloudfront.5xx_error_rate（赤）
2行目: 4xx エラーのステータスコード別内訳（Timeseries）
- aws.cloudfront.401_error_rate（黄色）
- aws.cloudfront.403_error_rate（オレンジ）
- aws.cloudfront.404_error_rate（赤）
- 目的: クライアントエラーの詳細分析（拡張メトリクス）
3行目: 5xx エラーのステータスコード別内訳（Timeseries）
- aws.cloudfront.502_error_rate（オレンジ）
- aws.cloudfront.503_error_rate（赤）
- aws.cloudfront.504_error_rate（濃い赤）
- 目的: オリジンエラーの詳細分析（拡張メトリクス）
4行目: エラー率の比較（Toplist）
- メトリクス: 全エラー率メトリクスのランキング表示
- ソート: 降順（エラー率が高い順）
- 目的: 最も問題となっているエラータイプを即座に特定

通知設定とエスカレーション

Slack 通知チャンネル

チャンネル	用途	アラート優先度
`#sre-alert`	緊急・高優先度アラート	P1（Critical）、P2（High）
`#sre-monitoring`	中・低優先度アラート、情報通知	P3（Medium）、P4（Low）
`#sre-waf-phase1`	Phase 1 専用（COUNT モード検証）	Phase 1 のみ、検証終了後削除

PagerDuty 設定

対象アラート: P1（Critical）のみ

エスカレーションポリシー:

1次対応: オンコール SRE（即座）
2次対応: SRE リーダー（15分後）
3次対応: SRE マネージャー（30分後）

対象モニタ:

5xx エラー率 > 1%
（Phase 3 以降）Rate Limiting 大量発動

通知メッセージテンプレート

各アラートには以下の情報を含める:

タイトル: [WAF Phase X] <アラート内容>
現在の値:
ログ確認リンク: Datadog Logs の該当クエリへの直接リンク
次のアクション: 対応手順のチェックリスト
関連ドキュメント: 運用設計書、手順書へのリンク

実装手順

Step 1: 前提条件の確認

[ ] WAF Web ACL の各ルールで visibility_config.cloudwatch_metrics_enabled = true が設定されている
[ ] Datadog AWS 統合が有効化されている
[ ] CloudWatch メトリクスの収集権限が Datadog IAM Role に付与されている
[ ] Kinesis Data Firehose が Datadog に WAF ログを転送している
[ ] CloudFront デフォルトメトリクス（4xxErrorRate, 5xxErrorRate）が Datadog に収集されている
[ ] CloudFront 拡張メトリクス（ステータスコード別エラー率：401/403/404/502/503/504）が有効化され、Datadog に収集されている

Step 2: Datadog Logs Pipeline の構築

親パイプライン作成:
- Datadog UI > Logs > Configuration > Pipelines
- "Create Pipeline" をクリック
- フィルタ: source:waf
- プロセッサ追加: Grok Parser, Date Remapper, Status Remapper, Category Processor
ネストパイプライン作成（COUNT ログ）:
- 親パイプライン内で "Add Nested Pipeline" をクリック
- フィルタ: @action:COUNT
- Array Processor 追加: ruleGroupList を展開
ネストパイプライン作成（BLOCK ログ）:
- フィルタ: @action:BLOCK
- Grok Parser で User-Agent を抽出
- Tag Remapper でタグ追加

Step 3: Datadog Monitors の作成

Phase 1 用のモニタから順次作成:

COUNT リクエスト急増アラート
特定ルールの COUNT 集中アラート（ルールごと）

Phase 2 移行時に追加:

BLOCK リクエスト急増アラート
特定ルールの BLOCK 集中アラート
IP Reputation List ブロックアラート

CloudFront エラー監視:

4xx エラー率異常アラート（アノマリー検知）
5xx エラー率アラート（絶対値監視）

Step 4: Datadog Dashboards の作成

WAF Overview ダッシュボード: テンプレートをインポートまたは手動作成
WAF Attack Analysis ダッシュボード: 攻撃分析用
CloudFront Performance & Errors ダッシュボード: パフォーマンス監視用

Step 5: Slack 通知設定

Datadog と Slack を連携（Datadog Integrations > Slack）
#sre-alert, #sre-monitoring, #sre-waf-phase1 チャンネルを Datadog に追加
各モニタの通知先を設定

Step 6: PagerDuty 設定（P1 アラートのみ）

Datadog と PagerDuty を連携
エスカレーションポリシーを設定
5xx エラー率アラートに PagerDuty 通知を追加

Step 7: 疎通検証（検証用 Datadog アカウント）

検証用 Datadog アカウントで上記 Step 2〜6 を実施
1週間運用し、ログ量、アラート発火頻度、誤検知の有無を確認
ログ量を正確に見積もり、コストを算出

Step 8: 本番 Datadog アカウントへの移行

検証完了後、本番 Datadog アカウントで Step 2〜6 を再実施
Kinesis Firehose の送信先を本番 Datadog アカウントに変更
検証用アカウントのリソースを削除

運用とメンテナンス

日次運用

ダッシュボード確認: 毎朝 WAF Overview ダッシュボードを確認し、異常がないかチェック
アラート対応: Slack 通知に従い、ログを確認して誤検知の有無を判断

週次運用

傾向分析:
- WAF Attack Analysis ダッシュボードでブロックされた IP、User-Agent、URI の傾向を分析
- 繰り返しブロックされている IP は IP Blacklist への追加を検討
- 繰り返しブロックされている User-Agent は UA Blacklist への追加を検討
誤検知レビュー:
- 過去1週間の BLOCK ログを確認し、正規ユーザーがブロックされていないかレビュー
- 誤検知が確認された場合は除外設定を実施

月次運用

コスト確認:
- Datadog のログ取り込み量、インデックス量を確認
- 必要に応じてログ保持期間、除外フィルタを調整
モニタのチューニング:
- 誤検知が多いモニタは閾値を調整
- 新しい攻撃パターンが検出された場合は新規モニタを追加

Phase 移行時の運用

Phase 1 → Phase 2 移行時

COUNT モード用のモニタ（優先度 P3/P4）を削除または無効化
BLOCK モード用のモニタ（優先度 P2）を有効化
#sre-waf-phase1 チャンネルを削除

Phase 2 → Phase 3 移行時

新規追加ルール（Rate Limiting、Bot Control など）用のモニタを追加

ドキュメントメンテナンス

アラート閾値を変更した場合は本ドキュメントを更新
新規モニタを追加した場合は本ドキュメントに記載
誤検知対応の知見は運用設計書に蓄積

参考資料

Datadog ドキュメント

AWS ドキュメント

内部ドキュメント

CloudFront WAF アーキテクチャ設計書
CloudFront WAF 運用設計書
CloudFront WAF 運用手順書: aws/service-guides/waf-operation-guide.md（未作成）

変更履歴

日付	バージョン	変更内容	担当チーム	担当者
2026-03-19	1.2	CloudFront拡張メトリクス（ステータスコード別エラー率：401/403/404/502/503/504）をPhase 1/2で有効化する方針に変更（$1.80/月）。CacheHitRate/OriginLatencyは検討対象外として削除。CloudFront Performance & Errorsダッシュボードにステータスコード別エラー率の可視化を追加	SRE	大賀
2026-03-19	1.1	CloudFront Real-time Logsを別PR・別ドキュメントとして分離。CloudFront 4xx/5xxエラー監視をデフォルトメトリクスで実施する方針に変更。「追加メトリクス」を「拡張メトリクス」に用語統一。メトリクス監視の前提条件の見出しを「メトリクス監視の設定」に修正	SRE	大賀
2026-03-19	1.0	初版作成。WAF メトリクス・ログ監視、アラート定義、ダッシュボード設計、通知設定を記載	SRE	大賀

CloudFront WAF モニタリング・アラート設計書（Datadog） ​

目次 ​

概要 ​

目的 ​

スコープ ​

モニタリング方針 ​

基本方針 ​

Datadog アカウント戦略 ​

メトリクス監視 ​

前提条件: メトリクス監視の設定 ​

WAF Web ACL の visibility_config 設定（必須） ​

CloudFront: デフォルトメトリクスと拡張メトリクス（Phase 1/2で有効化） ​

Datadog で監視する主要メトリクス ​

WAF メトリクス（aws.wafv2.*） ​

CloudFront メトリクス（aws.cloudfront.*） ​

ログ監視 ​

WAF ログ ​

Datadog Logs Pipeline ​

親パイプライン: AWS Web Application Firewall ​

ネストパイプライン 1: COUNT ログ ​

ネストパイプライン 2: BLOCK ログ ​

アラート定義 ​

アラート優先度 ​

Phase 1（COUNT モード）のアラート ​

1. ルール別 COUNT 集中アラート ​

2. 同一 IP の COUNT 急増アラート ​

3. 同一 UA の COUNT 急増アラート ​

BLOCK モード化時のアラート ​

追加タイミングと設定 ​

CloudFront エラー率アラート ​

6. 4xx エラー率異常アラート（アノマリー検知） ​

7. 5xx エラー率アラート（絶対値監視） ​

今後の検討課題: DDoS 検知（リクエスト総数アノマリー） ​

Rate Limiting アラート（Phase 3 以降） ​

8. Rate Limiting 発動アラート ​

ダッシュボード設計 ​

ダッシュボード 1: WAF Overview ​

ダッシュボード 2: WAF Attack Analysis ​

ダッシュボード 3: CloudFront Performance & Errors ​

通知設定とエスカレーション ​

Slack 通知チャンネル ​

PagerDuty 設定 ​

通知メッセージテンプレート ​

実装手順 ​

Step 1: 前提条件の確認 ​

Step 2: Datadog Logs Pipeline の構築 ​

Step 3: Datadog Monitors の作成 ​

Step 4: Datadog Dashboards の作成 ​

Step 5: Slack 通知設定 ​

Step 6: PagerDuty 設定（P1 アラートのみ） ​

Step 7: 疎通検証（検証用 Datadog アカウント） ​

Step 8: 本番 Datadog アカウントへの移行 ​

運用とメンテナンス ​

日次運用 ​

週次運用 ​

月次運用 ​

Phase 移行時の運用 ​

Phase 1 → Phase 2 移行時 ​

Phase 2 → Phase 3 移行時 ​

ドキュメントメンテナンス ​

参考資料 ​

Datadog ドキュメント ​

AWS ドキュメント ​

内部ドキュメント ​

変更履歴 ​

CloudFront WAF モニタリング・アラート設計書（Datadog）

目次

概要

目的

スコープ

モニタリング方針

基本方針

Datadog アカウント戦略

メトリクス監視

前提条件: メトリクス監視の設定

WAF Web ACL の visibility_config 設定（必須）

CloudFront: デフォルトメトリクスと拡張メトリクス（Phase 1/2で有効化）

Datadog で監視する主要メトリクス

WAF メトリクス（`aws.wafv2.*`）

CloudFront メトリクス（`aws.cloudfront.*`）

ログ監視

WAF ログ

Datadog Logs Pipeline

親パイプライン: AWS Web Application Firewall

ネストパイプライン 1: COUNT ログ

ネストパイプライン 2: BLOCK ログ

アラート定義

アラート優先度

Phase 1（COUNT モード）のアラート

1. ルール別 COUNT 集中アラート

2. 同一 IP の COUNT 急増アラート

3. 同一 UA の COUNT 急増アラート

BLOCK モード化時のアラート

追加タイミングと設定

CloudFront エラー率アラート

6. 4xx エラー率異常アラート（アノマリー検知）

7. 5xx エラー率アラート（絶対値監視）

今後の検討課題: DDoS 検知（リクエスト総数アノマリー）

Rate Limiting アラート（Phase 3 以降）

8. Rate Limiting 発動アラート

ダッシュボード設計

ダッシュボード 1: WAF Overview

ダッシュボード 2: WAF Attack Analysis

ダッシュボード 3: CloudFront Performance & Errors

通知設定とエスカレーション

Slack 通知チャンネル

PagerDuty 設定

通知メッセージテンプレート

実装手順

Step 1: 前提条件の確認

Step 2: Datadog Logs Pipeline の構築

Step 3: Datadog Monitors の作成

Step 4: Datadog Dashboards の作成

Step 5: Slack 通知設定

Step 6: PagerDuty 設定（P1 アラートのみ）

Step 7: 疎通検証（検証用 Datadog アカウント）

Step 8: 本番 Datadog アカウントへの移行

運用とメンテナンス

日次運用

週次運用

月次運用

Phase 移行時の運用

Phase 1 → Phase 2 移行時

Phase 2 → Phase 3 移行時

ドキュメントメンテナンス

参考資料

Datadog ドキュメント

AWS ドキュメント

内部ドキュメント

変更履歴