AWS Health アラートはなぜ混沌としているのか
AWS で本番サービスを運用していると、インフラに問題が発生した際、まず AWS Health Dashboard を確認するかと思います。しかし、問題はアラートの量です。サービス障害、計画メンテナンス、アカウント通知、非推奨の告知まで、あらゆるイベントが一つのチャネルに流れ込んできます。
ここでジレンマが発生します。
- すべてのアラートを重要なものとして扱うと、ノイズが多すぎて本当に重要なイベントを見逃す可能性があります。
- アラートを無視し始めると、致命的な障害やサービスの非推奨化など、重要な知らせを見逃すリスクがあります。
結局のところ、アラートを適切に「分類」することが重要です。この記事では、AWS User Notifications を活用し、アラートを優先度に応じて分離し、組織が必要とするサービスのイベントのみを受信する方法を段階的に紹介します。最後には、プロセス全体を自動化する CloudFormation テンプレートも提供しますので、すぐに実務へ適用できます。
解決策: 「フィルタリング後、優先度で分離」する2段階戦略
提案する構成は非常にシンプルです。1) フィルタリング で重要なサービスのイベントのみを残し、2) 優先度 に応じてアラートを分離します。
ステップ 1: アラートのフィルタリング
AWS Health で発生するすべてのイベントを受け入れるのではなく、組織が依存するサービス（例: Amazon RDS, AWS Direct Connect）のイベントのみにマッチするルールを作成します。これにより、関連のないサービスからのノイズを最初から遮断できます。
ステップ 2: 優先度の分離
フィルタリングされたイベントは、さらに2つのグレードに分けられます。
- CRITICAL (重要): サービス障害 (
issue) や計画された変更 (scheduledChange) など、即時対応が必要なイベント。メールで即座に単独送信されます。 - INFORMATIONAL (情報): アカウント通知 (
accountNotification) など、参考用のイベント。5分間バッチ処理され、要約版として送信されます。
これにより、メールが届いたとき、単独メールなら「今すぐ確認すべきこと」、バッチメールなら「後で確認してもよい通知」であるとすぐに判断できます。
CloudFormation テンプレートで一括デプロイ
この一連のプロセスをまとめた CloudFormation テンプレートを作成しました。テンプレートをデプロイすると、以下のリソースが自動的に作成されます。
- 監視対象サービスの指定: デフォルトで Direct Connect、Connect Customer、RDS が含まれます。パラメータを変更することで、任意のサービスを追加できます。
- 2つの通知設定: CRITICAL イベント用と INFORMATIONAL イベント用の通知設定が自動生成されます。
- メール配信チャネルの接続: デプロイ時に入力したメールアドレスが通知設定に自動的に関連付けられます。
参考: AWS 公式ブログで提供されている CloudFormation テンプレートと詳細ガイド で、より詳細な情報を確認できます。
デプロイモード
テンプレートは、デプロイ範囲に応じて4つのモードをサポートしています。
| モード | 適用範囲 | 提供機能 |
|---|---|---|
| Linked (デフォルト) | 単一アカウント | メール連絡先、User Notifications イベントルール、チャネル関連付け |
| Payer | 組織全体または OU | Linked の機能 + 組織単位の関連付け |
| Combined | 単一アカウント | Linked の機能 + EventBridge ルールと SNS カスタムメール |
| PayerCombined | 組織全体または OU | Payer の機能 + EventBridge ルールと SNS カスタムメール |
通知設定の確認
CloudFormation テンプレートをデプロイした後、以下のコマンドで通知設定が正しく作成されたか確認できます。
# 通知設定のリストを確認
aws notifications list-notification-configurations --region <リージョン>
# 特定の通知設定の詳細を確認
aws notifications get-notification-configuration --configuration-arn <設定 ARN>
get-notification-configuration コマンドを実行すると、aggregationDuration の値が NONE (CRITICAL) または SHORT (INFORMATIONAL) となっていることを確認できます。これにより、イベントが即時送信されるのか、5分間バッチ処理されるのかを判別できます。
イベント発生テスト
実際にイベントが発生した際に、通知が正しく届くか確認してみましょう。
- AWS Health Dashboard で監視対象サービスにイベントが発生すると、CRITICAL アラートは即座に単独メールで受信されます。
- INFORMATIONAL アラートは5分以内にバッチ処理された要約メールで受信されます。
このパターンを覚えておくだけで、アラートを効率的に管理できます。
知っておくべき注意点とトレードオフ
このソリューションは意図的に「軽量」に設計されていますが、いくつかのトレードオフがあります。
- メール形式のカスタマイズ不可: AWS User Notifications が生成するメール本文と件名は変更できません。メール本文に
[CRITICAL]のようなテキストを入れたい場合は、Combined モード を使用して EventBridge と SNS レイヤーを追加する必要があります。この場合、メール本文に[CRITICAL]または[INFORMATIONAL]というプレフィックスが付与されます。 - 重複排除機能なし: AWS Health イベントには「作成 -> 更新 -> 解決」というライフサイクルがあり、各段階で通知が送信されます。1つの障害に対して2〜4通のメールを受信する可能性があります。厳格な重複排除が必要な場合は、AWS Health Aware (AHA) などのツールを追加で検討する必要があります。
- エスカレーションおよび承認機能なし: 通知を送信することに焦点を当てており、誰かが通知を確認したかどうかは追跡しません。オンコールルーティングやエスカレーションが必要な場合は、PagerDuty や OpsGenie などのツールとの連携を推奨します。
- 履歴保存機能なし: 通知はリアルタイムで配信されますが、後で分析できるように保存されるわけではありません。事後分析が必要な場合は、HEIDI や CID などのダッシュボードツールと併用することをお勧めします。
この技術の限界または注意点
CloudFormation スタックを削除しても、DeletionPolicy: Retain オプションにより、通知設定、イベントルール、メール連絡先などは削除されずに残ります。スタック削除後は、AWS User Notifications コンソールからリソースを手動でクリーンアップする必要があります。
まとめ: アラート管理をよりスマートに
この記事では、AWS Health アラートを優先度に応じて効果的に管理する方法を紹介しました。提案したソリューションは、特別なコードやサーバーを必要とせず、AWS ネイティブサービスのみで構成されており、CloudFormation テンプレートを1つデプロイするだけで即座に利用を開始できます。
このソリューションは、単なる通知ツール以上の価値があります。
- 単独メール は「今すぐ確認すべきこと」
- バッチメール は「後で確認してもよい通知」
この2つのパターンを区別するだけで、運用効率は大幅に向上するでしょう。
次のステップとしての学習方向性
- AWS Chatbot 連携: Slack や Microsoft Teams に通知を送りたい場合は、AWS Chatbot の設定を試してみてください。
- PagerDuty 連携: 障害エスカレーションやオンコール管理が必要な場合は、SNS トピックを PagerDuty に接続する方法を学んでみてください。
- AHA (AWS Health Aware) の導入: より複雑な通知ルーティングや重複排除機能が必要な場合は、AHA フレームワークの調査を検討してみてください。