はじめに

こんにちは！サーバーワークスの服部です。
めちゃくちゃ暑い日が続いてますが、皆様いかがお過ごしでしょうか。

さて、AWSクラウド上で重要なことといえば何が思いつくでしょうか…？（急
コスト・パフォーマンス・セキュリティなどなど思いつくかと思います。今回はリソースの監視と管理で必要なサービスの解説と設定手順を書かせていただきましたので、ご一読いただければ幸いです。

Amazon CloudWatchでリソースの監視設定を設定して、案件ごとに通知先用のAmazon SNSでトピック作ってメールアドレスで認証して…それの繰り返しになってしまうことはございませんか？
そして、そんな運用にそろそろ疲れてきてませんでしょうか…？
そんな方々に朗報がございます！
ぜひ、「AWS User Notifications」を使って、ものの十数秒で通知設定を終わらせてみませんか！

用語のサマリ

・ Amazon CloudWatch（以下、CloudWatch）→　AWSの様々なリソースのメトリクスを一括で管理、監視できるサービス。

aws.amazon.com

・Amazon SNS（以下、SNS）：CloudWatchでアラームが発生した際にEmail・SMSなどへの通知がするサービス。

aws.amazon.com

・AWS User Notifications（以下、User Notifications）：AWSサービスからの通知を集約し、SNSと同様Emailなどへ通知するサービス。

aws.amazon.com

AWS User Notificationsとは？

AWS User Notificationsは、AWSサービスからの通知を集約し、ユーザーに届けるためのサービスです。これにより、複数のAWSサービスからの通知を一元管理し、メール、SMS、または他のチャネルを通じて受け取ることができます。

SNSとUser Notificationsとの違い

	SNS	User Notifications
通知の見やすさ	△	◎
通知の履歴	×	◎
設定の手軽さ	○	○※注意
コスト	◎	◎
メッセージの耐久性	△	○

※注意：User Notificationsの通知先を設定検証する際にIAMユーザーのログイン情報が必要になります。

通知の見やすさ

下記を見てみてください。

こちら当方の検証環境でEC2のCPU使用率を監視するアラームと通知設定をしました。
一枚目画像のSNSからの通知では文字ベースだ書かれており、わかりにくいのに比べ、2枚目画像のUser Notificationsは整形され比較的見やすい内容の通知が届きました。
通知の有無について、下記にまとめてみました！

	SNS	User Notifications
アラーム名	有	有
リージョン	有	有
タイムスタンプ	有	有
コンソールへのリンク	有(URL)	有(ボタン)
名前空間	有	有
アラームの状態	有	有
名前空間	有	有
監視間隔	有	有
インスタンスID	有	有
メトリクス名	有	有
監視する値の条件	有	有
アカウントID	有	有
通知ジョブのARN	無	有
アラームの設定詳細	有	無

通知の見やすさについては、断然User Notificationsに軍配が上がりますが、CloudWatchのアラームの詳細設定まで通知で見ることができるのはSNSだけですね。なので、玄人向けはSNSで通知。なるべくわかりやすい通知を受け取りたい場合は、UserNotificationsを使うほうがよさそうです！

通知の履歴

SNSだとAWS CloudTrailからAWS::SNS::Topicのリソースタイプでフィルターしてログを拾ってと大変な作業ですが、User Notificationsでは通知センターから発砲された通知の一覧を下記のように確認することができます。

設定の手軽さ

SNSもUserNotificationsについても、数クリックで簡単に設定できます。違いとしては、通知先の使いまわしができるか否かという点で、使用感が変わるように思います。 SNSでは、各トピックごとで通知先を設定して、検証する必要があるので各リソースごとでトピックを作成する場合は都度通知先で許可する必要があります。ただしUserNotificationsと比べ、IAMでの認証が不要なので、その点は手軽さがあります！

UserNotificationsでは、通知先を一度登録してしまえばどの通知設定でも利用できるので、いくつも通知設定を作成する場合は便利です！

また、IaCという視点では、SNSはAPIが提供されているもののUserNotificationsではAPIがまだ提供されておらず、AWS CloudFormationやTerraformでの自動構築には向いていないです。ここについては今後のアップデートを楽しみに待ちましょう！

コスト

SNSもUserNotificationsも初期投資は不要で、従量課金制ではあるものの100通知当たりUSD 0.50程度と安価に利用することが可能です。

メッセージの耐久性

SNSでは、優れたメッセージ耐久性を実現するために、クロスアベイラビリティーゾーンのメッセージストレージで保存されてます。
対して、UserNotificationsはグローバルサービスでリージョンを指定せずに使えるサービスになります。したがって、複数リージョンでメッセージを保管するように設定ができ、大規模なリージョン障害が発生した場合でも、被害のないリージョンから安全にメッセージを通知することができます。

DRを考えている環境であれば、UserNotificationsを使ったほうが監視通知のDR設計が簡単にできそうですね！

実際に設定してみる

通知先の設定

AWSマネジメントコンソールにログイン
左上の検索窓に「UserNotifications」と入れて、「AWS User Notifications」をクリック
左側の「配信チャネル」をクリック
今回はメール通知にするので、オレンジ色の枠の「Eメールの追加」をクリック
受信者にメールアドレスを入力して、名前にはメールに記載する宛先名（アルファベット）を入力
右下の「Eメールの追加」をクリック
記載したアドレスにメールが届いているかと思いうので「Verify email」をクリック
配信チャネルを作成したアカウントのいずれかのIAMユーザのパスワード・IDを入力する
検証されたことを確認したら、登録完了！

監視アラームを通知先に送る

AWSマネジメントコンソールにログイン
左上の検索窓に「UserNotifications」と入れて、「AWS User Notifications」をクリック 3.クイックセットアップで「CloudWatch」を選択して「通知設定を作成」をクリック
命名規則などがある場合は適宜「名前」とを変更
リージョンでリソースを作成しているリージョンを指定
アラームを指定して通知したい場合は、「アラームを選択」で対象のCloudWatchアラームを選択する
配信チャネルは先ほど設定したものをプルダウンから選択
通知ハブの選択では作成しているリージョンのDR先に考えられるリージョンを指定（大阪・シンガポールなど）
設定が完了したら、右下「通知設定を作成」をクリック ※なお、アラームが発生する都度通知が欲しい場合は、「設定を編集」から「集約設定」の箇所で「集約しない」を選択してください。