AWS通知を3層に分離して通知疲れを軽減する設計戦略
歴史シミュレーションゲーム好きのくろすけです！
AWS の監視設計を考えていると、CloudWatch のアラート、AWS Health の通知、AWSアカウントの代替連絡先に届くメールなど、通知の入口がいろいろあって少し混乱しますよね。
便利な一方で、「これは今すぐ反応すべき通知なのか？」「あとで確認すればよい通知なのか？」が混ざってしまい、通知疲れしやすいのも事実です。
そこで今回は、自分なりに整理した AWS 通知の使い分けをまとめてみます。
概要
今回整理した考え方は、次の3層です。
また、通知が埋もれてしまうことを防ぐためにそれぞれ通知先のメールグループを分けるのが良いと考えています。
- CloudWatch Alarm などを用いたカスタム監視通知: 即時対応が必要な通知
- AWS Health からの保守通知: 計画的な対応が必要な通知
- AWS アカウントの代替連絡先: INFO 的な通知
この分け方の良いところは、通知の意味が整理されることです。
- 「障害対応のための通知」
- 「保守や変更対応のための通知」
- 「参考情報として知っておく通知」
これらを役割ごとに分けることで、通知疲れを減らしつつ、本当に見るべきものを見落としにくくできます。
やってみた
今回の検討では、AWS の通知をざっくり次のように整理しました。
1. CloudWatch Alarm などを用いたカスタム監視通知
まず、運用者がすぐに反応すべきものは CloudWatch Alarm などのカスタム監視に寄せるのが良いと考えます。
例えば、次のようなものです。
- ALB の 5xx エラー
- 不健全ターゲットの発生
- Lambda のエラー急増
- WAF の BlockedRequests 急増
- GuardDuty / Security Hub の高重大度 Finding
これらは「今、システムで異常が起きている」ことを伝える通知なので、即時対応の導線に乗せるべきです。
逆にメンテナンスなど AWS 側の都合で起きるイベントは公式より別途通知方法が提供されているため、カスタマイズする必要はありません。
2. AWS Health からの保守通知
次に、AWS Health で受けるべきなのは「即時障害ではないが、利用者側の対応や判断が必要な通知」です。
具体的には、次のようなイベントが該当します。
- ECS / Fargate のタスク退役予定
- ElastiCache のメンテナンス通知
- Lambda の将来の仕様変更や廃止予定に関する通知
- RDS / Aurora のエンジンアップグレードや将来の変更予定に関する通知
これらは緊急障害ではありませんが、無視してよいわけでもありません。
例えば、
- 事前に関係者へ保守時間を共有する
- 作業日程を見直す
- バージョンアップや移行の計画を立てる
といった対応につながります。
AWS Health の中には即時対応が必要な通知も含まれることがあります。
一方で、DescribeEventTypes で eventTypeCode は取得できるものの、各イベントの詳細な発火条件や通知粒度までは把握しづらいため、即時通知の主経路として使うには少し不安が残ると感じました。
よって、AWS Health は意図的に「保守運用・変更管理のための通知」として限定して使うことで、クリティカルなイベントを見逃してしまうリスクを回避できると考えています。
ちなみに、RDS のメンテナンスのイベント通知についても AWS Health と同じメールグループで受けると整理が良さそうです。
3. AWSアカウントの代替連絡先
最後に、すぐに何かしなくてもよい通知や、参考情報に近い通知は、AWSアカウントの代替連絡先に寄せる整理です。
AWS アカウントをお使いの場合に、多くは代替連絡先を登録し、通知を受け取っているかと思います。
例えば、次のような通知です。
- 請求や支払いに関する通知
- AWS からの個別フォローや案内
- サービス運用に関する一般的な案内
- 一部のセキュリティ関連の案内通知
- 今すぐの判断や作業に直結しない案内
こちらの通知は様々な情報が雑多に通知されるため、特に通知疲れしやすいと思います。
AWS 側でフィルタリングもできないため、通知元で通知の役割を一括制御することが難しいと考えます。
そのため、AWSアカウントの代替連絡先で受けつつ、必要に応じて後追い確認するくらいがちょうどよいと感じました。
今回のポイント
今回悩んだ点は、AWS Health の位置づけでした。
最初は「Health にも緊急度の高い通知含まれるなら、保守通知に加えて一部のシステム監視通知も担えるのでは？」と考えました。
ただ、上述の通りイベントごとの詳細な発火条件や通知の粒度まで読み取りやすいとは言いづらく、即時対応の主通知として任せるには少し不安が残りました。
そのため今回は、AWS Health は保守運用・変更管理向けの通知として使う前提で整理しました。
あとがき
途中で単一の通知フローで全て賄えるか？とも思いましたが、やはり役割ごとに分ける方が整理しやすいと思います。
また、通知先をそれぞれ分けておくことでより迅速な初動対応を実現できると考えています。
より良い通知フローの整理方法があれば、ぜひ教えてください！
以上、くろすけでした！
