マネージドサービス部 佐竹です。
AWS Organizations を利用したマルチアカウント環境下において「AWS User Notifications」と「AWS Chatbot」を用い、お手軽に全 AWS アカウントの AWS Health の情報集約と Slack への通知が実装可能なことを解説すると共に、通知運用を踏まえたフィルター設定もご紹介します。
はじめに
AWS Health は AWS アカウントの運用において重要な機能です。
以前に以下のブログでも解説したように EC2 インスタンス等のサービスにおけるメンテナンスの予告連絡も、AWS Health のメンテナンスイベントとして通知が行われます。
後者のブログでは AWS Health のメンテナンスイベントの Slack への通知を [EventBridge (旧 CloudWatch Events)]→[SNS topic]→[AWS Chatbot]→[Slack] という流れで行いました。
ただし、先のブログで紹介した検証方法は「1つの AWS アカウント」のみを対象として想定しており、そのままではマルチアカウント(組織全体)での展開と実装が困難です。
現在は、この「組織の全 AWS アカウントの AWS Health の集約」と「その通知の Slack への連携」が簡単に実装できるようになっているため、その実装方法をステップバイステップでお伝えします。
前提となる AWS サービスの紹介
今回主に3つのサービス（機能）を組み合わせて実装します。それらについて先に簡単に紹介します。
AWS 環境構成図
最初に構成図として全体像を示します。
全体としては AWS Organizations を利用しており、管理アカウント1つと、メンバーアカウントが例として3つある状態を示しています。
AWS Health Organizational View
1 つ目は AWS Health Organizational View です。
Organizational View は組織全体の AWS Health の情報を、特定の AWS アカウント（Delegated Administrator）に集約する機能です*1。AWS Organizations を利用したマルチアカウント環境下では「各 AWS アカウントへログインしての個別の確認」は運用として非常に煩雑となってしまいますため、「どこか1つのアカウントのみを確認すれば良い状況」を作っておくことが重要です。
なお、本機能は委任された管理者（Delegated Administrator）に対応していますが、本ブログの動作検証及び構成図では AWS Organizations における管理アカウント（Management Account）をそのまま利用しています。
合わせて AWS 公式ドキュメントもご紹介します。
また委任に関する重要な補足として、ホワイトペーパー「Organizing Your AWS Environment Using Multiple Accounts」における項目「Recommended OUs and accounts」に記載のある「Infrastructure OU」においては、AWS Health の委任先として「Operations Tooling account」もしくは「Monitoring account」が Recommended AWS Organization Integrated Service Delegation として紹介されております。このため、もし委任を行われる場合は、これらのアカウントが候補となるでしょう*2。
AWS User Notifications
次に今回の主役でもある AWS User Notifications です。
「AWS ユーザー通知」とも翻訳される AWS User Notifications は、マネジメントコンソールから簡単に設定が可能な「AWS サービスに関する通知の一元管理機能」です。
AWS User Notifications は前述の通り「非常にお手軽に設定が完了できる」よう作られており、複雑な操作なしに Slack 等に通知を連携させることが可能です。
なお、残念ながら AWS User Notifications には公式のアイコンが存在しませんでしたので、構成図上では通知マークで代替しています。
AWS Chatbot
最後に Slack への通知の役割を担う AWS Chatbot です。
AWS Chatbot は ChatOps が可能となるよう開発された機能です。この機能は現在、Microsoft Teams、Slack 及び Amazon Chime に対応しており、これらに対し bot を通じて通知を送信することが可能です。
「ChatOps が可能」という点から「Slack 上から AWS を操作する」ためにも利用が可能ですが、今回は純粋に「AWS Chatbot → Slack」の方向で「通知の連携」目的で利用します。
具体的な実装方法
ではマネジメントコンソールから実装を開始します。
イメージを掴んで頂くために、初期状態の構成図を掲載します。
上図の通りです。ここから開始します。
まずは矢印の先「AWS Health Organizational View」の実装から進めます。
AWS Health Organizational View の実装
マネジメントアカウントにログイン後、「AWS Health Dashboard」を開きます。その後、左側メニューから「Configurations」を押下し、「Enable organizational view」ページを表示させます。
表示後「Enable organizational view」の「Get started」に掲載されている3つの手順を見ていきます。
まず「1. Set up AWS Organizations」については、AWS Organizations をご利用中であれば既に「Success」となっている想定です。もしこれがクリアできていない場合は以下のドキュメントを参考に「all features enabled.」の条件をクリアしてください。
次に「2. Enable organizational view for AWS Health」の手順です。
本設定は「Enable organizational view」のボタンを押下するだけです。押下すると上画像の通り少し待ちが発生します。
なお、このボタンは確認画面等が出ず押下すると即時実行されます。注意してください。
ボタンの押下後は頃合いを見て画面をリロードし、上画像の通り「Success」となれば完了です。
完了の確認として「Your organization health」→「Event log」をメニューから選択し、表示してみます。ここに最近のイベントログが表示されていれば問題ありません。
さて最後の「3. Register a Delegated Administrator for organizational view」ですが、これは先に記載しました「委任管理者」を利用する場合の設定であり（ベストプラクティスとしては実装したほうが良いですが）任意です。今回、この3の手順はスキップします。
これで AWS Health Organizational View の実装が完了しました。作業自体は「Enable organizational view」のボタンを押下しただけです。非常にお手軽です。
図で示すと上図の通りになりました。
AWS Chatbot の実装
次に、順番は前後しますが、実装の都合 AWS Chatbot を先に構築します。
上図の右上、矢印の箇所です。
User Notifications 実装時に AWS Chatbot の指定が必要となるため、それよりも先に構築しておく必要があります。
AWS Chatbot のサービス画面を開き、画面右上に表示される「Configure a chat client」において、"Slack" を選択します。その後「Configure client」を押下します。既に Slack との連携が住んでいる場合は本設定は不要です。
「AWS Chatbot is requesting permission to access the [社名等] Slack workspace」という確認画面が出るため「Allow」を押下します*3。
自動的に画面が遷移しますので「Configure new channel」を押下して作業を進めます。
まず「Configuration name」にチャンネル名を記載します。チャンネル名が運用上最も識別しやすいため、お勧めです。
その後、ログのオプションを「Errors only」で設定しておきます。エラーハンドリングがし易くなるため、この設定は個人的に追加を推奨します。
次の設定の「Channel ID」ですが、以下の通りにします。
上画像の通り、通知先としたい Slack チャンネルにおいて「About」を表示し、その最下部に「Channel ID」が記載されていますのでこれを確認＆コピーします。
先程取得した Channel ID をマネジメントコンソールに貼り付け、次に進みます。
Permissions については、「Create an IAM role using a template」として IAM Role を「AWSChatbot-Role」の名前で新規作成します。既に作成済の場合は既存の IAM Role を指定ください。
それらの設定以外は全て今回デフォルトのままとしています。
AWS Chatbot の権限について詳細を知りたい方は以下のドキュメントも合わせてご覧ください。
最後に「Configure」を押下します。
正常に完了すれば「You successfully configured the Slack channel.」と表示されます。
これで AWS Chatbot の実装が完了しました。
図で示すと上図の状態まで完了しました。
Slack チャンネルに AWS APP を追加する
参考までに記載しますと、Slack 側に他に必要な作業があります。
AWS 公式ドキュメントからの引用は以下の通りです。
Add AWS Chatbot to the Slack channel:
In your Slack channel, enterinvite @aws.https://docs.aws.amazon.com/ja_jp/chatbot/latest/adminguide/slack-setup.html
上記の通りですが Slack の通知先のチャンネルに AWS Chatbot APP を招待（インバイト）しておく作業も必要です。
こちらも実施済か念のため確認ください*4。
AWS User Notifications の実装
最後に、AWS User Notifications の実装です。
ここまでの実装で、全てのアカウントの AWS Health のイベントは管理アカウントに集約されています。そして、Slack への連携の入り口は AWS Chatbot で用意されています。
あとは AWS Health と AWS Chatbot の間をつなぐだけです。ここを仲介するのが今回 AWS User Notifications となります。
先に記載しますと、この構成には少々違和感を覚える方もいらっしゃると思います。
というのも、AWS Chatbot は基本的に Amazon Simple Notification Service (SNS) をその配信の入り口とするためです*5。
これは先に紹介したエンジニアブログでの構成が [EventBridge (旧 CloudWatch Events)]→[SNS topic]→[AWS Chatbot]→[Slack] で行われていたことからもわかる通りなのですが、しかし今回のように AWS User Notifications から AWS Chatbot に連携を行う場合には SNS トピックが不要です。
では実際にマネジメントコンソールより実装を行います。
「AWS User Notifications」を開くと、画面右上に「Quick setup」が表示されます。
この選択肢から「Health」を選び、その後「Create notification configuration」を押下します。
Create notification configuration がポップアップされるため設定していきます。
まず Name はデフォルトの「Health-quick-setup」のままとしています。
次にリージョンの選択ですが、ここでは通知を受け取りたいリージョンをそれぞれ必要なだけ選択します。具体的には、組織全体で利用している（もしくは利用すると決めている）リージョンを選択します。
今回は「US East (N. Virginia)」、「Asia Pacific (Tokyo)」の2つとしました。
全リージョンを選択すると、利用していないリージョンのヘルスイベントも通知されてしまうため、ノイズを減らす目的で極力不要なリージョンは外したほうが良いでしょう。
「Aggregation settings」の Receive within 5 minutes は設定が変更できないためこのままとし、「Email - optional」は未設定で問題ありません。
最後に「Notification hubs」ですが、これは AWS User Notifications が各リージョンの情報を収集し、集約するためのハブとなるリージョンのことで、最低1つ、最大3つまで選択が可能です。
通知ハブは、通知が保存、処理、またはレプリケートされるリージョンです。通知設定を作成するには、通知ハブを少なくとも 1 つ選択する必要があります。
https://aws.amazon.com/jp/blogs/news/new-set-up-your-aws-notifications-in-one-place/
今回はデフォルトの「US East (N. Virginia)」とし、進めていきます。
最後に「Create notification configuration」を押下して完了です。つまり、Regions 以外特に設定は変更していません。お手軽です。
クイックセットアップの作成が完了した後、一部の設定を編集するために「Notification configurations」から「Health-quick-setup」を選択した後「Edit」を押下し編集画面を表示します。
編集を行いたいのは「Delivery channels」の項目です。
「Chat channels」にチェックを入れた後、先ほど設定した AWS Chatbot の Slack チャンネルである times-satake にチェックを入れます。
その後「Update notification configuration」を押下してアップデートは完了です。
念のため、Health-quick-setup の最下部「Delivery channels」に AWS Chatbot が設定されていることを確認しておきます。
これで今回必要な実装が全て完了し、上図の通りとなりました。
Amazon EventBridge との関係性について
AWS User Notifications の設定が完了すると、有効とした各リージョンにおいて、Amazon EventBridge の Rules に設定が追加されます。
上画像は「US East (N. Virginia)」の Amazon EventBridge の Rules を確認したものです。AWSUserNotificationsManagedRule から開始される Rule が作成されています。
イベントパターンは以下の通りで、全ての AWS Health のイベントを取得する設定が施されていることがわかります。
{ "source": ["aws.health"], "detail-type": ["AWS Health Event"] }
なお、このルールは（実際には試してみていませんが）強制的に消せてしまうようです。
謝って本ルールが削除等されると、AWS User Notifications が正しく動作しなくなってしまう可能性がありますので、運用上注意したいポイントです。
動作確認
では設定の動作確認に移ります。
まずは AWS User Notifications の Notification center からです。
Notification center
正しく動作していれば、これまでの全設定が完了した後に、指定のリージョンで発生した AWS Health 関係の全てのイベントが AWS User Notifications の初期画面となっている Notification center に表示されるようになります。ただ、設定より過去のイベントについては遡及されません。
この一覧表示は「歯車マーク」から「Region」や「Service name」「Account ID」を表示したほうが視認性が高くなります。
また、本情報の元となるのは「AWS Health Dashboard」の「Your organization health（Organizational View）」です。
一次情報を確認されたい場合は、AWS Health Organizational View の Event log を確認されると良いでしょう。
なお、Organizational View には全リージョンの情報が掲載されているため、表示が膨大になる場合があります。必要に応じて Region 等で表示の絞り込みを行ってください。
Slack への通知内容
Slack への通知結果もご紹介します。
発生したヘルスイベントは上画像の通りに Slack にも(ほぼ)同時に行われます。
通知の形式ですが、本設定では最上部のアカウント ID は常に管理アカウントになります。そして通知内容に記載のある「Affected account」が実際に影響を受けるメンバーアカウントを示しています。
Email 形式や SNS 通知の json では可読性が悪いのですが、AWS User Notifications と AWS Chatbot を通すことでこの通り視認性が上がり、運用者にとってもポジティブです。
AWS User Notifications のフィルター設定について
ここまでの通知設定では「特定のリージョン」に対象を絞り込んだものの、そのリージョンにおける全てのヘルスイベントが AWS User Notifications によって Slack に連携・通知されてしまう状況です。
実際に1週間程度運用してみたのですが、AWS Organizations の組織全体で利用している AWS サービスが多い場合、この通知の頻度も多くなってしまいます。
よって、重要な通知を見逃さないようノイズを減らすためにフィルタリングを行います。
ただし、本設定はオプションです。フィルタリングが不要な場合は実施しなくても問題ありません。
イベントカテゴリーのフィルター
先程記載した通り AWS User Notifications には裏側で Amazon EventBridge が使われていることもあり、フィルタリングルールは基本的に Amazon EventBridge のイベントパターンと同様となりますが、まずは前提知識として以下の AWS 公式ドキュメント (Concepts for AWS Health) における「Event type categories」を確認していきます。
イベントタイプカテゴリーには、以下の3つが存在します。
- Notification (Account notification)
- Issue
- Scheduled change
この中から必要なものだけに絞り込みを行います。
この3種は、AWS Health Organizational View の Event log 一覧における「Event category」からも確認が可能です。
今回は「Scheduled change」だけが必要と考えて、これだけに絞り込みを行います。
「Scheduled change」は、例えば AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED や AWS_RDS_PLANNED_LIFECYCLE_EVENT 他には AWS_ECS_TASK_PATCHING_RETIREMENT 等が含まれます。
本フィルター設定を、AWS User Notifications に実装していきます。
先程と同様、「Health-quick-setup」を選択した後「Edit」を押下し編集画面を表示します。
Event rules の項目内にある「Advanced filter - optional」を押下し、Event Pattern (JSON) を記載する箇所を表示させます。
Advanced filter に以下の通り記載します。
{ "detail": { "eventTypeCategory": [ "scheduledChange" ] } }
補足となりますが、AWS User Notifications の「Health-quick-setup」では「AWS service name」が「Health」に、「Event type」が「Specific Health events」で固定されます。このため Amazon EventBridge での設定と若干異なり、フィルターにおいてはこれらの記載は不要となっています。
記載が完了した後は「Update notification configuration」を押下して設定に反映します。
「Notification configuration update succeeded」と表示されたら完了です。上画像の通り「View JSON」を押下することで現在の JSON 設定を確認することも可能です。
サービスのフィルター
先のイベントカテゴリーのフィルター設定追加により AWS User Notifications 及びその Notification center は Scheduled change のみを取得・通知するようになりました*6。
しかし、このフィルター設定でもまだノイズが多い状況です。
例えばそれは「Slack への通知内容」において紹介した以下の画面キャプチャで通知されている Event type code AWS_CLOUDSHELL_PERSISTENCE_EXPIRING です。
本イベントの通知内容は以下の通りです。
Some users of this account have not used AWS CloudShell for over 110 days in the ap-northeast-1 Region. On July 27, 2024 we are scheduled to delete the CloudShell home directory and data of inactive users in the ap-northeast-1 Region.
[以下翻訳]
このアカウントの一部のユーザーは、ap-northeast-1 リージョンで 110 日以上 AWS CloudShell を使用していません。2024 年 7 月 27 日に、ap-northeast-1 リージョンの非アクティブ ユーザーの CloudShell ホーム ディレクトリとデータを削除する予定です。
マルチアカウント環境下で組織を横断して保守管理を行っていると、様々なメンバーアカウントで AWS CloudShell を利用することになります。
このような場合、それぞれのメンバーアカウントごとに定期的に「Health Event: AWS CLOUDSHELL PERSISTENCE EXPIRING」が通知されてしまい、ノイズになる場合があります。
参考までに、AWS CloudShell のホームディレクトリの仕様は以下の通りです。
AWS CloudShell で の使用を停止した場合 AWS リージョン、データは最後のセッションの終了から 120 日間、そのリージョンの永続ストレージに保持されます。アクションを実行しない限り、データは 120 日後にそのリージョンの永続的ストレージから自動的に削除されます。その AWS CloudShell で AWS リージョンを再度起動すれば削除を防止することができます。
https://docs.aws.amazon.com/ja_jp/cloudshell/latest/userguide/limits.html
このため、今回はフィルター設定で AWS CloudShell のみ通知から除外します。
特定のキーワードをフィルターで除外するには anything-but を利用します。詳細は以下のドキュメントも合わせてご覧ください。
Anything-but マッチングは、ルールで指定されているもの以外のものと一致します。
具体的には、以下の通りにフィルターに追記を行い、更新します。
{ "detail": { "service": [ { "anything-but": [ "CLOUDSHELL" ] } ], "eventTypeCategory": [ "scheduledChange" ] } }
更新作業後は先ほどと同様にマネジメントコンソールで確認し作業は完了です。
これで、フィルター設定は以下の通りとなりました。
- イベントカテゴリーは
Scheduled changeのみを通知 - その上で AWS サービスは
AWS CloudShellを通知から除外
なお、AWS User Notifications のフィルターに関する設定情報は探してもあまり見つかりませんでしたので、今回の検証においては念のため AWS サポートにも確認を取って進めました。
補足すると、以下の通り「Using customized JSON event patterns」という AWS 公式ドキュメントもあるにはあるのですが、具体例の掲載が少ないことに加え「EventBridge のルールビルダーを利用する」よう促されるに留まっています。
まとめ
本ブログでは、マルチアカウント環境下において「AWS User Notifications」と「AWS Chatbot」を用い、お手軽に全 AWS アカウントの AWS Health の情報集約と Slack への通知が実装可能なことを解説しました。
合わせて、サービスごとの具体的な実装方法について、進行状況を説明した構成図を添えながらステップバイステップで詳細に記載しました。
さらに実運用に備え、AWS User Notifications におけるイベントフィルター（Advanced filter）の具体的な設定例もご紹介しております。
これらの内容が AWS マルチアカウント運用の一助になれば幸いです。
では、またお会いしましょう。
*1:余談ですが、Trusted Advisor でも同様に Organizations View という機能が提供されていたりします https://blog.serverworks.co.jp/organizational-view-for-trusted-advisor
*2:"委任"機能そのものについては以下のブログ等で説明しております https://blog.serverworks.co.jp/organizations-config-aggregator-delegated-admin
*3:この設定が不可能な場合、作業者の Slack 側の権限が不足している可能性が高いと思われます
*4:AWS User Notifications を利用する場合、AWS Chatbot APP をチャンネルに招待していなくても動作するようでしたが、実施しておくほうが無難でしょう
*5:Tutorial: Subscribing an Amazon SNS topic to AWS Chatbot などを参照ください https://docs.aws.amazon.com/ja_jp/chatbot/latest/adminguide/subscribe-sns-topic.html]
*6:フィルター設定は AWS User Notifications の初期表示画面である Notification center にも効力を発揮します
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
