概要
AWS を運用していると、さまざまなサービスからイベント通知が発生します。EC2 インスタンスの状態変更、Health イベント、CloudWatch アラーム、Security Hub の検出結果など、それぞれのサービスで個別に通知設定を行っていると管理が煩雑になりがちです。
AWS User Notifications は、AWS アカウント内で発生するイベントの通知を一元的に管理するサービスです。複数の AWS サービスからのイベントを 1 つのハブに集約し、E メールや AWS Chatbot（Slack・Microsoft Teams 連携）などのチャネルで受け取れます。
本記事では、AWS User Notifications の基本概念を理解し、通知設定の作成からイベント受信の確認までを体験します。
この記事のメリット
- AWS User Notifications で通知ルールを作成し、特定のイベントを E メールで受け取る方法を習得できる
- 通知ハブとチャネルの概念を理解し、通知先の追加・管理方法を把握できる
- EventBridge ルールとの違いを理解し、適切な使い分けを判断できるようになる
- AWS Health イベントなどの重要な運用通知を見逃さない仕組みの構築方法を体験できる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
AWS User Notifications とは
クラウドおさるとひさん、AWS って色んなサービスから通知が来ますよね。EC2 の状態変化とか、Health イベントとか…。それぞれ個別に設定するのが大変だなって思ってたんですけど、まとめて管理する方法ってあるんですか？
土肥まさにその悩みを解決してくれるのが AWS User Notifications なんだ。AWS アカウント内のイベントを集約して、指定したチャネルに通知を配信してくれるサービスだよ。
クラウドおさるイベントを集約してくれるんですね。設定は難しくないですか？
土肥マネジメントコンソールから簡単に設定できるし、追加料金もかからないんだ。主なユースケースとしては、こんなものがあるよ。
- AWS Health イベント（メンテナンス通知、サービス障害）の受信
- CloudWatch アラームの状態変化の通知
- Security Hub の検出結果の通知
- EC2 インスタンスの状態変更の通知
- Cost Anomaly Detection の異常検出通知
クラウドおさる運用で気になるイベントがひととおりカバーされてるんですね。無料で使えるのもうれしいです。
通知設定の構成要素
クラウドおさるUser Notifications を使うには、どんな要素を設定すればいいんですか？
土肥大きく 4 つの要素で構成されているよ。まず表で整理するとこんな感じだね。
| 要素 | 説明 |
|---|---|
| 通知設定（Notification configuration） | どのイベントを通知するかを定義するルール |
| イベントルール（Event rule） | 通知対象のイベントソースとフィルタ条件 |
| チャネル（Channel） | 通知の配信先（E メール、Chatbot） |
| 通知ハブ（Notification hub） | 特定のリージョンで通知を処理するエンドポイント |
クラウドおさる通知設定の中にイベントルールとチャネルがあって、通知ハブがリージョンごとに処理する…という構造ですか？
土肥そのとおり。「何を通知するか」をイベントルールで決めて、「どこに届けるか」をチャネルで決める。それを通知設定としてまとめるイメージだよ。
クラウドおさる役割が分かれているから、あとからチャネルだけ追加したりもできそうですね。
イベントソース
クラウドおさるイベントルールで指定する「イベントソース」って、どんなサービスに対応してるんですか？
土肥User Notifications は EventBridge を通じていろんな AWS サービスのイベントを受信できるんだ。代表的なものを挙げるとこんな感じだよ。
| イベントソース | 通知の例 |
|---|---|
| AWS Health | メンテナンス予定、サービス中断 |
| Amazon EC2 | インスタンスの状態変更 |
| CloudWatch | アラームの状態変化 |
| Security Hub | セキュリティ検出結果 |
| AWS Cost Anomaly Detection | コスト異常の検出 |
クラウドおさるセキュリティ系からコスト系まで幅広いですね。裏側で EventBridge が動いてるんですね。
土肥そうなんだ。EventBridge のイベントバスに流れてくるイベントを User Notifications がキャッチして、人間に届けてくれる仕組みだよ。
通知ハブ
クラウドおさるさっき出てきた「通知ハブ」って、もう少し詳しく教えてもらえますか？
土肥通知ハブは、特定のリージョンで通知を集約・処理するためのエンドポイントなんだ。通知設定を作成すると、指定したリージョンに通知ハブが自動的に有効化されるよ。
クラウドおさるリージョンごとに処理されるということは、東京リージョンのイベントは東京の通知ハブで処理されるんですか？
土肥そのとおり。ただし注意点があって、IAM や CloudFront のようなグローバルサービスのイベントを受信するには、us-east-1 リージョンの通知ハブを有効化する必要があるんだ。
クラウドおさるなるほど、グローバルイベントは us-east-1 に集まるんですね。忘れずに有効化しないといけないですね。
EventBridge ルールとの違い
クラウドおさるEventBridge ルールでも通知って設定できますよね？ User Notifications とどう使い分ければいいんですか？
土肥いい質問だね。どちらもイベントに基づく通知ができるんだけど、用途が違うんだ。比較表で見てみよう。
| 観点 | AWS User Notifications | EventBridge ルール |
|---|---|---|
| 主な用途 | 人への通知（運用チーム向け） | システム間連携（自動化） |
| 設定の容易さ | コンソールから簡単に設定 | ルールとターゲットの詳細設定が必要 |
| 通知先 | E メール、Chatbot、コンソール | Lambda、SQS、SNS など多数 |
| フィルタリング | サービス単位・イベントタイプ単位 | イベントパターンの詳細なマッチング |
クラウドおさるUser Notifications は「人に知らせる」ためのもので、EventBridge ルールは「システムを動かす」ためのものなんですね。
土肥そういうこと。運用チームが目で見て判断するような通知には User Notifications、イベントをトリガーに Lambda を起動したり SQS にメッセージを送ったりする自動化には EventBridge ルール、と覚えておくとわかりやすいよ。
クラウドおさる目的に合わせて使い分ければいいんですね。すっきりしました。
実践
前提条件
- リージョン:
ap-northeast-1（東京） - IAM ユーザーまたはロールに AWS User Notifications、EC2 の操作権限があること
- 通知を受け取る E メールアドレスが利用可能であること
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| 通知設定 | ec2-state-change-notification | EC2 インスタンスの状態変更通知 |
| E メール受信者 | csl-notify | 通知の配信先（配信チャネル） |
| EC2 インスタンス | notif-demo | 通知を発生させるための検証用（既存のインスタンスでも可） |
ステップ1: AWS User Notifications コンソールにアクセスする
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
User Notificationsと入力し、表示された「AWS User Notifications」を選択します - 「通知センター」が表示されます。User Notifications はグローバルサービスなので、右上のリージョンは「グローバル」になります
- 「最新の通知」には、通知設定を作らなくても届く AWS Health の通知（メンテナンスや仕様変更のお知らせ）がすでに並んでいます
ステップ2: 通知設定を作成する
- 左側ナビゲーションの「通知設定」を選択し、「通知設定を作成」をクリックします
- 「名前と説明」に以下の内容を入力します
- 名前:
ec2-state-change-notification - 説明:
EC2 インスタンスの状態変更を通知
ステップ3: イベントルールを設定する
- 「イベントルール」の「パターンビルダー」で以下を設定します。ドロップダウンは検索欄に文字を入力すると絞り込めます
- AWS のサービスの名前:
EC2 - イベントタイプ:
EC2 Instance State-change Notification（「任意の状態」「任意のインスタンス」はデフォルトのまま） - リージョン:
Asia Pacific (Tokyo) - 「集約設定」は「5 分以内に受領 (推奨)」のままにします。短時間に同じ種類のイベントが続いても、まとめて 1 通で届く設定です
ステップ4: チャネルを設定する
- 「配信チャネル – オプション」で「E メール」のタイルを選択します
- 表示された「受信者」に、通知を受け取る E メールアドレスと、受信者の名前（例:
csl-notify）を入力します - 「通知ハブの選択」は、通知データを保存するリージョンです。デフォルトの
US East (N. Virginia)のままで構いません
- 「通知設定を作成」をクリックします
- 通知設定の一覧に
ec2-state-change-notificationが追加されるので、名前をクリックして詳細を開きます - 「ステータス」が「アクティブ」、「イベントルール」に EC2 のルールが「アクティブ」で登録され、「配信チャネル」の E メールは検証が済むまで「保留中」と表示されます
ステップ5: E メールアドレスを確認する
- 入力した E メールアドレス宛に AWS から確認メールが届きます
- メール内の確認リンクをクリックして、E メールアドレスの検証を完了します。検証が済むと配信チャネルのステータスが「アクティブ」になり、以降の通知がメールで届くようになります
- 検証前でも、コンソールの通知センターには通知が表示されます
ステップ6: 通知の動作を確認する
通知が正しく動作することを確認するために、EC2 インスタンスの状態を変更します。
- 上部の検索バーに
EC2と入力し、表示された「EC2」を選択します - 左側ナビゲーションの「インスタンス」を選択します
- 検証用のインスタンス（
notif-demo）を選択し、「インスタンスの状態」→「インスタンスを停止」を選択します - 確認ダイアログで「停止」をクリックします
インスタンスの状態が変更されると、イベントが通知設定に届きます。集約設定が「5 分以内に受領」なので、通知センターやメールに現れるまで数分かかります。
ステップ7: 通知センターで通知を確認する
- AWS User Notifications コンソールに戻り、左側ナビゲーションの「通知センター」を選択します
- 「最新の通知」に「Multiple events — There were 2 ec2 notifications within 5 minutes」のような通知が表示されていることを確認します。集約設定により、停止中（STOPPING）と停止済み（STOPPED）の 2 つのイベントが 1 通にまとめられています
- 通知のタイトルをクリックすると、まとめられた個々のイベント（インスタンス ID と状態）、通知設定の名前、リンクされた通知の一覧が確認できます。上部ナビゲーションのベルアイコンからも同じ通知が見られます
まとめ
- AWS User Notifications は、AWS アカウント内のイベント通知を一元管理するサービスである
- 通知設定でイベントソースとイベントタイプを指定し、E メールや Chatbot で受け取れる
- 通知ハブはリージョンごとにイベントを集約する仕組みで、グローバルイベントには
us-east-1の有効化が必要である - EventBridge ルールがシステム間連携向けであるのに対し、User Notifications は人への通知に特化している
- AWS Health イベントやセキュリティ検出結果など、運用上重要な通知の見落とし防止に有効である
