Amazon Q DeveloperとSlackで実現するCloudWatchアラート分析
クラウド事業本部運用イノベーション部の いそま です。
前回のブログにて、Amazon Q Developer in chat applicationsをSlack統合し、AWSリソース情報を取得するということをやってみました。
↓前回のブログはこちら
この機能を運用に活用できないかと考えたところ、
💭 障害（ex.EC2のCPU使用率が上昇しているなど）が発生した際にアラート通知をSlackで受信する
💭 Slackにてアラート分析
などなど…できたら便利だなと思いました。
今回のブログでは、上記の機能を実装し運用に活用できる一例をご紹介します！
構成
実装
今回は以下のような流れで、実装を進めます。
EC2のモニタリングアラームをSNS→Amazon Q Developer in chat applicationsを介し、Slackに通知します。
- SNSトピックの作成
- Amazon Q Developer in chat applicationsとSlackを統合
- EC2のCPU使用率（CPUUtilization）を監視するCloudWatchアラームを作成
- IAMロールにポリシーを追加
- アラート通知確認
まずは、SNSトピックを作成します。
- SNSトピック作成
※添付画像の項目以外はデフォルト
- 作成されたことを確認する
次に、Amazon Q Developer in chat applicationsとSlackを統合します。
- AWSコンソールにログイン後、Amazon Q Developer in chat applicationsに遷移
- [チャットクライアント設定]にて、[Slack]を選択
- [クライアントを設定]をクリック
- ワークスペースを設定して、[許可する]を選択する
- クライントの作成完了
次に、Slackのチャネルを設定します。
- [新しいチャンネルを設定]をクリック ※参考キャプチャの赤枠どちらでも可
- 項目に沿って設定する
設定の詳細
| 設定箇所 | 設置値 |
|---|---|
| [設定名] | 任意の設定名を設定 |
Slackチャネル
今回はプライベートチャネルを設定しましたが、パブリックチャネルでも問題ないです。
| 設定箇所 | 設置値 |
|---|---|
| [チャネルタイプ] | プライベート |
| [チャネル ID] | チャネルIDを指定 |
アクセス許可
| 設定箇所 | 設置値 |
|---|---|
| [ロール設定] | チャネルロール |
| [チャネルロール] | テンプレートを使用してIAMロールを作成する |
| [ロール名] | 任意のロール名を設定 |
| [ポリシーテンプレート] | 通知のアクセス許可，Amazon Q Developerのアクセス許可 |
| [チャネルガードレールポリシー] | ReadOnlyAccess，AmazonQDeveloperAccess |
※ SlackチャネルでAmazon Q Chatを利用するためには、「AmazonQDeveloperAccess」の設定が必要となります。
今回はQ Chatを使用するため、設定しました。
https://docs.aws.amazon.com/ja_jp/amazonq/latest/qdeveloper-ug/q-in-chat-applications.html
通知 - オプション
「1. SNSトピック作成」にて作成したSNSトピックを指定します。
| 設定箇所 | 設置値 |
|---|---|
| [リージョン 1] | SNSトピックを作成したリージョンを指定 |
| [SNSトピック] | SNSトピックを指定 |
タグ
今回は特に設定していません。
| 設定箇所 | 設置値 |
|---|---|
| タグ | ー |
-
チャネル設定がされたことを確認する
-
「2.」の設定が完了すると、SNSトピックにサブスクリプションが自動で追加される
次に、EC2のCPU使用率（CPUUtilization）を監視するCloudWatchアラームを作成します。
アラームの設定は通常通りで問題ないですが、[通知の送信先]を前述で作成したSNSトピックに設定することだけ意識していただければと思います。
（アラームの作成方法を知りたい方は、こちらのブログで丁寧に説明してくださっています！）
次に、IAMロールに必要なポリシーを追加します。
対象のIAMロールは[Slackチャネル]にて作成したIAMロールです。
今回は、EC2モニタリングアラームを分析したいので、以下IAMポリシーを追加しました。
- AmazonEC2ReadOnlyAccess
- CloudWatchReadOnlyAccess
以上で実装は完了です。
最後に、アラートをSlackに受信できるかの確認をしたいと思います。
まず、EC2のアラートを発生させます。
※アラームの閾値設定「>」を逆にすることで力技でアラートを発生させています。
すると、設定したプライベートチャネルにアラート通知が飛んできました🎉
これで無事に実装が完了していることの確認ができました！
アラート分析
実装が完了しましたので、運用に活用する方法を最後にご紹介します！
※あくまで私なりの活用方法ですので、ご了承ください。
「@AmazonQ」とメンションすることで、Amazon Q Developerと対話することができます。
前述で受信したCloudWatchアラームについて、Slack上でAmazon Q Developerに質問してみます。
2回ほどやり取りを重ね、最終的に以下のように分析をしてくれました。
※アラームの閾値設定「>」を逆にすることで力技でアラートを発生させていますので、不思議なアラート内容となっている点はご了承ください。
アラーム状態の詳細
| 概要 | 説明 |
|---|---|
| アラーム名 | demo-ec2-CPUUtilization |
| 現在の状態 | ALARM状態 |
アラームが発生した理由
| 概要 | 説明 |
|---|---|
| 閾値を下回ったため | 最新のデータポイント1つのうち1つ [3.21%（2025年9月27日 07:15:00）] が閾値（90.0%）を下回りました |
| OK → ALARM遷移の最小データポイント数 | 1 |
分析結果
| 内容 |
|---|
| CPUUtilization メトリックに異常は検出されませんでした |
| 現在のCPU使用率は約3.21%と非常に低い状態です |
まとめ
| 内容 |
|---|
| このアラームは、CPU使用率が90%を下回った場合に発生するように設定されているようです。これは通常とは逆の設定で、CPU使用率が低すぎる場合（つまりインスタンスがあまり使用されていない場合）にアラートを出すように構成されている可能性があります。 現在のCPU使用率が3.21%と非常に低いため、このアラームが発生しています。 |
感想
分析結果としてはもう少し情報が欲しいところではありますが、
大前提、AWSコンソールから人力で調査する手間を考えると、Slack上でこのレベルの情報をプロンプトだけで取得することができるのは、かなり楽なのではないかと思います。
今回は簡単なプロンプトで調査をしましたが、プロンプトの工夫と権限付与（IAMロール）を駆使すれば、あらゆるリソースのアラートを分析できるはずです。（願望）
また、個人的な推しポイントは AWSコンソールにログイン不要 な点です。
運用の現場において何かしらの障害が発生すると、現場もピリついて、緊張からオペミスも頻発します。（私だけかもしれませんが）
そういう時に複数のAWS環境で運用をしていると、間違えて違うAWSアカウントにログイン→操作してしまうなど、致命的なことをやらかしがちです。
ですので、今回紹介したようなAWSコンソールにログインせずとも、Slack上でアラート調査ができるということは、致命的なオペミスを防ぐこともできるのでは!?と個人的に思っています。
長くなりましたが、Amazon Q Developerは運用現場での活躍も期待できますので、これからも追い続けていきたいと思います！
