CloudWatchのアラームから通知先までを段階別にテストする

Conclusion

この記事の結論

2リージョンでSNSへの直接送信が成功しました。アラーム発火と最終受信は別の試験で確かめます。

監視メールには、アラームの状態が変わる、通知先トピックにイベントが渡る、購読先が受け取る、という複数の区間があります。通知トピックに直接送信する試験は、前半のアラーム判定を通りません。どこからどこまでを試したかを書かないと、通知経路全体が正常と誤解されます。

今回の対応

11月1日、CloudWatchに11件のアラームを追加し、2つのリージョンでSNSの購読状態を確認しました。それぞれ1回ずつ直接テスト送信を行い、SNSのAPIが両方を正常に受け付けたことを確認しました。

2つのリージョンの購読状態を確認し、それぞれ直接送信を1回ずつ行いました。APIが受け付けたことは応答で確認できます。一方、メールが届いたかは受信側の記録が必要です。テストを送った直後に届かなかったときは、すぐ同じメールを繰り返すより、送信時刻・リージョン・購読の対応を先に照合します。

アラーム経由を確認する場合は、対象のアラームで観測した状態遷移と、同じタイミングの通知を結びます。通常運用に不要な障害を発生させる必要はありません。今回は11アラームの追加、購読状態、直接送信の受付までを確認し、強制的な発火や受信者の開封は試験に含めていません。

対応手順を図で確認

確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認