CloudFront Real-time Logs 監視設計書

ドキュメント情報

項目	内容
作成日	2026-03-24
対象環境	全環境（production、staging、develop等）
対象システム	AWS全体のCloudFront Distributions
バージョン	2.26

ドキュメント	パス	参照箇所
WAF アーキテクチャ設計書	cloudfront-waf-architecture.md	WAF全体アーキテクチャ、IP Blacklist設定方法
WAF 運用設計書	waf-operation-design.md	IP Block運用フロー、インシデント対応
WAF 監視・アラート設計書	../../datadog/monitoring-guides/waf-monitoring-alert-design.md	Datadog基本設定、通知設定

背景・目的
要件
対象範囲
アーキテクチャ設計
Real-time Logsフィールド設計
Kinesis Data Streams設計
Kinesis Firehose設計
Datadog統合設計
404 Bot検知ロジック
定期モニタリング
KDS/Firehoseの健全性監視
WAF連携設計
コスト見積もり
サンプリング率調整戦略
CloudFront拡張メトリクスとの使い分け
初期評価計画
リスクと対策
変更履歴

背景・目的

1.1 背景

コーポレートサイト/LP（CloudFront配下）に対し、4xx/5xx の異常検知、404スキャン等のBot挙動を早期に把握し、WAFでブロック判断を行いたい
CloudFront標準アクセスログ（S3）は存在するが、遅延・後追いが中心となるため、運用監視用途としてはリアルタイム性が不足する
WAF設計書で「CloudFront Real-time Logsによる詳細なエラーログ分析は別PR・別ドキュメントで検討」と記載されており、本ドキュメントでその設計を具体化する

1.2 目的

CloudFront Real-time logs を Datadog に取り込み、以下を実現する：

4xx/5xx の発生を準リアルタイムに監視し、異常を早期検知する
404の偏り（特定IP/UA/パス/国）からBot/スキャンを検知し、遮断対象を特定する
CloudFront起因/オリジン起因の切り分け、遅延兆候の把握を可能にする
遮断は当面 手動運用（IP block） を基本とし、UAブロックは条件成立時のみ段階的に導入する

要件

2.1 機能要件

CloudFront Real-time logs を全ビヘイビアにアタッチし、サンプリングを行う
Datadogにログを取り込み、4xx/5xx/404の異常検知・可視化を行う
404 Bot検知時に、IP/UA等の特徴を元にWAFへ反映する判断材料を提供する

2.2 非機能要件

サンプリング率は 初期100% で開始し、一定期間ログ量・コスト・実運用有効性を確認後に調整する
ログ欠損は「絶対ゼロ」を保証しないが、攻撃検知に支障が出ないようベストエフォートで欠損回避する
機密情報混入リスクはコーポレート/LP用途のため低い見込みだが、Cookie/Query等は採用せずリスクを抑制する
FirehoseのS3バックアップは FailedDataOnlyモード で有効化（AWS仕様上必須、通常時コストゼロ）

対象範囲

3.1 対象CloudFront Distribution

本設計はAWS全体のCloudFront Distributionsに展開できる汎用的な設計です。

各Distribution単位で以下のリソースを独立して構築します：

Kinesis Data Streams（Distribution専用）
Kinesis Firehose（Distribution専用）
S3 Backup Bucket（Distribution専用）

3.2 監視対象

各Distribution共通の監視対象：

4xx（特に 404）
5xx
遅延（time-taken）
Bot疑い（IP/UA/国/Referer/パスの偏り）

アーキテクチャ設計

4.1 全体構成

アーキテクチャパターン: Distribution別完全分離（KDS + Firehose + S3 Backup）

各CloudFront Distribution単位で独立したリソースを構築:

Distribution A → KDS A (On-Demand) → Firehose A → Datadog
                                                ↓ (失敗時)
                                   S3 Backup Bucket A

Distribution B → KDS B (On-Demand) → Firehose B → Datadog
                                                ↓ (失敗時)
                                   S3 Backup Bucket B

4.2 完全分離アーキテクチャを採用する理由

4.2.1 設計方針の選択

複数のCloudFront Distributionsを監視する場合、以下の2つのアーキテクチャパターンが考えられます：

パターン	説明	特徴
A. 共有アーキテクチャ	全Distribution → 共通KDS → 共通Firehose	コスト効率重視
B. 完全分離アーキテクチャ	各Distribution専用のKDS/Firehose/S3	可用性・独立性重視

本設計ではパターンBを採用します。

4.2.2 完全分離を採用する理由

理由1: 障害影響範囲の最小化（SPOF回避）

共有の課題:

KDSまたはFirehoseで障害が発生すると、全Distributionのログ配信が停止
1つのDistributionのログ急増が他のDistributionに影響（スロットリング）

分離のメリット:

✅ 各Distributionが独立 → 1つのDistributionの障害が他に波及しない
✅ fastdoctor.jp（本番）とRetool（管理ツール）のログ配信が互いに影響しない

理由2: Distribution別のカスタマイズが可能

共有の課題:

Firehoseバッファ設定が全Distribution共通
ログ加工処理が全Distribution共通
サンプリング率変更時に全Distributionが影響を受ける

分離のメリット:

✅ Distribution別にバッファ設定を最適化（例: 重要なDistributionは短めのバッファ）
✅ Distribution別にサンプリング率を調整（例: fastdoctor.jpは100%、Retoolは10%）
✅ Distribution別にDatadogのタグ戦略を変更可能

理由3: 権限管理の明確化

分離のメリット:

✅ Distribution別にIAM権限を分離
✅ S3 Backup Bucketも分離 → 各チームが自分のログのみアクセス

理由4: コスト可視化

分離のメリット:

✅ Distribution別にKDS/Firehose/S3のコストを自動集計
✅ Cost Explorerでタグによるグルーピングが容易
✅ どのDistributionがコスト増の原因かを即座に特定

理由5: ライフサイクル管理の柔軟性

分離のメリット:

✅ 用途別にログ保持期間を設定
✅ Distribution追加・削除時もリソースごと管理が容易

理由6: コスト差が小さい（On-Demandモード採用時）

On-Demandモードではデータ量ベースの課金 → 共有しても分離してもコストはほぼ同じ

結論: コストデメリットがほぼ無いため、可用性・独立性を優先して分離を採用

4.2.3 採用アーキテクチャ

✅ Distribution別完全分離 + On-Demand KDS

各Distribution単位で以下を構築:

KDS: On-Demandモード（自動スケール）
Firehose: Distribution専用（個別設定可能）
S3 Backup: Distribution別バケット（FailedDataOnly）

4.3 データフロー図（Distribution単位）

各CloudFront Distributionで以下のフローを構築します：

注: このフローは各CloudFront Distributionごとに独立して構築されます。

4.4 コンポーネント一覧

コンポーネント	リージョン	役割	保存期間
CloudFront Distribution	GLOBAL	Real-time Logs出力元	-
Kinesis Data Streams	us-east-1	Real-time Logsバッファ、スループット制御	24時間
Kinesis Firehose	us-east-1	Datadog HTTP Endpointへの配信	-
Datadog Logs	AP1	ログ監視、可視化、アラート	15日
S3 (Standard Logging)	us-east-1	全アクセスログの監査保存（既存）	無期限
WAF Web ACL	us-east-1	IP Blacklist（Bot検知時に更新）	-

4.5 データフロー

CloudFront が Real-time Logs を Kinesis Data Streams に配信（サンプリング100%）
Kinesis Firehose が KDS をソースとして、Datadog HTTP intake に配送（60秒バッファ）
Datadog Logs Pipeline でタグ付け、正規化
Datadog Monitor で 404 Bot、5xx急増を検知
SRE Team がアラート受信、ログ確認後、必要に応じて WAF Blacklist（IP/UA）に追加

4.6 S3ログの位置づけ

CloudFront標準アクセスログ（S3）: 「監査/後追い調査」の根拠（既に有効、無期限保持）
Real-time Logs: 運用監視用途（即時検知・アクション判断）に特化
FirehoseのS3 Backup: FailedDataOnlyモードで有効化（AWS仕様上必須、Datadog配信失敗時のみS3に保存）

Real-time Logsフィールド設計

5.1 採用フィールド

フィールド選定方針: コストを勘案し、セキュリティ監視に必要な最低限のフィールドのみを選定しています。

フィールド名	説明	用途
`timestamp`	リクエスト時刻（エポック秒）	時系列分析
`c-ip`	クライアントIPアドレス	Bot検知、IP Block判断
`c-country`	クライアントの国コード	地理的分析、国別Bot検知
`cs-method`	HTTPメソッド	リクエストパターン分析
`cs-host`	Hostヘッダー	ドメイン別分析
`cs-uri-stem`	URIパス（クエリ除く）	スキャンパターン検知
`sc-status`	ステータスコード	404/5xx検知
`x-edge-response-result-type`	オリジン応答結果	オリジン/CloudFront切り分け
`x-host-header`	オリジンのHostヘッダー	Distribution識別、タグ付け用
`cs-user-agent`	User-Agent	Bot検知、UA Block判断
`cs-referer`	Refererヘッダー	Bot検知（Refererなし判定）
`time-taken`	総処理時間（秒）	パフォーマンス分析、異常遅延検知

合計: 12フィールド

Kinesis Data Streams設計

6.1 容量モード選択

✅ On-Demandモードを採用

モード	特徴	月額コスト（1GB/日想定）	推奨
On-Demand	自動スケール、データ量課金	$1.20	✅
Provisioned	固定shard数、手動スケール	$30.00（2 shards）	-

On-Demandを選択する理由:

✅ 自動スケール → スロットリングリスク回避
✅ データ量ベース課金 → 使用量に応じた最適コスト
✅ 運用負荷削減 → shard数の手動調整不要
✅ バースト対応 → アクセス急増時も自動対応
✅ 低コスト → 小規模Distributionでは安い

6.2 KDS設計（Distribution単位）

各CloudFront Distributionごとに専用KDSを作成

リソース命名規則:

cloudfront-realtime-logs-{distribution-name}

例:
- cloudfront-realtime-logs-fastdoctor-jp
- cloudfront-realtime-logs-amzconnect
- cloudfront-realtime-logs-retool

6.3 スループット上限（参考）

On-Demandモードの自動スケール上限:

ap-northeast-1リージョンのデフォルト上限: 200 MB/sec または 200,000 records/sec
上限緩和: AWS サポート経由で最大10GB/sまで引き上げ可能

例: fastdoctor.jp（ピーク187 RPS(202601~202603)）:

データ流入 = 187 RPS × 2KB = 374 KB/sec = 0.374 MB/sec
レコード流入 = 187 RPS

On-Demand上限:
  - データ: 200 MB/sec（余裕度: 535倍）
  - レコード: 200,000 records/sec（余裕度: 1,070倍）

→ 十分な余裕あり

6.4 監視

初期フェーズでは実装不要 - On-Demandモードは自動スケールするため、スロットリング監視は基本的に不要です。

コスト急増の監視: 17.1 コスト急増リスクでDatadog Monitorによる即時検知方法を記載しています。

6.5 リテンション

24時間（デフォルト）
Firehose配信失敗時のバッファとして機能
24時間以内に配信を復旧すればデータ欠損なし

Kinesis Firehose設計

7.1 Firehose設計（Distribution単位）

各CloudFront Distributionごとに専用Firehoseを作成

リソース命名規則:

cloudfront-realtime-logs-{distribution-name}

例:
- cloudfront-realtime-logs-fastdoctor-jp
- cloudfront-realtime-logs-amzconnect
- cloudfront-realtime-logs-retool

7.2 送信先

Datadog HTTP endpoint（AP1リージョン）
URL: https://aws-kinesis-http-intake.logs.ap1.datadoghq.com/v1/input

7.3 バッファ設定

攻撃検知目的のため、バッファを短めに設定：

hcl

http_endpoint_configuration {
  url                = "https://aws-kinesis-http-intake.logs.ap1.datadoghq.com/v1/input"
  buffering_size     = 1   # MB（リアルタイム性重視）
  buffering_interval = 60  # seconds（Firehose最小値）
}

転送遅延:

Firehoseバッファ: 60秒または 1MB（先に到達した方）
最大遅延: 約60秒（低トラフィック時）
ピーク時: 数秒〜数十秒（サイズに到達次第配信）

7.4 S3 Backup設計（Distribution別バケット）

✅ S3 Backupを有効化（s3_backup_mode = "FailedDataOnly"）

重要: Kinesis Firehose HTTP Endpoint配信では、AWS仕様上S3 Backupの設定が必須です。バックアップモードとして以下2種類があり、本設計ではFailedDataOnlyを採用します。

モード	説明	本設計での採用
`FailedDataOnly`	Datadog配信失敗時のみS3に保存	✅ 採用
`AllData`	全データをS3にも保存	❌ 不採用（コスト増）

設計方針:

Datadog配信失敗時のデータ保護（AWS仕様上必須）
Distribution別にバケットを分離 → 障害影響範囲の最小化、権限管理の明確化
通常運用時のS3ストレージコストはゼロ（Datadog配信成功時はS3に保存されない）

バケット命名規則:

cloudfront-logs-backup-{distribution-name}

例:
- cloudfront-logs-backup-fastdoctor-jp
- cloudfront-logs-backup-amzconnect
- cloudfront-logs-backup-retool

S3 Backup運用方針:

項目	設定値	理由
バックアップモード	FailedDataOnly	通常時はコストゼロ、失敗時のみ保存
保持期間	30日（Distribution別に設定可能）	標準ログで取得できているため調査用に保存
圧縮	GZIP	ストレージコスト削減
プレフィックス	`failed-logs/`	失敗ログを明確に識別

7.5 認証

Datadog API Key を Secrets Manager に格納
Firehose から Secrets Manager 経由で取得

7.6 配信失敗監視

Datadog Monitor設定例:

メトリクス: aws.firehose.delivery_to_http_endpoint_records_failed{delivery_stream:cloudfront-realtime-logs-*}
条件: sum(last_5m) > 0
優先度: P1 (Critical)
通知先: Slack

Datadog統合設計

8.1 ログ整形/タグ

重要: CloudFront Real-time Logsにおいて、ホスト名（host）タグの付与が最も重要です。これにより、Distribution単位でのログフィルタリングと可視化が可能になります。

source: cloudfront_rt

必須タグ:

host - 最重要。x-host-header フィールドから抽出（例: host:fastdoctor.jp）
distribution_name - Firehose common_attributesから付与（例: distribution_name:fastdoctor-jp）

タグ付けの流れ:

CloudFront Real-time Logs:
  - x-host-header: "fastdoctor.jp" → tag "host:fastdoctor.jp" ★最重要

Firehose common_attributes:
  - Name: "fastdoctor-jp" → tag "distribution_name:fastdoctor-jp"

8.2 Datadog Logs Pipeline設計

親パイプライン: CloudFront Real-time Logs

Filter: source:cloudfront_rt

必須Processor（最重要）:

Remapper: x-host-header → tag host:{value} ★最も重要
- CloudFront Real-time Logsの x-host-header フィールドから抽出
- Distribution単位でのログフィルタリングと可視化を実現
- 例: x-host-header: "fastdoctor.jp" → host:fastdoctor.jp

自動付与されるタグ:

distribution_name - Firehose common_attributesから自動付与（例: distribution_name:fastdoctor-jp）

8.3 Datadog Dashboard設計

運用方針:

運用開始から1-2週間は手動運用: ダッシュボードを手動で作成・更新し、運用しながらウィジェット構成を最適化
1-2週間後にTerraform管理化: 確定したダッシュボード構成をTerraformコード化し、バックアップ・再現性を確保
1つの統合ダッシュボード: 複数のダッシュボードではなく、1つのダッシュボードにすべてのウィジェットを配置
Template Variable: $distribution_name で Distribution を切り替え可能

Dashboard: CloudFront Real-time Logs 監視

セクション1: 全体概要

No	ウィジェット	タイプ	クエリ
1	リクエスト数	Timeseries	`source:cloudfront_rt distribution_name:$distribution_name count`
2	ステータスコード別	Timeseries	`source:cloudfront_rt distribution_name:$distribution_name by @sc_status`
3	Distribution別リクエスト	Timeseries	`source:cloudfront_rt by distribution_name`
4	5xx Top Paths	Toplist	`source:cloudfront_rt distribution_name:$distribution_name @sc_status:[500 TO 599] by @cs_uri_stem`

セクション2: 404 Bot Detection

No	ウィジェット	タイプ	クエリ
5	404 Top IPs	Toplist	`source:cloudfront_rt distribution_name:$distribution_name @sc_status:404 by @c_ip`
6	404 Top Paths	Toplist	`source:cloudfront_rt distribution_name:$distribution_name @sc_status:404 by @cs_uri_stem`
7	404 Top User-Agents	Toplist	`source:cloudfront_rt distribution_name:$distribution_name @sc_status:404 by @cs_user_agent`
8	404 by Country	Geomap	`source:cloudfront_rt distribution_name:$distribution_name @sc_status:404 by @c_country`
9	404 by Host	Toplist	`source:cloudfront_rt distribution_name:$distribution_name @sc_status:404 by host`
10	Recent 404 Logs	Log Stream	`source:cloudfront_rt distribution_name:$distribution_name @sc_status:404`

注記:

スキャンパターン（/.env, /wp-admin等）のアクセスはWAFのマネージドルールでブロックを想定しているが、検知できずアクセスが増加するようであれば、モニタリング・監視の導入を検討

404 Bot検知ロジック

9.1 検知パターンと閾値

重要: 以下のDatadog Monitor設定（クエリ、閾値、通知先等）は実装例です。実装時および運用しながら、各Distributionの特性や検知状況に応じて調整・更新してください。

調整が想定される項目:

閾値: リクエスト数、404率、時間窓（5分/10分等）
クエリ: フィルタ条件、グループ化キー
優先度: P1/P2/P3の判断
通知先: Slackチャンネル、メンション対象

パターン1: 同一IPからの高頻度404（Distribution別）

条件:

同一IPから5分間で100回以上の404
かつ
404率 > 80%
かつ
同一Distribution ID

閾値調整方針:

初期値（仮）: 100回/5分、404率 80%
調整タイミング: 初期評価期間（1-2週間）後
Distribution別調整例:
- fastdoctor.jp（本番コーポレート）: 100回/5分（厳しめ）
- Amazon Connect（アクセス多）: 200回/5分（緩め）
- Retool（管理ツール）: 50回/5分（厳しめ）

Datadog Monitor設定:

メトリクス名: cloudfront_rt.404_by_ip_per_distribution
クエリ: source:cloudfront_rt distribution_name:* @sc_status:404 group by @c_ip, distribution_name
条件: count > 100 in 5min
優先度: P2 (High)
通知先: Slack (#squad-sre-noti-security)

メッセージ:
[CloudFront RT] 404 Bot検知 - 同一IP高頻度

Distribution: {{distribution_name.name}}
IP: {{c_ip.name}}
5分間の404回数: {{value}}

ログ確認:
https://app.datadoghq.com/logs?query=source%3Acloudfront_rt%20distribution_name%3A{{distribution_name.name}}%20%40sc_status%3A404%20%40c_ip%3A{{c_ip.name}}

次のアクション:
1. ログでスキャンパターン（/.env等）を確認
2. 該当する場合は WAF Blacklist（IP/UA）に追加（[12. WAF連携設計](#waf連携設計) 参照）
3. Slack (#squad-sre-noti-security) に報告

閾値調整の検討:
- 誤検知が多い場合: 閾値を上げる（例: 100 → 200回/5min）
- 攻撃を見逃す場合: 閾値を下げる（例: 100 → 50回/5min）

パターン2: 特定UAの異常（Distribution別）

条件:

同一User-Agentから10分間で404率 > 80%
かつ
総リクエスト数 > 50
かつ
同一Distribution ID

閾値調整方針:

初期値（仮）: 50リクエスト/10分、404率 80%
調整タイミング: 初期評価期間（1-2週間）後、誤検知状況を確認
Distribution別調整例:
- fastdoctor.jp（多様なUA）: 100リクエスト/10分（緩め、誤検知回避）
- 内部ツール系: 50リクエスト/10分（標準）

優先度: P3 (Medium)

注意: UAブロックは誤爆リスクが高いため、慎重に判断

Datadog Monitor設定:

クエリ: source:cloudfront_rt distribution_name:* @sc_status:404 group by @cs_user_agent, distribution_name
条件: count > 50 in 10min AND 404率 > 80%
優先度: P3 (Medium)
通知先: Slack (#squad-sre-noti-security)

メッセージ:
[CloudFront RT] 特定UA異常検知 - 慎重に判断

Distribution: {{distribution_name.name}}
User-Agent: {{cs_user_agent.name}}
10分間のリクエスト数: {{value}}

ログ確認（該当UA全体）:
https://app.datadoghq.com/logs?query=source%3Acloudfront_rt%20distribution_name%3A{{distribution_name.name}}%20%40cs_user_agent%3A{{cs_user_agent.name}}

次のアクション:
1. 該当UAの200番台レスポンスを確認（正規ユーザーの可能性）
2. 既知のBot UAリストと照合
3. 明らかなBot以外はIP Blockを優先

閾値調整の検討:
- 誤検知が多い場合: 閾値を上げる（例: 50 → 100リクエスト/10min）

9.2 判断フロー

IPとUAは独立した判断基準で評価します。

9.2.1 IP Block判断フロー

判断ポイント:

即座にIP Block: 明確なスキャンパターン（/admin, /.git等）のアクセス
IPブロックもしくはWAF海外アクセスブロック検討: 高頻度404 + 特定国・地域に偏る（IPレベルでのブロック、またはWAFでの地域ベースのアクセス制限を検討）
監視継続: 正常ユーザーの誤操作の可能性がある場合

9.2.2 UA Block判断フロー

判断ポイント:

UA Block検討: 既知のBot・スクレイパーのUA（慎重に判断）
IP Block優先: UAよりIPでのブロックを優先検討
監視継続: 正常ブラウザUAの場合、誤爆リスクが高いため慎重に

定期モニタリング

CloudFront Real-time LogsをDatadogで定期的にモニタリングすることで、アラート発火前の異常パターンや新たな脅威を早期発見します。

10.1 監視アプローチ

本設計では、コスト効率を重視し、以下のアプローチで監視を実現します：

監視に使用するデータソース

1. ログクエリ（メイン）

ダッシュボード可視化: 8.3のダッシュボード（Timeseries, Toplist, Geomap等）でIP/UA分析
アラート設定: 9.1のログベースMonitorで404 Bot検知
Top N分析: 404 Top IPs、404 Top UAなど
カウント・グループ化: count by @c_ip, distribution_nameなどの集計
ログ保持期間: 15日間（十分な分析期間）
コスト: ログ取り込みコストのみ（追加料金なし）

2. CloudWatch統合メトリクス（補助）

Datadog AWS統合で以下のメトリクスが取得可能：
- デフォルトメトリクス（無料）：
  - aws.cloudfront.requests - リクエスト総数
  - aws.cloudfront.4xx_error_rate - 4xxエラー率
  - aws.cloudfront.5xx_error_rate - 5xxエラー率
  - aws.cloudfront.bytes_downloaded - ダウンロードバイト数
  - aws.cloudfront.bytes_uploaded - アップロードバイト数
- 拡張メトリクス（$1.80/月/Distribution、WAF設計書で有効化）：
  - aws.cloudfront.401_error_rate、aws.cloudfront.403_error_rate、aws.cloudfront.404_error_rate - ステータスコード別エラー率
  - aws.cloudfront.502_error_rate、aws.cloudfront.503_error_rate、aws.cloudfront.504_error_rate - 5xx系詳細エラー率
  - aws.cloudfront.cache_hit_rate - キャッシュヒット率
  - aws.cloudfront.origin_latency - オリジンレイテンシ
用途: 長期トレンド分析（15日超）、全体傾向の把握、ステータスコード別エラー率監視
コスト: デフォルトメトリクスは無料、拡張メトリクスは$1.80/月/Distribution

3. Log-based Metricsは作成しない

理由: コスト急増リスク
代替: ログクエリとCloudWatch統合メトリクスで十分対応可能

実現できる分析

本設計（ログクエリ + CloudWatch統合メトリクス）で以下の分析が可能：

分析内容	実現方法	参照箇所
IP/UA別404分析	ログクエリ（8.3のダッシュボード）	404 Top IPs、404 Top UAs
404 Bot検知アラート	ログベースMonitor（9.1）	パターン1（IP別）、パターン2（UA別）
ステータスコード分布	ログクエリ（8.3のダッシュボード）	ステータスコード別時系列
国別404分析	ログクエリ（8.3のダッシュボード）	404 by Country（Geomap）
長期トレンド（15日超）	CloudWatch統合メトリクス（デフォルト）	Distribution別リクエスト数、4xx/5xxエラー率
ステータスコード別エラー率	CloudWatch拡張メトリクス	401/403/404/502/503/504別エラー率
キャッシュ効率分析	CloudWatch拡張メトリクス	キャッシュヒット率、オリジンレイテンシ
定期モニタリング	ログクエリ + ダッシュボード（10.2）	日次/週次レビュー

Log-based Metricsが必要になるケース（将来検討）

以下のケースでは、Log-based Metricsの作成を検討してください：

ケース	理由	対応
ログクエリのパフォーマンス低下	大量アクセスでダッシュボード表示が遅延	特定メトリクスのみLog-based Metricsを作成
15日超の詳細トレンド分析	CloudWatch統合では粒度が粗い	必要な期間・粒度のメトリクスを作成
パーセンタイル計算が必要	p50, p95, p99などの高度な統計	Distribution型メトリクスを作成

注意: Log-based Metricsを作成する場合は、カーディナリティを最小限に抑え、コストを監視しながら段階的に追加してください。

10.2 定期モニタリング手順

定期的にダッシュボード（8.3）とCloudWatch統合メトリクスをレビューすることで、アラート発火前の異常パターンや長期的な脅威を早期発見します。

日次レビュー

チェック項目:

IP/UAアクセス傾向の確認
- 新規上位IP/UAの出現、特定IP/UAのアクセス急増を確認
- 既知のスキャンツールUAや不自然なUAパターンの検出
404エラー傾向の確認
- 高頻度404を発生させているIP/UAの存在確認
- スキャンパターン（/.env, /wp-admin等）との相関分析
ステータスコード分布の確認
- 404比率やエラー率の異常増加を確認
- 5xxエラーの発生状況確認

アクション:

異常検知時: 詳細調査、Slack報告、GitHub Issue作成
脅威確定時: 12. WAF連携設計の運用フロー開始

週次レビュー

チェック項目:

トレンド分析
- ユニークIP/UA数の推移、アクセスパターンの変化
- Distribution別のトラフィック傾向
WAF Blacklistの効果測定
- ブロック済みIP/UAの再出現確認（IPローテーション検知）
- ブロック後の攻撃減少効果、誤爆の有無確認
新たな脅威パターンの探索
- 低頻度・長期的な攻撃パターン
- 分散型攻撃（ボットネット）の兆候
監視ルールの見直し
- 検知閾値の調整、新規Monitor追加の検討
- False Positive削減施策

ドキュメント更新:

重要な発見事項の記録、WAF Blacklist追加履歴の整理

10.3 WAF運用フローとの連携

定期モニタリングで検知した異常は、12. WAF連携設計の運用フローに接続します：

連携フロー

推奨運用:

アラート: 高頻度・明確な脅威の即座対応
定期モニタリング: 低頻度・長期攻撃の戦略的検知

KDS/Firehoseの健全性監視

CloudFront Real-time Logsのデータパイプライン（KDS → Firehose → Datadog）の健全性を監視し、ログ欠損や配信失敗を早期に検知します。

重要: 以下の監視メトリクス、閾値、Datadog Monitor設定は実装例です。実装時および運用しながら、システムの特性や運用状況に応じて調整・更新してください。

11.1 監視対象メトリクス

必要最低限の監視メトリクス

本設計では、最も重要な2つのメトリクスのみを監視します：

メトリクス	監視対象	監視目的	閾値	アラート優先度
`PutRecord.Success` / `PutRecords.Success`	KDS	CloudFrontからのログ書き込み成功率（データ損失防止）	99%未満 → アラート	P1 (Critical)
`DeliveryToHTTP.Success`	Firehose	Datadogへの配信成功率（監視の継続性確保）	95%未満 → アラート	P1 (Critical)

監視設計の方針:

データ損失の防止と監視継続性の確保に焦点を絞る
この2つのメトリクスで、CloudFront → KDS → Firehose → Datadogの全経路の健全性を確認可能
その他のメトリクス（遅延、スロットリング等）は、問題発生時の調査で確認

追加検討が必要な場合のメトリクス（参考）

運用中に以下の問題が頻発する場合のみ、追加を検討：

メトリクス	監視対象	監視目的	追加を検討するケース
`DataFreshness`	Firehose	Firehose配信遅延	配信遅延が頻繁に発生し、リアルタイム性が求められる場合
`IncomingBytes`	KDS	データ量の異常増減	コスト急増の予兆検知が必要な場合
`ThrottledRecords`	Firehose	スロットリング検知	Firehoseでスロットリングが発生した場合（On-Demandでは基本発生しない）

11.2 Datadog Monitor設定例

Monitor 1: KDS書き込み失敗率（クリックで展開）

メトリクス: aws.kinesis.put_record.success (または aws.kinesis.put_records.success)
クエリ: avg:aws.kinesis.put_record.success{*} by {stream_name}
条件: < 99% over last 10min
優先度: P1 (Critical)
通知先: Slack (#squad-sre-noti-security)

メッセージ:
[CloudFront RT] KDS書き込み失敗率が高い（データ損失リスク）

Stream: {{stream_name.name}}
成功率: {{value}}%

影響:
- CloudFront Real-time LogsがKDSに書き込めていない（データ損失）
- ログ欠損により、404 Bot検知が不完全になる可能性

原因:
- KDSスロットリング（異常トラフィック、DDoS攻撃等）
- KDSアカウントレベルクォータ（デフォルト200MB/sec）到達
- AWS側の一時的な障害

次のアクション:
1. KDS IncomingBytesを確認（200MB/secに近いか）
2. CloudFront Distributionへの異常トラフィックを確認
3. DDoS攻撃の場合、WAF/Shield設定を確認
4. AWS側障害の場合、AWS Health Dashboardを確認
5. 緊急時: サンプリング率を一時的に下げる（100% → 10%）
6. 恒久対応: AWS サポートに上限緩和申請（最大10GB/sまで拡張可能）

Monitor 2: Firehose配信失敗率（クリックで展開）

メトリクス: aws.firehose.delivery_to_http.success
クエリ: avg:aws.firehose.delivery_to_http.success{*} by {delivery_stream_name}
条件: < 95% over last 10min
優先度: P1 (Critical)
通知先: Slack (#squad-sre-noti-security)

メッセージ:
[CloudFront RT] Firehose → Datadog配信失敗率が高い

DeliveryStream: {{delivery_stream_name.name}}
成功率: {{value}}%

影響:
- CloudFront Real-time LogsがDatadogに届いていない
- 404 Bot検知が機能していない可能性
- ダッシュボードが更新されていない

次のアクション:
1. Firehoseコンソールで配信失敗の詳細を確認
2. Datadog API Key/Endpointの有効性を確認
3. S3 Backupバケットに失敗データが保存されているか確認
   バケット: cloudfront-logs-backup-{distribution-name}
4. Datadogの取り込み制限（レート制限）に達していないか確認
5. 失敗が継続する場合、CloudFront Real-time Logs設定の一時停止を検討

11.3 S3 Backupの確認手順

Firehose配信失敗時、データはS3 Backupバケットに保存されます。

バケット命名規則:

cloudfront-logs-backup-{distribution-name}

例:
- cloudfront-logs-backup-fastdoctor-jp
- cloudfront-logs-backup-amzconnect

確認手順例:

bash

# S3 Backupバケットの確認
aws s3 ls s3://cloudfront-logs-backup-fastdoctor-jp/ --recursive --human-readable --summarize

# 特定期間のバックアップを確認
aws s3 ls s3://cloudfront-logs-backup-fastdoctor-jp/2026/03/24/ --recursive

# バックアップデータのダウンロード（調査用）
aws s3 cp s3://cloudfront-logs-backup-fastdoctor-jp/2026/03/24/file.json.gz ./
gunzip file.json.gz
cat file.json | jq .

バックアップデータの再送: Firehose障害復旧後、S3 Backupデータを手動でDatadogに再送することも可能です（必要に応じて検討）。

WAF連携設計

12.1 ブロック方針

基本方針: IPとUAの両方を注視し、攻撃パターンに応じて適切にブロック

IP Block

優先度: 高（即座に対応）
条件: スキャンパターン + 高頻度404
利点: 攻撃元を直接ブロック、効果が確実
欠点: IPローテーション、プロキシ・VPN、ボットネット等で回避可能

UA Block

優先度: 中（IP動的・ランダムの場合に有効）
条件: 以下のいずれかが揃った場合
- パターン1: 同一UAから高頻度404 + IPが複数/動的変化
- パターン2: 既知のBot/スクレイピングツールのUA
- パターン3: 明らかに偽装されたUA（空白、"Mozilla/5.0"のみ等）
- パターン4: スキャンツール特有のUA（sqlmap、nikto、nmap等）
利点: IPローテーション攻撃に有効、AS全体をブロックせずに対応可能
欠点: 誤爆リスク（正規ユーザーが同じUAを使用している可能性）

12.2 運用フロー（Bot検知 → WAF対応）

フロー概要

Step 1: アラート受信（0分）

検知経路:

Datadog Alert: 404 Bot検知（パターン1-3のいずれか）
通知先: Slack

初動判断:

緊急度を確認（P1/P2/P3）
影響範囲を確認（Distribution、IP数）

Step 2: ログ確認 - IP/UA分析（5分以内）

Datadog Logsでの確認:

Distribution別フィルタ
該当IPアドレスのログ
User-Agentのパターン分析
時系列での404発生パターン

確認ポイント:

スキャンパターンの有無: /.env、/wp-admin、/phpmyadmin 等
404率: 80%以上なら攻撃の可能性大
アクセス頻度: 100回/5分以上
IPパターン: 固定IP / 複数IP / IPローテーション
User-Agent: 既知のBot、スクレイピングツール、正規ブラウザ類似

Step 3: 脅威評価 - IP/UAパターン分析（10分以内）

IPパターン	UAパターン	判断	アクション
固定IP	スキャンツール特有	攻撃確定	IP Block
固定IP	正規ブラウザ類似	攻撃確定	IP Block
複数IP/動的	スキャンツール特有	攻撃確定	IP + UA Block
複数IP/動的	既知の悪性Bot	攻撃確定	IP + UA Block
複数IP/動的	正規ブラウザ類似	攻撃確定	IP Block + 継続監視
高頻度404のみ	-	要監視	継続監視、1時間後に再評価
正常パターン	-	誤検知	閾値調整、Monitor設定変更

評価基準:

スキャンパターン明確 → 即座にブロック
IPが動的 + UA特徴的 → IP + UA併用ブロック
IPが動的 + UA正規 → IP Blockのみ、効果測定後にUA Block検討
疑わしいが確証なし → 継続監視
正規ユーザーの可能性 → 誤検知、閾値調整

Step 4: WAF Blacklist追加（30分以内）

パターンA: IP Block（固定IPの場合）

Terraform実装:

対象ファイル: fastdoctor-template/common/{environment}/waf.tf

hcl

locals {
  ip_blacklist_ipv4 = [
    "1.2.3.4/32",          # 既存IP
    "5.6.7.8/32",          # 新規追加: YYYY-MM-DD 404 Bot検知
    "203.0.113.0/24",      # 新規追加: YYYY-MM-DD 連続する複数のCIDRからの攻撃パターン
  ]
}

CIDR単位でのブロックを検討するケース:

同一IPから攻撃後、連続する複数のCIDRからアクセスが来る場合
明確な攻撃パターンが特定のCIDRレンジに集中している場合
IPローテーション攻撃で/24や/16単位での攻撃パターンが確認される場合

適用コマンド:

bash

terraform apply -target=aws_wafv2_ip_set.ip_blacklist_ipv4

パターンB: IP + UA Block（IP動的 + UA特徴的の場合）

Terraform実装:

hcl

locals {
  # IP Blacklist
  ip_blacklist_ipv4 = [
    "1.2.3.4/32",      # 既存IP
    "5.6.7.8/32",      # 新規追加: YYYY-MM-DD 404 Bot検知
    "10.0.1.5/32",     # 同一UA、別IP
  ]

  # UA Blacklist
  ua_blacklist = [
    "sqlmap",                    # 既知スキャンツール
    "python-requests/2.25.1",    # 新規追加: YYYY-MM-DD 404 Bot検知
  ]
}

適用コマンド:

bash

terraform apply -target=aws_wafv2_ip_set.ip_blacklist_ipv4 -target=aws_wafv2_rule.ua_blacklist

注意事項:

即座にブロック: WAF Blacklist（IP: 優先度-2、UA: 優先度-1）は即座に評価されるため、追加後数秒でブロック開始
IPv6対応: 必要に応じてip_blacklist_ipv6にも追加
UA部分一致: UAは部分一致でブロックされるため、正規UAを含まないか確認
一時的なブロック: 期間限定ブロックの場合は、削除予定日をコメントに記載

Step 5: 効果測定（1-2時間後）

確認項目:

[ ] 該当IP/UAからのアクセスが0件になったか（CloudFront Real-time Logs）
[ ] 404 Bot検知アラートが停止したか（Datadog Monitor）
[ ] 他のIP/UAから同様の攻撃が発生していないか
[ ] 正規ユーザーへの影響がないか（エラーレート変化）

追加対応が必要な場合:

状況	対応
攻撃が続く（IP変更）	UA Block追加（Step 4パターンB）
攻撃が続く（UA変更）	新しいUA Blacklist追加
AS単位での攻撃	AS全体のブロックを検討（IP Setの追加）
誤爆が発生	即座にBlacklistから削除、Force Allow List検討

Step 6: 記録（当日中）

GitHub Issue作成:

markdown

## 概要
YYYY-MM-DD HH:MM に {distribution_name} への404スキャン攻撃を検知、WAF Blacklistに追加

## 検知情報
- **Distribution**: {distribution_name}
- **IP**: {ip_address または ip_address_list}
- **User-Agent**: {user_agent}
- **検知時刻**: YYYY-MM-DD HH:MM
- **スキャンパターン**: /.env、/wp-admin 等
- **404率**: XX%
- **アクセス頻度**: XX回/5分

## ブロック対応
- **IP Block**: ✅ / ❌
- **UA Block**: ✅ / ❌
- **Terraform適用**: `terraform apply -target=aws_wafv2_ip_set.ip_blacklist_ipv4` 等
- **PR**: #XXXX

## 効果測定（1時間後）
- ブロック済みIP/UAからのアクセス: XX件
- アラート停止: ✅ / ❌
- 正規ユーザー影響: なし / あり（詳細）

記録場所:

リポジトリ: fastdoctor-jp/terraform_for_aws
Issue Labels: waf, security, incident-response, ip-block or ua-block
関連PR: Terraform変更のPR番号

継続監視フロー（要監視と判断した場合）

再評価タイミング: 1時間後

再評価基準:

404率が80%を超え続けている → 攻撃確定、IP Blacklist追加
404率が低下した（< 50%） → 正常なクローラーの可能性、監視継続
アクセスが停止した → 対応不要、監視終了

記録:

再評価結果をDatadog Notebookに記録
最終判断をGitHub Issueに記載

誤検知対応フロー

閾値調整:

Datadog Monitorの閾値を緩める（例: 100回/5分 → 200回/5分）
Distribution別に閾値を調整（Amazon Connect等、アクセス多い場合）

Monitor設定変更:

404率の条件を追加（例: 404率 > 80%の条件を強化）
特定パスを除外（例: /favicon.ico、/robots.txt 等）

記録:

閾値変更理由をPRに記載
誤検知パターンを設計書に追記（将来の参考）

12.3 将来検討

自動化（Datadog workflow/ランブック等）
WAF側でのrate-based/managed rule group活用拡張

コスト見積もり

13.1 前提条件

アーキテクチャ: Distribution別完全分離 + KDS On-Demandモード

ログ量想定（CloudWatchメトリクス実績ベース）:

fastdoctor.jp（本番）: 667MB/日 = 20GB/月
- リクエスト数実績: 200M requests/月 ≒ 6.67M requests/日
- 1リクエストあたりのログサイズ: 約100B
サンプリング率: 100%（初期導入時）

注記:

上記はCloudWatchメトリクス（2025/02〜2026/02）の実績値に基づく
実際のログ量は運用開始後に実測値で再評価

AWS料金（us-east-1リージョン）:

KDS On-Demand: $0.04/GB
Firehose: $0.029/GB
CloudFront Real-time Logs: $0.01/1M requests/field（フィールド数に応じて課金）

Datadog料金（実績ベース）:

ログ取り込み: $3.188/1M indexed logs（2026/01, 2026/02の請求実績より）

13.2 1 Distribution あたりの月額コスト

ケース1: fastdoctor.jp（実績ベース）

前提条件（CloudWatchメトリクス実績）:

リクエスト数: 200M requests/月 ≒ 6.67M requests/日
ログ量: 667MB/日 = 20GB/月
フィールド数: 12フィールド
サンプリング率: 100%

リソース	設定	計算式	月額コスト
KDS (On-Demand)	20GB/月	20GB × $0.04/GB	$0.80
Firehose	20GB/月	20GB × $0.029/GB	$0.58
CloudFront Real-time Logs	200M requests/月 × 12フィールド	200M × 12 × $0.01/1M	$24.00
S3 Backup（失敗時のみ）	通常ゼロ	-	$0.00
合計（AWS）	-	-	$25.38/月

Datadog側（実績ベース）:

項目	設定	計算式	月額コスト
ログ取り込み	200M requests/月 = 200M indexed logs	$3.188/1M × 200M	$637.60
ログ保持	15日間	-	含む

合計コスト（fastdoctor.jp、サンプリング100%）:

AWS側: $25.38/月
Datadog側: $637.60/月
合計: 約$663/月

注: CloudFront Real-time Logsは1リクエスト = 1ログ行のため、Datadogの課金は行数ベース（200M requests = 200M indexed logs）

13.3 注意事項

Datadog側コスト:

Datadog側のログ取り込みコストは**$3.188/1M indexed logs**（2026/01, 2026/02の請求実績より）
課金単位は行数ベース: 1リクエスト = 1ログ行 = 1 indexed log
上記のコスト見積もりはこの実績値に基づいて算出
コスト削減が必要な場合: Lambda filteringでエラーログのみに絞ることで、Datadogコストを91%削減可能（$637.60 → $31.88/月）
コストが許容範囲内なら: サンプリング100%のまま継続が最もシンプル（運用容易）
サンプリング率を下げることでもコスト削減は可能だが、ログ欠損リスクがあるため非推奨
WAFログ（Firehose → Datadog）のコストは WAF設計書を参照

S3 Backupコスト:

FailedDataOnlyのため、通常時はコストゼロ
Datadog配信失敗時のみS3ストレージコストが発生（稀）

コスト最適化:

コスト最適化アプローチ別の比較は 14.3 コスト最適化アプローチ別の影響を参照
初期評価計画とコスト最適化戦略はセクション14 およびセクション16 を参照

コスト最適化戦略

14.1 初期評価期間（100%、1-2週間）

目的: 実際のログ量・エラー率・コストを精緻に算出し、Lambda filteringの必要性を判断

基本方針:

まずはサンプリング100%で試験的に導入し、実際のログ量・エラー率・コストを測定
コストが許容範囲内なら100%のまま継続（最もシンプル）
コスト削減が必要な場合のみ、Lambda filteringの導入を検討
想定コスト: 約$663/月（fastdoctor.jp、200M requests/月の場合）
- AWS: $25.38/月、Datadog: $637.60/月（200M indexed logs × $3.188/1M）
- Lambda filtering導入後: 約$57.28/月（91%削減、ただし運用複雑化）
  - Lambda: $0.02/月（20,000 invocations、128MB、500ms）

流量確認方法:

WAFログと同様に、ログ転送されていない「インフラ」環境（test.fastdoctor.jp等）でCloudFrontメトリクスから流量を確認し、初期コスト見積もりを実施
実際のログ転送前にコストを試算することで、予期せぬコスト発生を防止

確認項目:

[ ] CloudFrontメトリクスから1日あたりのリクエスト数を確認
[ ] リクエスト数 × フィールド数からログ量とコストを見積もり
[ ] 本番環境で実際のログ量測定（リクエスト数/日 = indexed logs/日）
[ ] 実際のエラー率測定（4xx/5xx の割合、Lambda filteringのコスト削減効果算出に必要）
[ ] AWS実測コスト確認（KDS + Firehose + CloudFront Real-time Logs）
[ ] Datadog実測コスト確認（$3.188/1M indexed logs、行数ベース課金）
[ ] 404 Bot検知の精度を評価（ログ転送後）
[ ] コスト最適化の方針決定（100%継続 or Lambda filtering導入）

14.2 調整判断基準（実測コストに基づく）

条件	判断
コストが許容範囲内（約$663/月）	100%継続（全ログ出力、最もシンプル、推奨）
コストが許容できない + 開発リソースあり	Lambda filtering（$663 → $57.28/月、Ingest+Index削減、柔軟性高）
コストが許容できない + 開発リソースなし	Pipeline Exclusion Filter（開発不要、実際のコストは検証が必要）
どうしても開発不可	サンプリング10%（$663 → $66.30/月、ただしログ欠損リスク、非推奨）

注記:

基本方針: まずサンプリング100%で試験導入し、コストが許容できるならそのまま継続（最もシンプル）
コスト削減が必要な場合: 実際の検討時にDatadog請求書を確認し、両方式のコストを検証して判断
- Lambda filtering: Ingest + Index両方削減、柔軟性高い（開発・保守が必要）
- Pipeline Exclusion Filter: 開発不要、運用容易（実際のコストは検証が必要）
サンプリング率調整は基本的に非推奨（ログが抜け落ち、モニタリングできない可能性があるため）

14.3 コスト最適化アプローチ別の影響

アプローチ	検知精度	AWS月額	Lambda月額	Datadog月額	合計月額	備考
100%（filteringなし）	全件検知	$25.38	-	$637.60+	$663+	最もシンプル、コスト許容なら推奨
Lambda filtering（エラー5%想定）	全件検知	$25.38	$0.02	$31.88	$57.28	Ingest+Index削減、柔軟性高、開発必要
Pipeline Exclusion Filter	全件検知	$25.38	-	要検証	要検証	開発不要、実際のコストは検証が必要
サンプリング10%	10件に1件検知	$2.54	-	$63.76+	$66.30+	ログ欠損リスク、非推奨
サンプリング1%	100件に1件検知	$0.25	-	$6.38+	$6.63+	ログ欠損リスク、非推奨

注記:

上記はfastdoctor.jp（200M requests/月）の実績値に基づく
AWS月額 = KDS + Firehose + CloudFront Real-time Logs
Datadog月額 = ログ取り込み（$3.188/1M indexed logs）、行数ベース課金
1リクエスト = 1ログ行のため、200M requests = 200M indexed logs
サンプリング率を下げるとログが抜け落ち、モニタリングできない可能性がある
WAFログ（BLOCK/COUNT）のサンプリングはなし（全件出力）

エラーログのみに絞る方法（2つの選択肢）:

選択肢1: Lambda filtering（Firehose側でフィルタリング）

Kinesis Firehose + Lambda Data Transformationで技術的にはエラーログ（4xx/5xx）のみに絞ることは可能
コスト: $57.28/月（AWS $25.38 + Lambda $0.02 + Datadog Index $31.88）
特徴:
- ✅ Datadogコストを大幅削減（$637.60 → $31.88、95%削減、エラー率5%想定）
- ✅ 全件検知を維持しながら大幅なコスト削減（$663 → $57.28、91%削減）
- ✅ Datadog Ingest料金も削減（エラーログのみ送信、10M logs）
- ✅ 柔軟性が高い（フィルタリングロジックをコードで自由に記述可能）
- ✅ Lambda実行コストはほぼ無視できる（$0.02/月、20,000 invocations/月）
- ❌ CloudFront Real-time Logsの料金は削減されない（$24/月は固定、ソースで課金）
- ❌ 運用の複雑さが増加:
  - Lambda開発・保守のメンテナンスコスト
  - 同時実行数やスケーリングの検討が必要
  - 障害ポイントの増加
  - トラブルシューティングの複雑化
Lambda実行の詳細:
- Firehoseバッファサイズ: 1MB（デフォルト）
- 実行回数: 20,000 invocations/月（20GB ÷ 1MB）
- 想定メモリ: 128MB、実行時間: 500ms
- Lambda料金: $0.02/月（Request $0.004 + Compute $0.021）

選択肢2: Datadog Logs Pipeline Exclusion Filter（Datadog側でフィルタリング）

Datadog Logs Pipelineの除外フィルターで4xx/5xx以外をDropする設定
コスト: 実際の検討時に検証が必要
- Datadog Index料金は削減可能
- Datadog Ingest料金の有無・課金方式は請求書を確認する必要がある
特徴:
- ✅ 開発不要（GUI設定のみ、Lambda開発・保守不要）
- ✅ 即座に設定変更可能（柔軟性は劣るが運用は容易）
- ✅ 障害ポイントなし（Lambda追加なし、シンプル）
- ⚠️ コストは要検証（Ingest料金の課金方式により、Lambda filteringとの総コストが変わる可能性）
- ❌ 柔軟性が低い（Pipeline設定のみ、複雑なロジックは困難）

設定例:

# Exclusion Filter設定（GUI操作）
@http.status_code:<400 → Drop（Indexしない）

参考資料:
- Datadog公式: ログ管理のベストプラクティス
- Datadogコスト最適化事例

コスト比較まとめ

アプローチ	AWS	Lambda	Datadog Ingest	Datadog Index	合計	備考
100%（filteringなし）	$25.38	-	不明	$637.60	$663+	-
Lambda filtering	$25.38	$0.02	$0（送信なし）	$31.88	$57.28	Ingest + Index両方削減
Pipeline Exclusion Filter	$25.38	-	要検証	$31.88	要検証	実際の検討時に検証が必要
サンプリング10%	$2.54	-	不明	$63.76	$66.30+	ログ欠損リスク

推奨判断フロー:

初期導入: まずサンプリング100%で試験的に導入し、実際のログ量・エラー率・コストを精緻に算出
コストが許容範囲内: 100%のまま継続（最もシンプル、運用容易）
コスト削減が必要な場合:
- Lambda filtering: Ingest + Index両方削減、柔軟性高い（開発・保守が必要）
- Pipeline Exclusion Filter: 開発不要、運用容易（実際のコストは検証が必要）
- 選択基準: 実際の検討時にDatadog請求書を確認し、両方式のコストを検証して判断
サンプリング率調整は非推奨（ログが抜け落ち、モニタリングできない可能性があるため）

CloudFront拡張メトリクスとの使い分け

15.1 前提

WAF設計書で CloudFront拡張メトリクス（$1.80/月）を既に有効化しています：

401ErrorRate、403ErrorRate、404ErrorRate
502ErrorRate、503ErrorRate、504ErrorRate

15.2 使い分け

監視項目	拡張メトリクス	Real-time Logs	用途の違い
404監視	✅ 全体エラー率トレンド	✅ IP/UA/パス別詳細分析	メトリクスは傾向、Logsは詳細
Bot検知	❌ 不可	✅ 高頻度404検知	Logsのみ可能
スキャン検知	❌ 不可	✅ /.env等のパターン検知	Logsのみ可能
5xx監視	✅ ステータスコード別	✅ パス別、オリジン別詳細	メトリクスは全体、Logsは原因特定
遅延監視	❌ 不可	✅ time-taken分析	Logsのみ可能

15.3 推奨

両方を導入し、役割分担：

拡張メトリクス: 全体的なエラー率トレンド監視（WAF設計書）
Real-time Logs: Bot検知・攻撃の早期検知（本設計書）

アラート設定の違い:

拡張メトリクスのアラート: 「全体的なエラー率異常」
Real-time Logsのアラート: 「Bot/攻撃の早期検知」

初期評価計画

16.1 段階的適用戦略

基本方針: 1つのDistributionで検証 → 段階的に他のDistributionへ展開

検証の流れ:

Phase 1: test.fastdoctor.jp（検証環境） → 1週間
Phase 2: fastdoctor.jp（本番1個目） → 1-2週間
Phase 3: 他のDistributions（段階的展開） → fastdoctor.jp実績を元に順次展開

注: 検証環境の構成（infra-dev → test → production）は WAF設計書と同じです。

16.2 Phase 1: test.fastdoctor.jp検証（1週間）

目的: 技術的動作確認、ログ量見積もり

確認項目:

[ ] 1日あたりのログ量測定（GB/日）
[ ] KDS On-Demandの動作確認（自動スケール）
[ ] Firehose配信成功率 > 99% を確認
[ ] Datadog Logs にログが表示される（60秒以内）
[ ] Logs Pipeline でタグ付けが動作する（distribution_name:test-fastdoctor-jp、host:test.fastdoctor.jp 等）
[ ] 404 Bot検知アラートが動作する（テストアクセスで確認）
[ ] S3 Backup（FailedDataOnly）の動作確認

期間: 1週間

成果物:

ログ量実測値（GB/日）
月額コスト試算
検知ロジックの動作確認レポート

16.3 Phase 2: fastdoctor.jp本番適用（1-2週間）

目的: 本番環境での実際のコスト精緻算出、検知精度の評価、閾値調整

サンプリング率: 100%（初期導入時）

重要: まずはサンプリング100%で試験的に導入し、実際のログ量・エラー率・コストを精緻に算出する。コストが許容範囲内ならそのまま継続（最もシンプル）、コスト削減が必要な場合のみLambda filteringを検討する。

確認項目:

[ ] 実際のログ量測定（リクエスト数/日 = indexed logs/日）
[ ] 実際のエラー率測定（4xx/5xxの割合）
[ ] AWS月額コスト確認（KDS + Firehose + CloudFront Real-time Logs）
- 想定: 約$25.38/月（200M requests/月、20GB/月の場合）
[ ] Datadog月額コスト確認（$3.188/1M indexed logs、行数ベース課金）
- 想定: 約$637.60/月（200M requests/月 = 200M indexed logs）
[ ] 合計コスト: 約$663/月（100%サンプリング時）
[ ] 404 Bot検知の実績（何件検知できたか）
[ ] 誤検知の有無（閾値調整が必要か）
[ ] Distribution別タグ付け動作確認（distribution_name:fastdoctor-jp）

閾値調整:

[ ] パターン1（高頻度404）: 100回/5分 → 調整必要か？
[ ] パターン2（スキャン）: 50回/10分 → 調整必要か？
[ ] パターン3（特定UA）: 50リクエスト/10分 → 調整必要か？

コスト最適化の判断（実測値に基づいて判断）:

[ ] 実測コストが許容範囲内（約$663/月） → 100%継続（全ログ出力、最もシンプル、推奨）
[ ] 実測コストが許容できない → 以下のいずれかを選択:
- Lambda filteringでエラーログのみ（$663 → $57.28/月、91%削減、全件検知維持）
  - Lambda: $0.02/月（20,000 invocations、128MB、500ms）
- サンプリング率を10%に削減（$663 → $66.30/月、ただしログ欠損リスク、非推奨）

期間: 1-2週間（評価） → 閾値調整・Lambda filtering導入判断 → 継続運用

成果物:

実測コスト詳細（AWS: KDS/Firehose/CloudFront Real-time Logs、Datadog: ログ取り込み、行数ベース）
実測ログ量（リクエスト数/日 = indexed logs/日）
実測エラー率（4xx/5xxの割合）
Bot検知実績レポート（検知件数、誤検知、対応内容）
調整後の閾値設定
コスト最適化方針（100%継続 or Lambda filtering導入）

16.4 Phase 3: 他のDistributionsへ段階的展開

展開戦略: fastdoctor.jpでの実績を元に、他のDistributionsへ順次展開

各Distributionの展開ステップ:

Terraform適用:

bash

# Distribution専用リソース作成
terraform apply -target=module.cloudfront_realtime_logs_{distribution_name}

初期評価（1週間）:
- [ ] Distribution別のログ量測定
- [ ] Distribution別のコスト確認
- [ ] 404検知ロジックの動作確認
- [ ] fastdoctor.jpで調整した閾値が適切か確認
閾値のDistribution別調整:
- トラフィック特性に応じて閾値を微調整
サンプリング率調整:
- Distribution重要度に応じて調整

並行展開の判断基準:

✅ fastdoctor.jpで安定運用できている
✅ Terraformモジュールが確立している
✅ 閾値のベースラインが確定している → 複数Distributionsに展開可能

16.5 継続運用フェーズ

Phase 3完了後の運用:

月次レビュー:

[ ] Distribution別コスト確認
[ ] Bot検知実績サマリ
[ ] 誤検知・見逃しの有無確認
[ ] 閾値・サンプリング率の再調整判断

四半期レビュー:

[ ] 全Distributionのサンプリング率最適化
[ ] コスト vs 検知精度のバランス評価
[ ] 新しいDistribution追加計画

リスクと対策

本設計で採用するアーキテクチャにおいて想定されるリスクとその対策を記載します。

17.1 コスト急増リスク（On-Demand特有）

リスク内容

On-Demandモードはデータ量ベース課金のため、異常なトラフィック増加でコストが急増する

主なシナリオ：

DDoS攻撃: CloudFront Distribution への大量アクセス
設定ミス: サンプリング率100%のまま運用継続
無限ループ: アプリケーション側のバグで同じリクエストを繰り返す
予期しないバズ: SNS等で拡散され、トラフィックが急増

影響範囲:

通常時:  1 GB/日 × 30日 = 30GB → $1.20/月
DDoS時: 100 GB/日 × 1日 = 100GB → $4.00/日（通常の100倍）

Provisionedとの比較:

Provisioned: 固定コスト（トラフィック増でも料金変わらず）
On-Demand: トラフィック比例（DDoS時は高額）

→ On-Demand採用の理由は低トラフィック時の圧倒的なコスト効率（96%削減）だが、異常時のリスクを認識

対策

対策1: 週次コストモニタリング（ベースライン）

コスト監視設計書での定期モニタリング:

詳細はコスト監視設計書を参照してください。

週次でのコスト傾向確認:

CloudFront Real-time Logs関連のコスト推移
Distribution別のコスト集計
異常なコスト増加の早期発見

⚠️ 制約:

週次レビューのため即時検知ができない
DDoS攻撃やトラフィック急増時、数日間コストが発生し続ける可能性
即時検知が必要な場合は、対策2のDatadog Monitorを併用

対策2: Datadog Monitor（即時検知）

KDS IncomingBytes監視設定例（クリックで展開）

yaml

名前: [CloudFront RT] KDS異常トラフィック検知 - コスト急増の可能性
タイプ: Metric Monitor
メトリクス: aws.kinesis.incoming_bytes{stream:cloudfront-realtime-logs-*}
条件: avg(last_5m) > 10485760  # 10 MB/sec = 通常の25倍
優先度: P2 (High)
通知先: Slack (#squad-sre-noti-security)

メッセージ:
[CloudFront RT] KDS異常トラフィック検知 - コスト急増の可能性

Distribution: {{stream.name}}
現在のトラフィック: {{value}} bytes/sec (通常: 400 KB/sec)

確認事項:
1. CloudFront Distribution へのアクセス状況確認
   - AWS Console: CloudFront > Monitoring
   - Datadog: CloudFront Dashboard
2. DDoS攻撃の可能性確認
   - WAF Web ACL のログ確認
   - 特定IPからの大量アクセス
3. サンプリング率設定確認
   - CloudFront Real-time Logs configuration
4. 緊急対応:
   - サンプリング率を10%または1%に削減
   - CloudFront Real-time Logs を一時的に無効化（極端なケース）

検知の利点:

✅ 即時検知: 5分間隔でトラフィック異常を検知
✅ コスト急増前に対処可能
✅ Distribution別に監視（完全分離アーキテクチャ）

対策3: 初期評価期間での早期サンプリング率削減

戦略:

初期1-2週間: サンプリング100%で評価
コスト・検知精度を確認後、速やかに10%へ削減
Distribution別に調整可能（重要度に応じて）

変更履歴

日付	バージョン	変更内容	担当チーム	担当者
2026-03-24	1.0	初版作成	SRE	大賀

CloudFront Real-time Logs 監視設計書 ​

ドキュメント情報 ​

関連ドキュメント ​

目次 ​

背景・目的 ​

1.1 背景 ​

1.2 目的 ​

要件 ​

2.1 機能要件 ​

2.2 非機能要件 ​

対象範囲 ​

3.1 対象CloudFront Distribution ​

3.2 監視対象 ​

アーキテクチャ設計 ​

4.1 全体構成 ​

4.2 完全分離アーキテクチャを採用する理由 ​

4.2.1 設計方針の選択 ​

4.2.2 完全分離を採用する理由 ​

理由1: 障害影響範囲の最小化（SPOF回避） ​

理由2: Distribution別のカスタマイズが可能 ​

理由3: 権限管理の明確化 ​

理由4: コスト可視化 ​

理由5: ライフサイクル管理の柔軟性 ​

理由6: コスト差が小さい（On-Demandモード採用時） ​

4.2.3 採用アーキテクチャ ​

4.3 データフロー図（Distribution単位） ​

4.4 コンポーネント一覧 ​

4.5 データフロー ​

4.6 S3ログの位置づけ ​

Real-time Logsフィールド設計 ​

5.1 採用フィールド ​

Kinesis Data Streams設計 ​

6.1 容量モード選択 ​

6.2 KDS設計（Distribution単位） ​

6.3 スループット上限（参考） ​

6.4 監視 ​

6.5 リテンション ​

Kinesis Firehose設計 ​

7.1 Firehose設計（Distribution単位） ​

7.2 送信先 ​

7.3 バッファ設定 ​

7.4 S3 Backup設計（Distribution別バケット） ​

7.5 認証 ​

7.6 配信失敗監視 ​

Datadog統合設計 ​

8.1 ログ整形/タグ ​

8.2 Datadog Logs Pipeline設計 ​

8.3 Datadog Dashboard設計 ​

404 Bot検知ロジック ​

9.1 検知パターンと閾値 ​

パターン1: 同一IPからの高頻度404（Distribution別） ​

パターン2: 特定UAの異常（Distribution別） ​

9.2 判断フロー ​

9.2.1 IP Block判断フロー ​

9.2.2 UA Block判断フロー ​

定期モニタリング ​

10.1 監視アプローチ ​

監視に使用するデータソース ​

実現できる分析 ​

Log-based Metricsが必要になるケース（将来検討） ​

10.2 定期モニタリング手順 ​

日次レビュー ​

週次レビュー ​

10.3 WAF運用フローとの連携 ​

連携フロー ​

KDS/Firehoseの健全性監視 ​

11.1 監視対象メトリクス ​

必要最低限の監視メトリクス ​

追加検討が必要な場合のメトリクス（参考） ​

11.2 Datadog Monitor設定例 ​

11.3 S3 Backupの確認手順 ​

WAF連携設計 ​

12.1 ブロック方針 ​

IP Block ​

UA Block ​

12.2 運用フロー（Bot検知 → WAF対応） ​

フロー概要 ​

Step 1: アラート受信（0分） ​

Step 2: ログ確認 - IP/UA分析（5分以内） ​

Step 3: 脅威評価 - IP/UAパターン分析（10分以内） ​

CloudFront Real-time Logs 監視設計書

ドキュメント情報

関連ドキュメント

目次

背景・目的

1.1 背景

1.2 目的

要件

2.1 機能要件

2.2 非機能要件

対象範囲

3.1 対象CloudFront Distribution

3.2 監視対象

アーキテクチャ設計

4.1 全体構成

4.2 完全分離アーキテクチャを採用する理由

4.2.1 設計方針の選択

4.2.2 完全分離を採用する理由

理由1: 障害影響範囲の最小化（SPOF回避）

理由2: Distribution別のカスタマイズが可能

理由3: 権限管理の明確化

理由4: コスト可視化

理由5: ライフサイクル管理の柔軟性

理由6: コスト差が小さい（On-Demandモード採用時）

4.2.3 採用アーキテクチャ

4.3 データフロー図（Distribution単位）

4.4 コンポーネント一覧

4.5 データフロー

4.6 S3ログの位置づけ

Real-time Logsフィールド設計

5.1 採用フィールド

Kinesis Data Streams設計

6.1 容量モード選択

6.2 KDS設計（Distribution単位）

6.3 スループット上限（参考）

6.4 監視

6.5 リテンション

Kinesis Firehose設計

7.1 Firehose設計（Distribution単位）

7.2 送信先

7.3 バッファ設定

7.4 S3 Backup設計（Distribution別バケット）

7.5 認証

7.6 配信失敗監視

Datadog統合設計

8.1 ログ整形/タグ

8.2 Datadog Logs Pipeline設計

8.3 Datadog Dashboard設計

404 Bot検知ロジック

9.1 検知パターンと閾値

パターン1: 同一IPからの高頻度404（Distribution別）

パターン2: 特定UAの異常（Distribution別）

9.2 判断フロー

9.2.1 IP Block判断フロー

9.2.2 UA Block判断フロー

定期モニタリング

10.1 監視アプローチ

監視に使用するデータソース

実現できる分析

Log-based Metricsが必要になるケース（将来検討）

10.2 定期モニタリング手順

日次レビュー

週次レビュー

10.3 WAF運用フローとの連携

連携フロー

KDS/Firehoseの健全性監視

11.1 監視対象メトリクス

必要最低限の監視メトリクス

追加検討が必要な場合のメトリクス（参考）

11.2 Datadog Monitor設定例

11.3 S3 Backupの確認手順

WAF連携設計

12.1 ブロック方針

IP Block

UA Block

12.2 運用フロー（Bot検知 → WAF対応）

フロー概要

Step 1: アラート受信（0分）

Step 2: ログ確認 - IP/UA分析（5分以内）

Step 3: 脅威評価 - IP/UAパターン分析（10分以内）