AWS User Notifications で人間が読みやすい通知を受け取ろう

クラウドソリューション部の荒木です。今回は AWS の通知サービス、AWS User Notifications をご紹介します。

この記事では、既存の通知サービスとの構成や機能の違い、検証から得られた気づきについて記述しています。

AWS User Notifications とは

AWS User Notifications は、複数の AWS アカウントやリージョンに対して、通知を一元的に設定および表示できるようにするサービスです。サービスやリソースの状態変化（＝イベントの発生）を検出し、通知を行うことができます。また、検出の条件をカスタマイズできるため「指定したイベントのなかで、特定のタグを持つリソースだけを監視対象とする」というように絞り込んだ設定を行うこともできます。

サービスの特徴をひとことで表すと、「人間が読む通知のためのサービス」といえるかと思います。

うれしいポイント

監視と通知の構成がシンプルに

これまでのメール通知構成は、Amazon EventBridge や Amazon CloudWatch アラームで検出された内容を Amazon SNS に連携して E メールを送信する、という構成が多かったかと思います。AWS User Notifications は検出と通知機能を併せ持っており、それらの設定を一元管理することができます。

また、Amazon EventBridge や Amazon CloudWatch アラームがリージョンごとに作成する必要があるのに対して、AWS User Notifications は複数リージョンに対して一括で設定を行うことができます。

利用料が無料

AWS User Notifications 自体の利用は無料となっています。ただし、検出するイベントルールに沿った Amazon EventBridge がマネージドに作成されるので、その実行には課金が発生すると思われます。

通知内容が読みやすい

AWS User Notifications の通知は人間向けの文章に自動編集されるため、受け取った際の状況把握がしやすい、というところもうれしいポイントです。また、配信方法は E メールのほか、AWS Chatbot や AWS コンソールモバイルアプリを選択することもできます。

通知内容を比較してみた

前項の構成例の経路ごとに、メール内容を比較してみたいと思います。

Amazon EventBridge ＋ Amazon SNS

イベント詳細の JSON がそのままメール内容となっているため、判読が難しいです。なお、Amazon EventBridge の入力トランスフォーマーという機能で JSON から値を抜き出し、『[リージョン名] の [インスタンスID] が [●●（状態）] になりました』というような表示にカスタマイズすることもできますが、この設定はイベントルールごとにひとつずつ設定する必要があります。

Amazon CloudWatch アラーム ＋ Amazon SNS

こちらはメール本文が整えられるようで、「なぜこのメールが送信されたのか」「どのようなアラームなのか」といった内容の、比較的読みやすいメールとなっています。

 

AWS User Notifications

HTML 形式で内容が整形され、読みやすさが各段に改善されています。また、メールには検出内容の記載だけでなく、該当するインスタンスを直接表示するリンクも付与されています。

各サービスごとのメールを比較してみて、

1. 後続の AWS Lambda やシステムに連携が必要な場合は、引き続き Amazon SNS を介してメッセージを送信
2. 人間向けにメッセージを送信する場合は AWS User Notifications を使用する

というように使い分けると便利だと理解できました。

検証から得られた気づき

AWS User Notifications の導入や設計にあたり、検証から得られた気づきをいくつかご紹介します。

正常 / 異常の評価に一定期間を要する監視はどうやってトリガー化する？

例えば EC2 の CPU 使用率など、「●分の間、●％を超えている」というような一定期間に対しての評価は AWS User Notifications で行うことができないため、Amazon CloudWatch アラームで監視する必要があります。ですが、「Amazon CloudWatch アラームの状態変化」は AWS User Notifications でトリガー化することができます。そのため、既に Amazon CloudWatch アラームで監視を行っている環境でも、既存の設定を活用しつつ、通知メールだけ AWS User Notifications に置き換えることが可能です。

イベントパターンとイベント集約のバランスの検討

AWS User Notifications は通知内容を集約する設定が可能で、5 分間 / 12時間 / 集約しない（イベントごとに送信）から選択することができます。

この集約設定を、迅速な対応アクションが必要な監視項目に対して行ってしまうと、メッセージを一見して「今、何がどういう状況なのか」がわかりにくくなってしまいます。例として、以下は EC2 に関するイベントを「複数のインスタンス、複数のリージョンで集約」した内容です。

逆に、Trusted Advisor や AWS Health など定期的に状況を確認するようなサービスに対しては、ある程度集約した情報をまとめて受け取るほうが扱いやすくなるかと考えました。

すべてのAWSリソースイベントを監視できるわけではない

一般提供を開始した時点で AWS User Notifications は 100 以上のサービスと統合されているというアナウンスがありましたが、サービスごとのすべてのイベントを検出できるわけではないようです。まずは検出対象としたいイベントが AWS User Notifications に統合されているか確認が必要となります。

おわりに

いかがでしたでしょうか。今回の検証を通して、リージョンやアカウントをまたいで通知設定を一元管理できることに加え、これまでサービスごとに異なっていた通知内容の形式を AWS User Notifications を経由することで統一できる、という点も魅力的だと感じました。この記事が、少しでもどなたかのお役に立ちましたら幸いです。