変更要約: DOP-C02 第5章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
5.1イベント駆動の自動化
イベントへの自動応答——EventBridge（ルール/ターゲット）、CloudWatch アラーム、EventBridge Scheduler、SNS/SQS——を理解します。状態変化をきっかけに処理を自動起動します。
インシデント対応の起点はイベントの検知です。EventBridge やアラームでイベントを受け、自動で処理を起動します。
5.1.1イベントのルーティング
- EventBridge：AWS サービスの状態変化イベントをルールでフィルタし、ターゲットへルーティング。
- ターゲット：Lambda / SSM Automation / Step Functions / SNS などで自動処理。
- EventBridge Scheduler：cron/レート式で定期実行をスケジュール。
- SNS/SQS：SNS=通知のファンアウト、SQS=バッファ/再試行で疎結合に処理。
「サービスの状態変化に反応＝EventBridge ルール」「定期実行＝EventBridge Scheduler（または CloudWatch Events ルール）」「自動処理のターゲット＝Lambda/SSM Automation/Step Functions」 は DOP-C02 で頻出です。GuardDuty/Config/CodePipeline などの検出を EventBridge で受け、自動対応につなぐのが定番です。
DOP-C02 では「イベントをどう受け、どこへ確実に届けるか」が問われます。EventBridge のイベントパターンは JSON で source・detail-type・detail をマッチさせ、必要に応じてインプットトランスフォーマーでターゲットへ渡す形に整形します。AWS サービスの状態変化はデフォルトイベントバスに流れ、SaaS/自社アプリのイベントはカスタムバスやパートナーイベントソースで受けます。スキーマレジストリでイベント構造を管理でき、複数アカウントのイベントはバス間のルーティングで集約します。定期処理は従来の「ルール（cron/rate）」に加え、より柔軟でタイムゾーンや一回限り実行に対応する EventBridge Scheduler が推奨されます。配信の信頼性のために、ターゲットへの配信失敗時はリトライポリシーと DLQ を設定し、取りこぼしを防ぎます。通知の SNS は Email/SMS/HTTP/Lambda/SQS へファンアウトし、メッセージフィルタリング（サブスクリプションフィルターポリシー）で購読者ごとに必要なメッセージだけを配信できます。SQS はバッファとして取り込み側のスパイクや一時障害を吸収し、順序保証が要るなら FIFO を使います。これらを組み合わせ、状態変化を起点に通知・チケット起票・自動修復へ分岐させるのがイベント駆動運用の基本形です。
| 要件 | サービス/機能 | 要点 |
|---|---|---|
| 状態変化に反応 | EventBridge ルール | イベントパターンでフィルタ→ターゲット |
| 柔軟な定期実行 | EventBridge Scheduler | cron/rate・タイムゾーン・一回限り |
| 複数宛先へ通知 | SNS（ファンアウト） | フィルタポリシーで選別配信 |
| 取り込みのバッファ/再試行 | SQS | スパイク吸収・FIFO で順序保証 |
シナリオ：本番アカウントの GuardDuty 検出と Config 違反を、セキュリティ専用アカウントに集約して一元的に自動対応したい。→ 各アカウントのデフォルトイベントバスから、ルールで該当イベントをセキュリティアカウントのカスタムバスへクロスアカウント転送。集約先のルールで重大度に応じて Lambda/SSM Automation を起動し、配信失敗に備えて各ターゲットに DLQ を設定します。
FAQ：EventBridge ルールのスケジュールと EventBridge Scheduler はどちらを使う？ 単純な定期トリガで既存運用に組み込み済みならルールでもよいですが、新規はおおむね EventBridge Scheduler が推奨です。タイムゾーン対応・一回限りのスケジュール・柔軟な再試行/フレックスウィンドウ・大量スケジュールのスケールに優れます。
ひっかけ：EventBridge のターゲット呼び出しが失敗しても、DLQ を設定していないとイベントは失われます。重要な自動対応では必ずリトライポリシー＋DLQ を構成します。また「複数の購読者に同じイベントを配信」は SNS ファンアウト/複数ターゲットであり、SQS 単体は 1 メッセージを 1 コンシューマが処理する点（ファンアウトには SNS→複数 SQS が必要）に注意します。
5.1.2この節のまとめ
- 検知/ルーティング＝EventBridge（ルール→ターゲット）
- 定期＝Scheduler／通知＝SNS／バッファ＝SQS
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. GuardDuty が脅威を検出したら、自動で隔離用の Lambda を起動したい。検出をどこで受けますか？
Q2. 毎日深夜に定期的にメンテナンス用の自動化を実行したい。何を使いますか？
Q3. 1 つのインシデントイベントを、通知・チケット起票・自動修復の複数処理へ同時に届けたい。何を使いますか？