AWS Health Dashboardの使い方｜障害通知の自動化とAPI実装

AWS Health Dashboardは、AWSの障害・メンテナンス・アカウント宛の通知を1か所で見る画面です。画面を開く使い方は短時間で覚えられます。手が止まるのはその先。イベントをEventBridgeに流して自動で受け取ろうとすると、ルールを置いたリージョン次第で届かなかったり、同じ障害が二重に通知されたりします。この記事では、Health Dashboardが持つ画面とイベントの分類、EventBridgeのイベントパターンの書き方、取りこぼしと重複を避けるリージョン配置、Health APIのアクティブエンドポイント判定とboto3での取得、AWS Organizations全体の集約までを、公式ドキュメントの記述とサンプルペイロードに沿って組み立てます。

まとめ：AWS Health Dashboardで最初に決める3点

結論から置きます。ダッシュボードを開いて眺めるだけなら追加費用はかからず、サインインしないアカウントでも一般的なサービス稼働状況は確認できます。設計判断が要るのは次の3点です。

第1に、プログラムから扱うかどうか。AWS Health APIの公式ドキュメントは、APIの利用にAWS Business Support+、AWS Enterprise Support、またはAWS Unified Operationsのいずれかが必要だと明記しています。未加入のアカウントから呼ぶとSubscriptionRequiredExceptionが返るため、Basic SupportならEventBridge経由の通知で組み立てます。

第2に、EventBridgeルールをどのリージョンに置くか。標準パーティションでは各リージョンのイベントがus-west-2にも複製され、IAMなどのグローバルイベントはus-east-1にしか来ません。ここを知らずに東京リージョンだけにルールを置くと、拾えないイベントが残ります。

第3に、届いたイベントを誰に渡すか。ペイロードのactionabilityとpersonasを使わずに全件を1つのチャンネルへ流すと、通知は読まれなくなります。障害直後の初動そのものはAWS障害の確認方法と原因・対策の記事が扱うため、本記事は通知経路を組む側に絞ります。

AWS Health Dashboardが持つ3つの画面とイベントの分類

Health Dashboardは1つの名前ですが、中身は見える範囲の違う画面の集合です。旧Service Health DashboardとPersonal Health Dashboardが統合された経緯が、そのまま画面に残っています。

サインインの有無で変わる稼働状況ページとアカウント固有イベントの差

公式の開始ガイドは、サインイン後の画面を「アカウントのイベント」と「組織のイベント」に分けて説明しています。どちらも未解決・最近・予定された変更を持ち、イベントログでは過去90日分をさかのぼれます。アカウントを持たない状態でも一般的なサービス提供状況のページは見られますが、そこに出るのは全利用者に共通する事象だけです。

この差が実務で効きます。自分のEC2インスタンスが退役対象になった、RDSの証明書更新が必要になった、といった通知はアカウント固有イベントにしか出ません。公開ステータスページが全部緑でも、自分のアカウント宛の予定変更は別に届きます。障害発生直後の確認順序は2025年10月の大規模障害を題材にした実務ガイドが扱います。

eventTypeCategoryの4分類とstatusCodeで追う状態遷移

イベントの性格はeventTypeCategoryで分かれます。EventBridgeスキーマのリファレンスが挙げる値はissue、accountNotification、investigation、scheduledChangeの4つです。障害だけを拾いたいならissue、退役や証明書更新のような予定作業ならscheduledChangeを見ます。

状態はstatusCodeのopen・closed・upcomingで表されます。予定されたメンテナンスはupcomingで届き、開始するとopenに変わる仕組みです。同じリファレンスには、MAINTENANCE_SCHEDULEDを含むイベントは開始時刻のおよそ2週間前に配信されるとあり、計画停止の準備期間がここで決まります。

影響を受けたリソースはaffectedEntitiesに並び、各要素のstatusはIMPAIRED・UNIMPAIRED・PENDING・RESOLVED・UNKNOWNを取ります。計画的なライフサイクルイベントではこの状態更新が非同期で行われ、まれに最大72時間の遅れが出るとも書かれています。エンティティの状態だけを根拠に自動で作り直しを走らせる設計にはしないでください。

ダッシュボードの利用料金とサポートプランで変わるAPIの利用範囲

ダッシュボードの閲覧に料金はかかりません。分かれ目はAPIです。サポートプランの比較ページを2026年9月22日に確認したところ、プラン名はBasic Support、Business Support+、Enterprise Support、Unified Operationsの構成でした。日本語の解説記事で今も見かける「ビジネス／エンタープライズOn-Ramp／エンタープライズ」という3プランの表記は、この改称より前の情報です。

公式ドキュメント側も、旧体系から移行していない場合はBusiness、Enterprise On-Ramp、Enterpriseでも使えると補足しています。自社がどちらの体系かは請求画面のプラン名で判断してください。なおAWS Trusted Advisorの解説記事と混同されやすいものの、あちらは設定の推奨事項、Health Dashboardは事象の通知です。

EventBridgeでHealthイベントを受け取るルールを作る手順

手で画面を見に行く運用は、担当者が見ていない時間に穴が空きます。公式のEventBridge連携ページによれば、AWS Healthはイベントを永続的に配信し、少なくとも1回はEventBridgeへ届けようとします。ターゲットとして選択できるのは、Lambda関数、Kinesis Data Streams、SQSキュー、組み込みターゲット、SNSトピックです。

source aws.healthを起点にしたイベントパターンの書き方

イベントパターンの起点はsourceです。Healthイベントの値はaws.healthで固定され、detail-typeはAWS Health EventとAWS Health Abuse Eventの2種類があります。不正利用の報告を別経路に回したい場合は、この2つを分けて書きます。

次のパターンは、対応が必要な障害と予定変更だけを拾う例です。actionabilityはACTION_REQUIRED・ACTION_MAY_BE_REQUIRED・INFORMATIONALのいずれか1つを取るメタデータで、人が中身を読まずに要対応かどうかを機械判定するために用意されています。

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
    "eventTypeCategory": ["issue", "scheduledChange"],
    "actionability": ["ACTION_REQUIRED"]
  }
}

サービスを限定したいときはdetailに"service": ["EC2", "RDS"]を足します。リファレンスのサンプルペイロードでは、サービス名がEC2やELASTICLOADBALANCINGのように大文字で入るため、表示名ではなくこの表記に合わせてください。

AWS CLIでEventBridgeルールとSNSターゲットを作る実行手順

上のJSONをhealth-pattern.jsonとして保存し、ルールとターゲットを作ります。リージョンは後述の理由でus-west-2にしています。

$ aws events put-rule \
  --name health-action-required \
  --region us-west-2 \
  --event-pattern file://health-pattern.json

$ aws events put-targets \
  --rule health-action-required \
  --region us-west-2 \
  --targets "Id"="1","Arn"="arn:aws:sns:us-west-2:123456789012:ops-alert"

SNSトピック側には、EventBridgeからのsns:Publishを許可するリソースポリシーが要ります。ここを忘れるとルールは作れてしまい、イベントが一致しても通知だけが届きません。aws events test-event-patternでパターンの妥当性を先に確かめておくと切り分けが早く済みます。

費用面では、AWSサービスが発行するイベントのデフォルトイベントバスへの配信自体に課金は発生しません。ターゲット側のLambda実行やSNS配信で課金が生じます。EventBridgeの課金がどこで効くかはAmazon EventBridgeの料金を整理した記事で扱っています。

取りこぼしを防ぐバックアップリージョンと簡易統合のルール配置

ルールをどこに置くかは、Healthイベントの設計で最も間違えやすい部分です。リージョンごとのルール作成についての公式ページには、東京リージョンだけを見ていると分からない仕組みが書かれています。

backupEventフラグとcommunicationIdによる重複排除

標準パーティションでは、US West（オレゴン）が他の全リージョンのバックアップリージョンとして働き、オレゴン自身のバックアップはUS East（バージニア北部）が担います。フランクフルトで障害が起きれば、イベントはフランクフルトとオレゴンの両方に配信されます。プライマリが巻き込まれても通知が途切れない設計です。

裏返すと、両方にルールを置けば同じ障害が2通届きます。冗長性が不要ならバックアップ側のルールにdetail.backupEventのフィルタを入れて除外してください。スキーマリファレンスのサンプルペイロードでは、このフラグは真偽値ではなく"backupEvent": "false"という文字列で表現されているため、イベントパターンも文字列で一致させます。

{
  "source": ["aws.health"],
  "detail": {
    "backupEvent": ["false"]
  }
}

冗長性を残したまま二重通知だけを避けたい場合は、両リージョンにルールを置いたうえでcommunicationIdによる重複排除を実装します。この値はページ番号を含む形（例：12345678910-1）で発行され、アカウントIDと組み合わせて同一通知を判定できます。

簡易統合のルール1本で済ませる条件とパブリックイベントの欠落

ルールを何本も管理したくないなら簡易統合（simplified integration）を選べます。US West（オレゴン）に中央ルールを1本置くと、標準パーティション内の全リージョンのアカウント固有イベントが自動で集まります。

ただし公式は、この方式ではHealth Dashboardに表示されるパブリックイベントを受け取れないと明記し、対応が必要なイベントの取り込みに限って推奨しています。高可用性の構成にもなりません。

リージョンに属さないイベントはグローバルイベントと呼ばれ、IAMがこれに当たります。公式は、受け取るにはUS East（バージニア北部）にルールが要ると書いています。東京にしかルールがない環境では、IAM関連の通知は構造的に届きません。

Health APIで過去90日のイベントを取得するboto3実装

過去のイベントを一覧したい、社内のダッシュボードに取り込みたいという要件ではHealth APIを使います。エンドポイントの仕様を知らないと、古いデータを読み続ける実装ができあがります。

global.health.amazonaws.comのアクティブ判定と署名リージョン

Health APIはアクティブ・パッシブ構成の2つのリージョナルエンドポイントを持ち、DNSフェイルオーバーのためにglobal.health.amazonaws.comという単一のグローバルエンドポイントが用意されています。既定ではアクティブがus-east-1（health.us-east-1.amazonaws.com）、パッシブがus-east-2（health.us-east-2.amazonaws.com）です。IPv6を含むデュアルスタックが必要ならhealth.us-east-1.api.awsを使います。

どちらがアクティブかはCNAMEを引けば分かります。公式が示す確認方法がそのまま使えます。

$ dig +short global.health.amazonaws.com
health.us-east-1.amazonaws.com.

ここで返ったリージョンが署名リージョンになります。公式は、両方のエンドポイントがデータを返すものの、最新の情報はアクティブ側にしかなく、パッシブ側は結果整合であると説明しています。切り替わりを検知したらワークフローを再起動するよう推奨されているので、エンドポイントを定数で埋め込む実装は避けてください。

boto3でDescribeEventsを叩いて影響リソースまで取る

SDKを使えば署名は自動で処理されます。次のコードは東京リージョンで進行中・予定の障害イベントを取得し、影響リソースまで展開する例です。

import boto3

client = boto3.client(
    "health",
    region_name="us-east-1",
    endpoint_url="https://global.health.amazonaws.com",
)

paginator = client.get_paginator("describe_events")
for page in paginator.paginate(
    filter={
        "regions": ["ap-northeast-1"],
        "eventTypeCategories": ["issue", "scheduledChange"],
        "eventStatusCodes": ["open", "upcoming"],
    }
):
    for event in page["events"]:
        detail = client.describe_affected_entities(
            filter={"eventArns": [event["arn"]]}
        )
        entities = [e["entityValue"] for e in detail["entities"]]
        print(event["arn"], event["statusCode"], entities)

region_nameに指定しているus-east-1は、リソースを置いているリージョンではなく署名リージョンです。取得対象のリージョンについては、filterのregionsで指定してください。ここを取り違えると、東京の障害を調べているつもりでバージニア北部のイベントだけを見ることになります。オペレーションの全仕様はHealth APIリファレンスにあり、通知の転送や自動対応のサンプル実装はAWS Health Toolsのリポジトリが参考になります。

Organizations全体のHealthイベントを1本に集約する設定

アカウントを本番・検証・共通基盤と分けた環境では、数だけルールを作る運用は破綻します。組織ビューと委任管理者についての公式ページは、組織ビューを有効にすると管理アカウントまたは委任管理者アカウントが組織内の全アカウントのHealthイベントを単一のフィードとして受け取れると説明しています。

組織ビュー有効化後にaffectedAccountを読む必要が出る理由

集約したイベントでは、ペイロードのaccountとdetail.affectedAccountが別の値になります。前者はイベントを受け取ったアカウント、つまり管理アカウントや委任管理者のIDで、実際に影響を受けたアカウントは後者です。通知文面を組み立てるLambda側でaccountだけを見ていると、どのアカウントが落ちているのか分からない通知ができあがります。

公式には、管理アカウントに組織ビューとEventBridgeルールを設定しても、他のアカウント側のEventBridgeルールが無効化されるわけではないとも書かれています。移行期に両方が動くと通知は二重になるため、集約に切り替えたら子アカウント側のルールを止めるところまでを作業に含めてください。

委任管理者を置く構成と各アカウント側に残しておくべき閲覧の権限

管理アカウントに運用ツールを載せたくない場合は、委任管理者として運用担当のアカウントを指定します。請求や組織管理の権限を持つ管理アカウントに運用担当者を入れずに済み、Healthイベントの閲覧と自動処理の権限だけを委任先へ置けます。各アカウントの担当者が自分のHealth Dashboardを見る経路は残し、集約側が全体把握と一次受けを担う分担にしてください。

AWS Health通知の自動化で失敗する条件と運用体制の線引き

ここからは判断の話です。Healthイベントの通知は作るのが簡単なぶん、作り過ぎて読まれなくなります。避けるべき構成と、自前で持つか委託するかの線を先に示します。

全イベントを1つのチャンネルへ流す構成が数週間で破綻する理由

sourceがaws.healthであることだけを条件にしたルールを作り、全部をSlackの1チャンネルに流す構成は採用しないでください。accountNotificationには利用量のお知らせや機能の案内が含まれ、それらが要対応の退役通知と同じ列に並びます。数週間で誰も読まなくなり、退役通知を見落とします。

振り分けの材料はペイロードに用意されています。personasはOPERATIONAL・SECURITY・BILLINGを取り、どの担当に渡すべきイベントかを示す項目です。actionabilityと組み合わせれば、要対応かつ運用担当宛のイベントだけを呼び出し用のチャンネルへ、残りを記録用のチャンネルへ、という2系統に分けられます。監視項目そのものの設計の考え方はシステム監視の解説記事に譲ります。

Healthイベントでは拾えない自社アプリの障害と計装の守備範囲

Healthイベントが教えてくれるのは、AWS側が認識した事象だけです。自社アプリケーションのメモリリーク、デプロイの失敗、特定エンドポイントの遅延は対象外で、AWSが障害と認識する前の数分から数十分は何も届きません。Healthの通知だけを頼りにすると、利用者からの連絡のほうが先に来ます。

この穴を埋めるのはアプリケーション側の計装です。メトリクスとトレースの取り方はAWSオブザーバビリティの実装記事、サービス単位の目標値と逸脱の検知はCloudWatch Application Signalsの解説記事で扱っています。Healthは外形的な事実、計装は自社の症状。役割を分けて両方を置くのが前提です。

自前で通知基盤を組むより運用ごと委託したほうが安く付く2条件

判断を言い切ります。アカウントが1つか2つで、稼働時間も平日日中に限られる規模なら、EventBridgeとSNSでメールに飛ばすところまでを自前で作るのが早く、外部に頼む必要はありません。

一方、アカウントが10を超える、24時間の一次受けが要る、通知から復旧作業までを手順として残す必要がある、のうち2つ以上に当てはまるなら、通知の自動化だけを作っても運用は埋まりません。必要になるのは受け手の体制で、そこが無いまま仕組みだけ増やすと、鳴り続ける通知を誰も見ない状態になります。委託範囲と費用の考え方はAWS運用保守の委託範囲と費用の記事に整理しました。設計から運用までまとめて相談したい場合はインフラ構築（AWS・Google Cloud・Azure）で対応しています。

よくある質問

AWS Health Dashboardについて、検索で多く見られる疑問に答えます。

AWS Health DashboardとService Health Dashboardの違いは何ですか？

旧Service Health Dashboardは全利用者に共通するサービスの提供状況を示すページ、旧Personal Health Dashboardは自分のアカウントとリソースに影響する事象を示す画面でした。現在はAWS Health Dashboardに統合され、サインインすればアカウント固有のイベントまで見られます。サインインしない状態で見られるのは一般的な提供状況の部分だけです。

AWS Health Dashboardの利用に料金はかかりますか？

ダッシュボードの閲覧に追加料金はかかりません。費用が発生するのは、EventBridgeから起動するLambdaの実行やSNSの配信など、通知の先に置いた仕組みの側です。Health API自体の呼び出しにも料金はかかりませんが、利用条件としてサポートプランの加入が求められます。

AWS Health APIはどのサポートプランから使えますか？

公式ドキュメントはAWS Business Support+、AWS Enterprise Support、AWS Unified Operationsのいずれかを条件としています。これらのプランへ移行していない場合は、Business、Enterprise On-Ramp、Enterpriseでも利用できると補足されています。条件を満たさないアカウントから呼ぶとSubscriptionRequiredExceptionが返るため、Basic Supportの環境ではEventBridge経由で組み立ててください。

EventBridgeにHealthイベントが届かないときは何を見ますか？

最初にルールのリージョンを確認します。IAMなどのグローバルイベントはus-east-1にしか配信されず、東京リージョンのルールでは一致しません。次にルールのMatchedEventsメトリクスを見て、一致自体が起きているかを切り分けます。一致しているのに通知が来ないならターゲット側の権限です。パブリックイベントはルール作成から配信開始まで最大1時間かかる点にも注意してください。

障害の情報を日本語で受け取ることはできますか？

EventBridgeで届くペイロードのeventDescriptionにはlanguageフィールドがあり、公式はこの言語がイベントの発行先リージョンによっておおむね決まると説明しています。us-east-1ではen_USです。日本語で運用したい場合は、受け取ったLambdaで定型の文面を日本語で組み立て、原文のlatestDescriptionを併記する形にするのが確実です。

関連記事

• AWS障害の確認方法と原因・対策｜2025年10月の大規模障害から学ぶ実務ガイド：通知を受けた後、実際に障害が起きているときの確認順序と初動
• AWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成【2026年時点】：Healthイベントでは拾えない自社アプリ側の症状を捉える計装
• AWS運用保守の委託範囲と費用｜監視・障害対応・パッチ適用の判断基準：通知の受け手をどこまで内製し、どこから委託するかの費用感