変更要約: DOP-C02 第5章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
5.3通知とエスカレーション
インシデントの通知と運用——SNS、EventBridge、Systems Manager Incident Manager、Chatbot（Slack/Teams 連携）、デッドレターキュー（DLQ）——を理解します。適切な相手へ確実に届け、対応を統制します。
検知・修復に加え、適切な相手への通知とエスカレーションが重要です。SNS や Incident Manager で対応を統制します。
5.3.1通知とインシデント管理
- SNS：通知を Email/SMS/HTTP/Lambda へファンアウトする。
- Chatbot：Slack/Teams に運用通知やアラームを連携する。
- Incident Manager：重大インシデントのエスカレーション計画・対応プラン・オンコールを統制。
- DLQ（デッドレターキュー）：配信/処理に失敗したメッセージを退避し、後で再処理する。
「通知のファンアウト＝SNS」「Slack/Teams 連携＝Chatbot」「重大インシデントの統制/オンコール＝Incident Manager」「失敗メッセージの退避＝DLQ」 は DOP-C02 で頻出です。Lambda や SQS の処理失敗を取りこぼさないよう DLQ を設定するのが定石です。
DOP-C02 では「適切な相手へ、適切な経路で、取りこぼさず届け、対応を統制する」運用設計が問われます。SNS は Email/SMS/HTTP(S)/Lambda/SQS/モバイルプッシュへファンアウトし、サブスクリプションフィルターポリシーで購読者ごとに必要なメッセージだけを配り、SNS 自体の DLQ（再ドライブ）で配信失敗を退避できます。チャット連携は AWS Chatbot（Amazon Q Developer in chat applications）で、Slack/Teams にアラームや CloudWatch のグラフを流し、チャットから承認済みコマンドを実行することもできます。重大インシデントは Systems Manager Incident Manager が対応プラン（response plan）・エスカレーション計画・オンコールスケジュール（ローテーション）・連絡先チャネルを統制し、発生時に自動でランブックを起動し、関係者を招集して事後分析（post-incident analysis）まで支援します。配信・処理の信頼性は DLQ が要で、Lambda の非同期呼び出しや SQS のコンシューマ失敗をメッセージごと退避して後で再処理（リドライブ）でき、原因調査も可能にします。設計の勘所は、通知の重大度に応じた経路分け（情報は Slack、重大はオンコール呼び出し）と、アラート疲れの抑制（複合アラーム・フィルタリング）です。これらは検知・自動修復と一体で、インシデント対応の MTTR とエスカレーションの確実性を高めます。
| 目的 | サービス | 要点 |
|---|---|---|
| 多経路への通知配信 | SNS | ファンアウト・フィルタポリシー・DLQ |
| チャットへの連携 | AWS Chatbot | Slack/Teams へアラーム/グラフ |
| 重大インシデントの統制 | Incident Manager | 対応プラン・オンコール・事後分析 |
| 失敗メッセージの保全 | DLQ | 退避→リドライブで再処理 |
シナリオ：軽微な警告はチャットで十分だが、本番停止級は担当者を電話で呼び出し、対応を統制したい。→ 重大度を SNS のサブスクリプションフィルターポリシーで振り分け、情報レベルは Chatbot 経由で Slack へ、重大レベルは Incident Manager の対応プランを起動してオンコールのエスカレーション（電話/SMS）と自動ランブックを発動。対応後は Incident Manager で事後分析を記録し、再発防止につなげます。
FAQ：SNS の通知だけで十分？ Incident Manager はいつ要る？ 単純な「通知を届ける」だけなら SNS（＋Chatbot）で十分です。重大インシデントの対応統制——オンコールのローテーション、段階的エスカレーション、対応プランの自動起動、事後分析の記録——が要るなら Incident Manager を使います。通知（SNS）と統制（Incident Manager）は役割が異なります。
ひっかけ：「処理に失敗したイベントを失わない」要件で DLQ を設定し忘れると、Lambda の非同期呼び出しや SQS のメッセージはリトライ上限後に破棄され、調査もできません。重要な非同期処理には必ず DLQ を構成します。また Chatbot は通知/承認実行の連携であって、インシデントの統制（オンコール/エスカレーション）は Incident Manager の役割です。
5.3.2この節のまとめ
- 通知＝SNS（ファンアウト）＋Chatbot（Slack/Teams）
- 統制＝Incident Manager／失敗退避＝DLQ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. アラート通知を Email・SMS・Lambda など複数の宛先へ同時に配信したい。何を使いますか？
Q2. 運用アラームやインシデント通知を Slack チャンネルに連携したい。何を使いますか？
Q3. Lambda がイベント処理に繰り返し失敗する。メッセージを失わずに後で調査・再処理したい。何を使いますか？