背景

監視はシステム運用において必須です。
監視は「システム上の異常を検知し通知する」という目的があり、それを達成するためにはシステムから以下３つのデータを収集し通知する仕組みが必要です。

メトリクス(CPU使用率などの数値データ)
ログ
トレース(処理の繋がり)

その仕組みのうち、データ収集部分については Amazon CloudWatch が代表サービスです。
通知部分については Amazon Simple Notification Service が代表サービスですが、
2023 年 5 月に GA した AWS User Notifications (以下、AUN) も候補になります。
今回は、AUN を実際に運用で使ってみて惜しいなと感じた 4 点をまとめたいと思います。

AWS User Notifications について

概要

AUN は、Amazon CloudWatch Alarm や AWS Health イベントなどの通知設定を一元的に設定・管理できるサービスです。サービス自体は グローバルサービス となります。
後述しますが、内部的には指定したリージョンに AWS管理の Amazon EventBridge ルール が作成され、検知したイベントを AWS Management Console Notifications Center と、指定した以下通知先に通知します。

Eメール
AWS Chatbot
AWS Console Mobile App

料金

AUN 自体に料金はかかりません。
ただし、内部的には EventBridge を作成していますので、検知したイベント数に応じて料金が発生します。

仕組み

全体像

全体像は以下に示すようなイメージとなります。

Notification hubs (通知ハブ)

通知ハブは、通知データを 保存・処理・複製 するためのコンポーネントです。
アカウントレベルで設定するもので、最低 1 つ、最大 3 つのリージョンを設定することができます。
AUN はグローバルサービスであることから、初めて設定する際は以下のようにバージニア北部リージョンが入っていますが、変更可能です。

実際のところ、通知ハブの設定に関わらず、デフォルトリージョンであるバージニア北部リージョンには通知データが保存されます。
また後述する通知設定を作成したリージョンにも、通知データは保存されるようです。そのため、基本的には通知設定を作成するリージョンに合わせて通知ハブのリージョンを設定するのが良いと思います。

Important

Notification hubs only set the Regional boundaries of notifications. User Notifications stores the notification configuration's data in the default Region, US East (N. Virginia). This data is also stored in individual Regions that you have configured rules for.

Notification configurations (通知設定)

通知設定は、検知したい AWS サービスのイベントとルールを定義し、通知先の配信チャネルを設定するコンテナです。
以下の例では Amazon CloudWatch Alarm のステータスが Alarm 状態になったイベントを検知するための通知設定です。EventBridge での設定と変わらない使用感ですね。

特別な設定として リージョン という項目がありますが、ここで指定したリージョンに
AWS 管理の EventBridge ルール が作成されます。
このルールは AWS 管理であるため、編集することはできません。

実際に EventBridge ルールの中身を見てみると以下の通りです。
イベントパターンに AUN の画面で設定した 高度なフィルター の値が入っていませんが、
ちゃんとフィルターしてくれるので安心してください。

ターゲットを見てみると実は 入力トランスフォーマー が設定されています。

入力トランスフォーマーの中身は以下の通りです。
入力パスで EventBridge ルールが検出した JSON 形式のイベントをそのまま event 変数に格納し、入力テンプレートで使用しています。
実際のところは入力テンプレート通りの形式ではなく、配信チャネルに合わせて
AWS 側で変換して通知します。
例えば Eメールであれば HTML 形式のメール文に変換されます。

通知設定におけるその他設定項目としては 集約設定 と 配信チャネル があります。
集約設定は大別すると、イベントが発火されたら即座に通知 か 一定期間 ( 5 分 or 12 時間 ) に発火されたイベントをまとめて通知 の 2 パターンです。ここは監視対象イベントの重要度に合わせて設定する項目となります。
配信チャネルは、検知したイベントの通知先の設定となります。複数指定可能 です。

Delivery channels (配信チャネル)

前述した通りで、検知したイベントの通知先の設定となります。
現時点では以下 3 つを配信チャネルとして設定できます。

ちなみに余談ですが、Eメールに関しては全体像で図示した通り、AWS 管理の EventBridge ルールを作成したリージョンと同じリージョンの Amazon SES API Endpoints を経由するそうです。
※ 特にマネジメントコンソールからは確認できませんでした。内部的なリソースのようです。

セキュリティ

マネージドサービスなので意識するところではないですが念のため記載します。
データにフォーカスしますが、AWS 所有の KMS キー で暗号化されています。また AUN からのデータ通信は TLS で暗号化 されています。

Data encrypted with AWS owned key

Notification events

Notification configurations

Event rules

Notification hubs

Email contacts

Encryption in transit

All data sent to and from User Notifications is encrypted using standard TLS.

惜しいところ

本記事の本題です。
実際に使ってみて 惜しいなと感じた 4 点 を記載していきます。

全てのイベントに対応していない

一例ではありますが、EventBridge では AWS Directory Service からのイベントを検知するルールを作成できますが、AUN では作成できません。
このように、AUN では検知できないイベントが存在します。
そのため利用する際は、事前に検知したいイベントが AUN で対応しているか検討する必要があります。

対応イベントについて具体的に明記されたページは見つけられませんでしたが、現在 100 を超える AWS サービスからのイベントに対応しているようです。

AWS ユーザー通知がサポートしている通知タイプを教えてください。

AWS ユーザー通知により、ユーザーは CloudWatch アラームの状態変化などの任意の EventBridge イベントを選択し、通知を生成するように設定できます。現在、100 を超える AWS のサービスが EventBridge にイベントを発行しています。

一部イベントはメールから詳細が分かりにくい

Amazon CloudWatch Alarm などは Eメール本文に Alarm 名やメトリクス名が記載されているので判断しやすいのですが、例えば以下のような ACM の証明書有効期限前通知なんかだと、どの証明書が対象なのか Eメール本文から判断できません。
そのため、追加調査が必要となります。

通知文をカスタマイズできれば良いのですが、現時点ではサポートされていません。

通知をカスタマイズできますか? つまり、通知のタイトルまたは本文を変更できますか?

現在、このサービスはカスタマイズ機能をサポートしていません。

EventBridge のフィルタリング機能が一部使えない

AUN におけるイベントのフィルタリングで使用できる比較演算子は以下の 3 つです。

Suffix filtering
$or matching
Equals-ignore-case - ignore case sensitivity

ちなみに ワイルドカードは使用不可 であることが明記されています。

Wildcards aren't currently supported.

EventBridge で使用できる比較演算子の数と比較するとかなり少ないので、柔軟なフィルタリングができないことになります。

イベントソース ( AWS サービス) のクォータが厳しい

以下図の赤枠で囲ったところが個人的にはネックだなと思います。

上記赤枠のクォータにより、同タイミングで異なるソース ( AWS サービス ) からイベントが発火された場合に、1 つソースからのイベントしか拾えない ということになります。
つまり拾えなかったソースからのイベントは、「設定した通知先に通知が飛ばない」「AWS Management Console Notifications Center で確認できない」ということになります。
イメージは以下のような感じです。

実際に私の環境でもスロットルが発生し、拾われなかったソースからのイベント通知は届かず、AWS Management Console Notifications Center でも確認ができませんでした。
残念ながらこのクォータは 変更不可 です。そのため苦し紛れではありますが、スロットルを監視し、スロットル監視通知が来た場合、捨てられたソースの状態をマネジメントコンソールで確認する という対処をする必要があります。
そのためなのかはわかりませんが、AUN が出力する唯一のメトリクスがスロットルに関するメトリクスです。

上記メトリクスに対する Amazon CloudWatch Alarm を作成し監視することでイベントを見逃す確率は下げられます。

以下 2 点を考えるとかなり致命的なところかなと個人的には思っています。

スロットルで検知した後の調査が大変
スロットル監視用 Amazon CloudWatch Alarm の通知を AUN でやろうとすると、このイベントもスロットルで捨てられる可能性があるため、
SNS など AUN ではない別の通知を設定するのがベターであり、
通知の一元化ができない

まとめ

今回は、AUN を実際に運用で使ってみて惜しいなと感じた 4 点をまとめました。
通知というのは運用担当者の初動においてとても重要なインプット材料だと思います。
「とにかく通知がこれば良い」ということであれば、AUN で良いのかなと個人的には思います。
「通知からより詳細な情報が知りたい」ということであれば、EventBridge 入力トランスフォーマーか AWS Lambda を仲介させる必要があります。
その点踏まえた通知部分の設計をしておくと運用フェーズで困らないかなと思います。
こちらの記事が誰かの役に立てば幸いです。

参考資料

リファレンス

What is AWS User Notifications? - AWS User Notifications User Guide

ブログ

【資料公開】Classmethod Odyssey で「監視と可観測性の違い」そして「運用上の優秀性」について語りました - DevelopersIO produced by Classmethod