AWS Health Dashboard で構築するインシデント管理 - 障害通知の自動化と影響分析
サービス障害の検知から EventBridge 連携の自動通知、Organizations 統合による組織全体の影響分析までを一貫して紹介します。
Health Dashboard の 2 つのビュー
Health Dashboard はサービスヘルス (全 200 以上の AWS サービスの稼働状況) とアカウントヘルス (自アカウントに影響するイベント) の 2 つのビューを提供します。サービスヘルスは AWS サービス全体の稼働状況を表示し、リージョンごとのサービス障害を確認できます。アカウントヘルスは自分のアカウントに影響するイベントのみを表示し、EC2 インスタンスのメンテナンス予定、RDS の計画的フェイルオーバー、EBS ボリュームの障害通知など、具体的なリソースに紐づいた情報を提供します。アカウントヘルスのイベントは影響を受けるリソースの ARN が含まれるため、対応が必要なリソースを即座に特定できます。イベントは issue (障害)、accountNotification (計画メンテナンス)、scheduledChange (予定変更) の 3 カテゴリに分類され、カテゴリごとに対応の緊急度が異なります。issue は即座の対応が必要ですが、scheduledChange は数日から数週間の猶予があるため、通知先やエスカレーションルールをカテゴリ別に設計することで運用負荷を最小化できます。
EventBridge 連携による自動通知
Health イベントは EventBridge に自動送信されるため、イベントルールで特定のイベントタイプをフィルタリングし、Lambda や SNS にルーティングできます。EC2 のメンテナンス通知を Slack チャネルに自動投稿し、影響を受けるインスタンスの一覧を添付するワークフローが典型的です。Lambda 関数で Health イベントを受け取り、影響を受けるインスタンスを Auto Scaling グループから一時的に除外し、メンテナンス完了後に復帰させる自動対応も実装可能です。AWS Chatbot と組み合わせると、Slack チャネルに Health イベントのリッチな通知が自動投稿されます。EventBridge ルールのイベントパターンでは source を aws.health、detail-type を AWS Health Event に指定し、detail.service や detail.eventTypeCategory でさらにフィルタリングします。us-east-1 リージョンのルールでグローバルイベント (IAM、Route 53、CloudFront の障害) を受信する設計が必要で、他リージョンのルールではリージョナルサービスのみが対象です。この設計を見落とすとグローバルサービスの障害通知を取りこぼします。
Organizations 統合と組織全体の監視
Organizations の Health API (Organizational View) を有効にすると、組織内の全アカウントの Health イベントを管理アカウントまたは委任管理者アカウントから集約して確認できます。数百のアカウントを運用する大規模組織では、個別アカウントの Health Dashboard を確認するのは非現実的です。 Organizational View で全アカウントのイベントを一元監視し、影響範囲の大きいイベントを優先的に対応します。 EventBridge ルールで組織全体の Health イベントを集約し、セキュリティチームや運用チームに一括通知する構成が推奨されます。 Health Dashboard の基礎から応用まで、書籍 (Amazon)で体系的に学べます。
インシデント対応ワークフローの設計パターン
Health Dashboard を中核としたインシデント対応は 3 段階で設計します。第 1 段階 (検知) では EventBridge ルールがイベントを受信し、SNS 経由で運用担当者に即座に通知します。第 2 段階 (トリアージ) では Lambda 関数が影響を受けるリソースの一覧を取得し、Systems Manager OpsCenter に OpsItem として自動起票します。OpsItem には関連する CloudWatch アラーム、影響リソースの ARN、推奨アクションが紐づけられるため、担当者は単一の画面から対応を開始できます。第 3 段階 (自動修復) では Systems Manager Automation ランブックを起動し、定型的な対応 (インスタンスの再起動、スナップショットからの復元、DNS のフェイルオーバー) を人手を介さず実行します。この 3 段階設計により、夜間の障害でもオンコール担当者が起きる前に復旧が完了するケースを増やせます。PagerDuty や Opsgenie との統合では、Health イベントの severity フィールドに基づいてエスカレーションポリシーを自動選択する設計が有効です。
CloudWatch や他サービスとの使い分け
Health Dashboard はAWS インフラ側の障害を通知するのに対し、CloudWatch Alarms はアプリケーションメトリクスの異常を検知します。両者は補完関係にあり、併用が前提です。例えば EBS ボリュームの I/O エラーは Health Dashboard から通知される一方、ボリュームの IOPS スロットリングは CloudWatch メトリクスで検知します。Trusted Advisor は設定上のリスク (セキュリティグループの開放、利用率の低いリソース) を検出しますが、リアルタイムの障害通知は行いません。AWS Fault Injection Simulator (FIS) はカオスエンジニアリングで意図的に障害を注入するツールであり、Health Dashboard の通知パイプラインが正しく動作するかの検証にも使えます。Systems Manager Incident Manager はインシデントのライフサイクル管理 (検知、エスカレーション、対応、振り返り) を統合するサービスで、Health Dashboard のイベントをトリガーとしてインシデントを自動起票する構成が大規模組織では標準的です。
Health Dashboard の料金
Health Dashboard は無料で利用できます。サービスヘルスとアカウントヘルスの閲覧、EventBridge へのイベント送信に追加料金は発生しません。Health API (Organizations の Organizational View) も無料です。コストが発生するのは EventBridge ルールの実行 (100 万イベントあたり約 1 ドル) と、通知先の SNS・Lambda の利用料金のみです。全 AWS アカウントで有効化すべき無料のセキュリティ基盤であり、導入しない理由はありません。実際のコストインパクトが最も大きいのは Lambda 関数の実行料金ですが、Health イベントの発生頻度は通常 1 アカウントあたり月数件から数十件程度であり、Lambda の無料枠 (月 100 万リクエスト) で十分に収まります。
まとめ
Health Dashboard は AWS サービスの障害とアカウント固有のイベントをリアルタイムに通知するサービスです。EventBridge 連携で自動通知と自動対応を構築し、Organizations 統合で組織全体の影響を一元監視します。3 段階のインシデント対応ワークフロー (検知、トリアージ、自動修復) を設計し、CloudWatch Alarms や Incident Manager と組み合わせることで、人手を介さない障害復旧を実現できます。