User NotificationsとSNSの違いを知りたい

初めに

こんにちは。コンサルティング部の津谷です。
皆さんはAWS User Notificationsというサービスを使ったことはありますでしょうか。最近知識をインプットする機会がありましたので、調べてみるとこんな疑問が浮かびました。
「SNSとの明確な機能の違いってなんだろ？？」
どちらもイベントがあった際にユーザに通知してくれるという共通点があることは頭にあったのですが、具体的にどのような違いがあるのか説明できないと思ったのでUser Notificationsを実際に触りながら確認したいと思います。

コンソール触ってみた

いろいろコンソールを触って感覚をつかみたいと思います。
まずは通知センターのコンソールから確認してみたいと思います。

こちらは、通知されたメッセージを確認できるみたいです。「最新」は文字通り時系列にメッセージを並べてくれるようです。ユーザ設定とAWSマネージドの通知もタブになっていますね。気になったのはQuick SetUpです。押下してみると、対象リソースはCloudWatch、EC2、AWSHealthの3種類のようです。「他のサービスの通知設定をセットアップ」とすれば様々なリソースをイベントソースとして指定できるみたいです。実際の通知設定の画面に来てみました。

イベントタイプを覗いてみると、Quick SetUp以外のサービスをイベントソースとして選択できます。イベント検知と通知両方やってくれるのは便利ですね。「EventBridge+SNS」の機能を提供してくれている印象を受けます。
気になったので調べてみました。こちらのドキュメントを確認するとUser NotificationsはEventBridgeのルール作成機能を内包しており、イベントソースごとにマネージドルールを自動作成してくれるようです。

リージョンは複数指定できるようです。複数リージョンでシステムが稼働している場合は、各リソースのイベント検知結果を一元化して「通知センター」に表示するので便利ですね。高度なフィルターでは、通知するイベントをさらにカスタマイズできるというわけですね。この辺も後ほど触ってみます。（こちらはJSON形式で記載する必要があります）
イベントフィルタはEventBridgeだと正常なJSONかテストする機能がありますが、それはできないようです。また、調べてみると追加したフィルタ情報はEventBridge側で表示できないようです。
（公式情報はこちらをご参照ください。）
なので、EventBridge側でテストしてからUser Notification側で設定するのが良さそうです。

集約設定は時間間隔を指定できるようです。「5分以内（推奨）」「12時間以内に受領」「集約しない」の3つが選択できますね。カスタムで時間設定とかできたら便利そうです。イベント駆動ですぐに通知を飛ばすのは「集約しない」を選択すればよいですね。
配信チャネルも確認します。SNSでいうサブスクリプションにあたりますでしょうか。「Eメール」「AWSコンソールモバイルアプリ」「チャットチャネル」から選択できます。（AWSコンソールモバイルアプリを探してみてインストールしてみました。（そんなのあるんだ。。））
こちらのドキュメントに機能の解説があります。アカウントIDやサインイン情報と紐づけて作成したリソースの状態を簡易的に監視してくれるようです。自分も気になったので入れちゃいました。←今度機能調査してみようと思います。

話を戻して、、、SNSと配信リソースを比較してみます。

上記のようにサブスクリプションではKinesisやLambda、SQSを指定できますね。
一方、User Notificationsは「Eメール」、「AWSコンソールモバイルアプリ」、「チャットチャネル」のみです。
メール通知はもちろん、多くの会社で使われているSlackやTeamsなどのコミュニケーションツールともシームレスに連携できるのは良いですね。チャットクライアントとの連携はAmazon Q Developer in chat applications（旧AWSChatBot)を利用しています。これらの統合サービスも内包しているんですね。通知の送信先はmax50個まで指定できます。
最後に、「通知ハブ」を確認します。通知データを複数リージョンにレプリケートすることが可能です。既存では最低1リージョンを通知ハブとして設定する必要があり、「us-east-1（バージニアリージョン）」が指定されています。

また、User Notificationsの1つの特徴は、AWSHealthの通知内容をそのままエンドユーザにメール通知できることですね。従来であればAWSHealthのダッシュボード画面で確認するorEventBridgeを噛ませて通知させるみたいなのがスタンダードな感じですがこっちもうれしい機能です。

「EventBridge+SNS」「CloudWatch+SNS」と何が違う？

いろいろ触ってみてUser NotificationsとSNS＋EventBridgeの違いをまとめてみました。
【メリット】
・User Notificationsは複数リージョンのイベント情報を収集し、通知内容を集約させられる（イベント通知系はここで一元管理ができる）
・AWS Healthイベントとシームレスに連携しているのでイベントを検知したら直接エンドユーザに通知を送れる。
→SNSの場合は、Healthとシームレスに連携しないので間にEventBridgeを挟む必要があり、設定が面倒。
・EventBridge＋SNSはリージョンリソースなので、1つのイベントごとに作成する必要があるが、User Notificationsだと同一UI上でまとめて設定可能。
・チャットボットに通知すればチャネル全員が通知を確認するので、リアルタイムに障害検知が可能。また、Amazon Q Developer in chat applicationsが通知設定を媒介しているため、CLIによる問題の自動修復やより詳細な障害情報をわかりやすく検知することが可能っぽい。下記に参考リンクを張りました。これも検証してみたい。
こちらをご参照ください。

【デメリット】
・SNSのサブスクリプションには「Kinesis」や「Lambda」が設定できる通り、非同期のシステムロジックが組みやすいが、User Notificationsはシンプルなメール・チャット通知しかできない。そのため、より高度なシステム連携を実装する場合SNS＋EventBridgeの方がよさそう。どちらかというと通知のリアルタイム性や可視性に重点を置いているので、ここは用途によって使い分けをするべきだと感じた。

・裏で作成されるEventBridgeはイベントフィルタリングに制限がある。（こちらをご参照）
-- サフィックスフィルタリング - 値の末尾の文字と一致
-- $or マッチング - 単一のルールを使用して、複数の異なるフィールドの条件が真かどうかを確認します。
-- Equals-ignore-case - 大文字と小文字の区別を無視します
-- ワイルドカードを利用できない
上記を使った複雑なフィルターで検知を行う場合は、Eventbridge＋SNSを使うしかない。

実際にUser Notificationsを試してみた

せっかくなので、通知していきたいと思います。S3バケットに格納しているオブジェクトを作成し、誤って削除してしまったらメール通知するという設定でやってみます。

構築手順

①S3を作成していきます。
名前は東京リージョンは「test-s3-usernotification-tokyo」、バージニアリージョンは「test-s3-usernotification-tokyo」と命名します。他はデフォルト設定のまま作成して問題ないです。

EventBridgeが検知しているので、S3のプロパティの設定からバケット内のイベントを検知できるようにしておきます。

②テスト用のオブジェクト（.txt)を両方のバケットに格納します。
【東京リージョン】

【バージニアリージョン】

③UserNotificationの設定を行います。

名前は「test-usernotification」とし、説明は「バージニアと東京にあるS3オブジェクトが削除されたら通知を行う」とします。イベントルールの設定では、実際にどのサービスのイベントを検知して通知するかを設定できます。今回は「S3」を選択し、イベントタイプは「Object Deleted」とします。リージョンは「バージニア」「東京」を指定します。実際の挙動は裏でEventBridgeルールが各リージョンに作成される仕様です。（下記は作成後に確認しました）

配信先の設定を行います。

今回は検証なので、イベント検知後都度通知しますが受け取るイベント数が多い場合などはまとめて受け取るというのも可能です。次に通知するメールアドレスと名前を指定します。メールを受け取れるアドレスを各自設定しましょう。名前は「tsuyataku」にしてますが任意で問題ないです。裏ではSESのAPIを叩いているんですね。

作成が完了すると、User Notificationsから認証メールが飛んできます。SESでドメイン検証ではなくＥメール検証する場合と同じですね。確認メールが飛んで来たら承認してしまいましょう。

承認後にステータスがアクティブになっていることも確認しましょう。

④最後にS3のオブジェクトを削除しておきましょう。

挙動確認

オブジェクトを削除した後の動作を確認してみます。
User Notifications側のコンソールで通知センターを確認すると下記のように各リージョンでオブジェクトが削除されていることがわかります。

メールの方も確認してみましょう。


それぞれ届いていました。これにて確認は終了です。

おまけ

高度なフィルタリングも使ってみたいと思います。
今回は簡単にEC2の起動で試してみます。

イベントタイプは、「EC2 Instance State-change Notification」とします。任意のインスタンスでIDを指定すると、高度なフィルタにJSON形式で自動反映してくれました。

EC2を起動してみます。

数秒後、通知センターを確認すると反映されていました。

メール通知も念のため確認します。

問題なくできていますね。

終わりに

調査兼、構築検証をすることでUser Notificationsへの解像度が上がった気がします。検証する中で気になったのは、モバイルアプリとの連携（そもそもモバイルアプリの機能がしりたい）とChatbotとの通知連携部分です。もう少し調査が必要な気がしますが、後者の方は個人のSlackワークスペース上にAmazon Qを連携することで障害情報をかみ砕いてもらう、チャットで指示を出して自動対応させるみたいなことをやってみたいと思いました。商用で利用する場合は、User NotificationsとEventBride+SNSのメリットデメリットに応じてうまく使い分けるとよいかと思いました。皆さんもぜひ使ってみてください。