はじめに（背景と目的）
「SNSトピックを使ってアラートやイベントを通知しているけど…」
通知メールが見づらく、アラートの内容が読み取りづらい
メッセージを整形するには Lambda を使う必要があり、運用コストがかさむ
通知の履歴を確認するには、メールを遡るしかなく管理が煩雑
そんな運用課題に直面したことはありませんか？
AWS User Notifications を使えば、SNS や Lambda を 自分で構築・運用せずに、アラート通知をメール・Slack・Microsoft Teams などで受け取ることができます。
通知内容も見やすく、可読性と保守性に優れた通知基盤を、コードレスで構築することが可能です。
本記事では、CloudWatch Alarm を例に、AWS User Notifications の概要と具体的な設定手順、運用設計のポイントを解説します。
AWS User Notifications とは？
AWS User Notifications は、AWS 上で発生するさまざまな通知を一元的に管理・配信できるサービスです。
AWS User Notifications の機能自体は追加料金無しで利用でき、通知の内容を AWS マネジメントコンソール上でまとめて確認できるほか、メールやチャットアプリ（Slack、Teams など）への通知設定も可能です。
なお、AWS User Notifications 自体に追加料金はありませんが、イベントソースや配信チャネル連携に伴って利用するサービスの料金は別途発生する可能性があります。
通知は以下の2種類に分類されます。
| 種類 | 内容 |
|---|---|
| AWS管理通知 | AWS が自動的に生成する通知。2025年7月現在では、AWS Health の通知のみが通知対象です。 |
| ユーザー設定通知（UCNs） | ユーザー自身が通知設定（Notification Configuration）を作成して発生させる通知。 たとえば CloudWatch Alarm や Support Case など、EventBridge 経由で任意の条件に基づいて通知を生成できます。 |
AWS User Notifications の主な機能は以下の通りです。
| 機能 | 内容 |
|---|---|
| マルチチャネル通知 | コンソール通知（ベルマーク）／メール／Amazon Q Developer in chat applications（Slack, Teams など）など同時配信可能 |
| 豊富なイベントソース | CloudWatch Alarm, Health Events, AWS Budget, Config, Security Hub など多様なトリガーと連携 |
| 通知ルールによる集中管理 | 通知ルールでイベント条件と送信先を一元管理 |
CloudWatch Alarm を AWS User Notifications と連携する
ここでは、CloudWatch Alarm の状態変化をトリガーに、AWS User Notifications 経由で メール通知を送る手順を紹介します。
AWS User Notifications のマネジメントコンソール画面は以下のような構成です。
主に、以下の 3 つの設定要素で構成されています。
| 用語 | 説明 |
|---|---|
| 通知ハブ（Notification Hub） | アカウント単位で「通知を保存・処理・複製するリージョン」を指定する設定です。通知設定を作成する前に必ず1リージョン以上（最大3リージョン）を登録する必要があり、登録したリージョン間で設定が自動的にレプリケーションされます。メール通知には SES API を利用し、SES 非対応リージョンの通知は米国東部（バージニア北部）経由で配信されます。 |
| 配信チャネル（Delivery Channel） | 通知の送り先／手段を定義する設定。複数選択でき、メールアドレス、チャットツール（Slack・Teams など）、モバイルプッシュなど、さまざまなチャネルへ同時に通知を配信できます。 |
| 通知設定（Notification Configuration） | 「どのイベントを」「どのチャネルで」通知するかを定義するルールです。たとえば CloudWatch Alarm の状態変化をトリガーに、指定した配信チャネルへ通知を送る設定が可能です。通知先は最大で合計 50 チャネルまで指定でき、チャネルを追加しなくても AWS マネコン上の通知センターに通知を表示することができます。 |
後述の手順では、以下の流れで設定を進めていきます。
STEP 1：通知ハブ（Notification Hub）の作成
STEP 2：配信チャネル（Delivery Channel）の作成
STEP 3：通知設定（Notification Configuration）の作成
STEP 1：通知ハブの作成
最大 3 つまでリージョンを設定できます。今回は「東京リージョン（ap-northeast-1）」を選択します。
ステータスが「アクティブ」になれば作成完了です。
STEP 2：配信チャネルの設定
今回はメールで通知を受け取るため、「E メールの追加」から通知先のアドレスを設定します。
「受信者」には通知を受け取りたいメールアドレスを入力します。
「名前」は内部的な識別用名称であり、通知本文には表示されません。
「名前」には英数字および - . ~ などの一部記号のみ使用できます
1 validation error detected: Value at 'name' failed to satisfy constraint: Member must satisfy regular expression pattern: .[\w-.~]+.
設定後、ステータスは「保留中」となります。
検証用の確認メールが送信されるので、「Verify Email」ボタンをクリックして承認してください。
※迷惑メールフォルダに分類される場合もあるのでご注意ください。
「Verify Email」ボタンをクリックすると、AWSアカウントへのサインインが求められます。
ボタンをクリックすると AWS アカウントへのログインが求められます。対象アカウントでログインして承認してください。
STEP 3：通知設定の作成
「通知設定を作成」ボタンから設定を開始します。
任意の「名前」と、必要に応じて「説明」を入力します。
通知対象のサービスを選択します。ここでは CloudWatch を選択。
「高度なフィルタ」を利用すれば、EventBridge のイベントパターンと同様の構文で、通知対象とするイベントを柔軟に絞り込むことが可能です。
今回はフィルタは指定しません。
CloudWatch を選ぶと、以下の 2 種類のイベントタイプを選択できます
CloudWatch Alarm State Change：アラームの状態変化（OK／ALARM／INSUFFICIENT_DATA の遷移）をトリガーとして検知
CloudWatch Alarm Configuration Change：アラームの定義内容（しきい値や通知先など）の作成・更新・削除といった構成変更が発生した際に検知
「集約しない」を選ぶと、状態変化を検知したら即時に通知が送信されます。
送信先として「E メール」を選択し、先ほど設定した配信チャネルのアドレスを選びます。最大で合計 50 チャネルまで指定可能です。
タグ付けは任意です。今回はそのまま「通知設定を作成」します。
「正常に作成されました」と表示されれば完了です。
通知設定を作成すると、設定内容に応じて以下のような AWS マネージドの編集不可なイベントルール が自動的に生成されます。
通知確認
CloudWatch Alarm の状態が遷移すると、以下の通りメール通知が正常に送信されていました。
通知はマネジメントコンソールのベルマーク（通知センター）にも表示されます。
AWS User Notifications 経由で配信された通知は、マネジメントコンソール上の「通知センター」に一覧表示され、過去の通知内容もここから一元的に確認可能です。
Google Group を通知の受信先に設定している場合、「グループ設定」にある「スパム メッセージの処理」の設定によって、通知メールがブロックされることがあります。
特に、「グループ宛の疑わしいメッセージの投稿を許可」以外を選択していると、AWS User Notifications からの通知がスパムとして扱われ、受信ボックスに届かない場合があるため注意が必要です。
実際に「管理してコンテンツ管理者に通知」に設定していたところ、通知がスパム判定されて受信できない事象が発生しました。
まとめ
本記事では、CloudWatch Alarm のイベント検知を AWS User Notifications と連携させる方法について、構成要素や設定手順を交えて解説しました。
とくに本サービスは、次のような課題を抱えている方にとって、有効な選択肢となります。
SNS + Lambda 構成に比べて、通知の整形や送信処理をコードレスで実現したい
通知履歴を AWS マネジメントコンソール上で一元的に確認したい
Slack や Teams、Eメールなど複数チャネルへ同時に通知したい
AWS User Notifications を活用することで、これまで分散していた通知処理を統一・簡素化し、運用負荷を下げつつ、通知の可読性・管理性を向上させることが可能です。
本記事が、AWS 上での通知設計・改善を検討されている皆さまの一助となれば幸いです。
