AWS Systems Managerとは

AWSリソースだけでなくオンプレミスに構築されたサーバも対象とし、運用負荷を大幅に減らすことができる。
一口にSystems Managerといっても機能は多岐にわたり、2022/06時点では18もの機能が存在する。
https://aws.amazon.com/jp/systems-manager/features/#Explorer

本記事ではSystems Managerの中でも、インシデント管理を行うIncident Manager関して記載する。

Incident Managerとは

CloudWatchAlarmやEventBridge(旧CloudWatchEvents)のイベントをトリガーとして
インシデント起票し、その後の自動復旧の実行や、メール/電話による通知が可能なサービス。
昨今話題のSOAR(Security Orchestration, Automation and Response)に近いサービス。

インシデントへの対応プランと連絡先を定義できる
インシデント発生時に対応するためのRunbook(コマンドや手順内容をまとめたもの)を自動実行
エスカレーション先として、Slack、メール、電話を選択可能。
以下のような細かい制御も可能
- 検知後0分でメール、5分で電話連絡
- 第一担当者不在時には第二担当者へ連絡
エスカレーション連絡が来た後の解決と分析を定義
PDCAサイクルを回し、次回以降のアクションの向上に役立つ

やりたいこと

CloudWatchで検知したアラートをIncident Managerに集約する
運用負荷を減らすためメール通知をなるべく削減する

設定例

以下を参考に実施

不明点の問い合わせ

重複排除文字列

重複除外文字列を指定します。Incident Manager は、重複除外文字列を使用して、同じ根本原因が同じアカウントに複数のインシデントを作成しないようにします。

この「重複排除文字列」という言葉から察するに、入力した文字列を含む内容は、1回目は通知され2回目以降は通知抑制されるものと推測。
結果としては、ここに入力しなくても抑制できるとのこと。
以下サポートからの回答

重複排除文字列を入力せずとも同じCloudWatchAlarm / EventBridgeイベントから
作成されるインシデントは同じものとなる。
（例）
複数インスタンスでCPU使用率が80%を超えると発報するアラームを設定したとして、
　インスタンスAのCPU使用率80% → ALARM
　インスタンスAのCPU使用率50% → OK
　インスタンスAのCPU使用率80% → ALARM
と2回アラームが発報してもインシデントを解決していなければ
重複してインシデントが作成されることはない。
一方で、インスタンスBでCPU使用率が80%を超えて発報した場合は
別のインシデントとして作成される。

因みに、重複除外文字列を指定した場合どうなるかも問い合わせたが、
同じ対応プランから作成されたインシデントは、
作成のされ方に関わらず同じインシデントとなるそう。

これは非常にわかりづらい記載だったので、
是非ともドキュメントを修正してもらいたい。

料金

1対応プランにつき100件のSNSまたは音声メッセージ含め7$/月
大量のプランを作成するとなかなかの金額となってしまうので精査が必要。
https://aws.amazon.com/jp/systems-manager/pricing/