AWSのメンテナンス通知を見逃さない！HealthイベントをSlackに流してみた

はじめに

「EC2のリタイアメント通知、気づいたら期限が明日だった」——AWSを運用していると一度は経験する状況です。

AWS Healthのイベント（ハードウェア障害によるEC2リタイアメント、RDSのメンテナンス予告、証明書の期限切れ警告など）は、デフォルトではルートアカウントのメールアドレスとHealth Dashboardに届きます。しかしルートメールが共有メールボックスだと誰も見ておらず、Health Dashboardは開く習慣がなく、結果として「対応期限ギリギリに気づく」事故が起きがちです。

この記事では、AWS HealthイベントをSlackに流す経路を2パターン構築して比較します。

1. パターンA: AWS User Notifications（マネージド。シンプルなセットアップ）
2. パターンB: EventBridge → SNS → Amazon Q Developer in chat applications（カスタマイズしたい人向け）

AWS Healthイベントとは

AWS Healthは、自分のアカウントのリソースに影響するイベント（アカウント固有イベント）と、AWS全体の障害情報（パブリックイベント）を配信するサービスです。コンソールのHealth Dashboardで確認できるほか、EventBridgeに source = aws.health のイベントとして流れてきます。

なお、Health APIの直接利用にはビジネス以上のサポート契約が必要ですが、本記事で使うEventBridge経由・User Notifications経由のイベント受信はサポート契約なし・追加料金なしで利用できます。

通知経路は2パターンある

• パターンA: Health → AWS User Notifications → Slack（Q Developer経由）/ メール / コンソール通知センター
• パターンB: Health → EventBridge → SNS → Q Developer → Slack

どちらの経路でもSlack配信の末端はQ Developerです。そのため、まずはSlackワークスペースとQ Developerの接続から始めます。ここを作っておくと両パターンで使い回せます。

事前準備: SlackワークスペースとQ Developerの接続

通知先チャンネルの用意

Slack側に通知先チャンネル（例: #aws-health-test）を作っておきます。チャンネル設定の作成でチャンネルIDを使うので、チャンネル名をクリックして開く詳細画面の最下部に表示される C0XXXXXXXXX を控えておきます。

ワークスペースの認可

コンソールの検索バーで「Amazon Q Developer in chat applications」を開き（「chatbot」でもヒットします）、「チャットクライアントを設定」でSlackを選択します。SlackのOAuth認可画面にリダイレクトされるので、画面右上のワークスペースが正しいことを確認して「許可する」をクリックします。

チャンネル設定の作成

Workspace details画面の「新しいチャネルを設定」から作成します。リソース名は自由につけられます。本記事では検証時の名前のまま、konishi- プレフィックスで記載するので、適宜読み替えてください。今回の設定値は以下の通りです。

作成後、Slack側で通知先チャンネルにAmazon Qアプリを招待しておきます（/invite @Amazon Q を実行）。これを忘れると設定は正常なのに何も届かないので注意してください。

テストメッセージで疎通確認

チャンネル設定の画面にある「テストメッセージを送信」を押すと、Slackにテスト通知が届きます。

コラム: SNSに直接publishしても届かない

「SNS経由の疎通も確認しよう」と aws sns publish で任意のプレーンテキストを送っても、Slackには何も届きません。Q Developerが整形・配信するのは、対応サービスのイベント形式と、所定のカスタム通知スキーマ（version: "1.0" / source: "custom" のJSON）に従ったメッセージのみで、それ以外の形式はエラーも出さずに破棄する仕様です。逆に言えば、このスキーマに従えばLambdaで整形した独自メッセージもSNS経由で配信できます（パターンBの発展形）。単純な疎通確認は、テストメッセージ機能を使うのが確実です。

パターンA: User Notificationsで作る

コンソール右上のベルアイコン→「通知センター」、または検索バーから「User Notifications」を開き、「通知設定を作成」をクリックします。

ポイントはリージョンを複数まとめて選べることです。後述しますが、EventBridge直の構成ではリージョンごとにルールを作る必要があるため、ここはUser Notificationsの明確な優位点です。

集約設定は「5分以内に受信（推奨）/ 12時間以内に受信 / 集約しない」の3択で、同時多発したイベントをまとめてくれます。

Slack配信は内部的にQ Developerのチャンネル設定を参照するため、事前準備で作った設定をここで選択します。

補足: メール配信も追加できる

配信チャンネルにはEメールも追加できます。ただし、登録後に届く確認メールのリンクをクリックして検証を完了するまでは配信されない点に注意してください。本記事はSlack通知のみを前提に進めます。

作成すると、配信チャンネルに加えてコンソール右上のベルアイコン（通知センター）にも自動で届くようになります。

パターンB: EventBridgeで作る

SNSトピックの作成

SNSコンソールで、スタンダードタイプのトピック aws-health-notify を作成します（FIFOはQ Developer非対応）。設定はデフォルトのままで構いません。作成後、Q Developerのチャンネル設定の「通知」欄にこのトピックを紐付けておきます。

EventBridgeルールの作成

EventBridgeコンソール→「ルール」→「ルールを作成」と進みます。ルール作成画面には「強化ビルダー」（ドラッグ＆ドロップのビジュアルビルダー）と「アドバンストビルダー」（ステップ形式）の2モードがありますが、本記事はアドバンストビルダーで進めます。

• ステップ1: ルール名を設定（ここでは konishi-health-to-slack とつけます）、イベントバスは default、ルールタイプは「イベントパターンを持つルール」
• ステップ2: イベントソースは「AWSイベントまたはEventBridgeパートナーイベント」、作成のメソッドは「パターンフォームを使用する」

パターンフォームで「AWSのサービス: Health」「イベントタイプ: すべてのイベント」を選ぶと、イベントパターンが自動生成されます。JSONを1文字も書かずにここまで来られます。

{
  "source": ["aws.health"]
}

特定サービスに絞りたい場合は、作成のメソッドを「カスタムパターン(JSONエディタ)」に切り替えて detail.service を追加します。EC2だけに絞る例です。

{
  "source": ["aws.health"],
  "detail": {
    "service": ["EC2"]
  }
}

• ステップ3: ターゲットに「AWSのサービス」→「SNSトピック」→ aws-health-notify を指定
• ステップ4〜5: タグは任意。レビューして「ルールの作成」

コラム: コンソールとIaCで権限の持たせ方が違う

コンソールでSNSターゲットを指定すると、EventBridgeがAmazon_EventBridge_Invoke_Sns_* というIAMロールを自動作成してターゲットに紐付けます。SNSトピックのアクセスポリシーはデフォルトのまま書き換えられません（同一アカウント内のPublishを許可するデフォルトポリシー＋このロールで動きます）。

一方、TerraformやCloudFormationでこの構成を組む場合の定石は、トピックポリシーに events.amazonaws.com からの SNS:Publish を許可する方法です。コンソールで検証してからIaC化するとき、「コンソールにはあったロールがコードにない」「コードにはあるポリシーがコンソールにない」と混乱しやすいポイントです。

リージョンの注意

Healthのイベントはリソースが存在するリージョンのEventBridgeにしか流れません。東京リージョンのルールで拾えるのは東京リージョンのイベントだけで、IAMなどグローバルサービスのイベントはus-east-1にのみ配信されます。複数リージョンを使っている場合はリージョンごとにルールが必要です。この点、リージョンを一括選択できるUser Notificationsは楽です。

動作確認

実はこの構成、ダミーイベントを流したE2Eテストができません。

コラム: aws.health は偽装できない

EventBridgeには任意のカスタムイベントを投げ込める PutEvents APIがありますが、source の aws. プレフィックスはAWSサービス専用に予約されており、ユーザーが aws.health を名乗ったイベントは送れません。偽の障害通知を注入できないための正しい仕様ですが、「テスト用イベントを流して最後まで確認」ができないため、動作確認は部分ごとの積み上げになります。

設定直後確認できるのは以下です。

1. Slack配信路: Q Developerのテストメッセージ（事前準備で実施済み）
2. パターンマッチ: EventBridgeの「開発者用リソース」→「サンドボックス」で、サンプルイベント「AWS Health Event」（EC2の AWS_EC2_OPERATIONAL_ISSUE）と作成したパターンの一致を確認

サンドボックスでEC2絞り込み版のパターンを試し、サンプルの detail.service を "RDS" に書き換えると「一致しませんでした」になることも確認できます。絞り込みがちゃんと効いている証拠です。

3. User Notifications側: 通知設定のステータスが「アクティブ」であることを確認（設定直後にできる確認はこれくらいです）

残る「本物のイベントが末端まで流れるか」は、実イベントを待つしかありません。数日〜数週間運用していると、サービス廃止予告やメンテナンス告知などが届きます。今回の構成ではA/B両経路を同じチャンネルに向けているので、実イベントが届くと同じイベントがSlackに2通並びます。これが両経路とも生きている何よりの証拠です。

2パターンの比較

まとめ

• まず入れるならUser Notifications。SNS不要・複数リージョン一括・集約あり・コンソール通知センターにも同時配信と、「見逃し防止」の目的にはこれで十分です（メール等の配信先も後から追加できます）
• 整形や他システム連携をしたくなったらEventBridge。Lambdaで加工する、チケットシステムに流すなど、SNSの先を自由に組めます
• どちらもSlack配信の末端はQ Developerなので、ワークスペース接続は最初に一度だけ作れば使い回せます

「ルートメール頼みで運用している」チームは、まずUser Notificationsから始めてみてください。Q Developerのワークスペース接続さえ済んでいれば、15分ほどで設定できます。

参考

• Amazon EventBridge を使用して AWS Health イベントをモニタリングする
• AWS User Notifications とは
• Amazon Q Developer in chat applications（Slackのセットアップ）