AWS Chatbot

AWS Chatbot は、SlackやMicrosoft TeamsといったチャットツールとAWSをつなぐ対話型のエージェントサービスです。CloudWatchアラームや各種イベントの通知をチャンネルに見やすく届けるだけでなく、チャットの画面から一部のAWS CLIコマンドを実行して、その場で状況確認や対応ができます。運用のやり取りをチャットに集約し、ChatOpsを実現するための入り口となるサービスです。

解決する課題

• アラームや障害通知をメールやコンソールで個別に確認しており、チームの初動が遅れる → 普段使うチャットに集約して即座に気づきたい
• 通知を受けてからAWSコンソールにログインし直して調査するのが煩雑 → チャットからそのまま状況を確認・操作したい
• 通知が生のJSONで届いて内容が読み取りにくい → 重要度やリソース情報を整形して見やすく届けたい
• チャット経由の操作に過剰な権限が紐づくのが怖い → 実行できる操作の範囲を安全に絞り込みたい
• インシデント対応のやり取りや判断の経緯がチャットに残らない → 通知から対応までを同じ場所で記録したい

主要概念と用語

• 設定済みクライアント（Configured Client）: AWS Chatbot と連携させたSlackワークスペースまたはMicrosoft Teamsのチーム。最初に一度だけ承認・登録する
• チャネル設定（Channel Configuration）: 通知を届ける個々のチャンネルと、そこで使うIAMロールや通知元をひも付けた設定単位
• IAMロール（チャネルロール）: チャットからコマンドを実行する際に引き受けるロール。この権限がチャット経由で実行できる操作の上限になる
• ガードレールポリシー（Guardrail Policy）: チャネルロールに重ねて適用する上限ポリシー。許可される操作の範囲を全体として制限する
• SNSトピック連携: 通知の入口。CloudWatchアラームやEventBridgeなどがSNSトピックに発行したメッセージを Chatbot が受け取りチャンネルへ転送する
• 通知（Notifications）: チャンネルへ届くアラームやイベントのメッセージ。重要度やリソース情報を整形したカード形式で表示される
• コマンド実行（Run Commands）: チャットにコマンドを入力してAWS操作を行う機能。読み取り系の確認から一部の変更操作まで対応する

仕様・制限・クォータ

• 連携先のチャットツールはSlackとMicrosoft Teamsに対応する。チャンネルごとに チャネル設定 を作成して通知元と権限をひも付ける
• 通知の入口は基本的に SNSトピック で、CloudWatchアラーム・EventBridgeルール・Budgetsなど多くのサービスがSNS経由で通知を送れる
• チャットから実行できるのは 読み取り中心のAWS CLIコマンドで、一部の操作はチャット経由では実行できないよう制限される。実行可能な範囲はチャネルロールとガードレールで決まる
• 1つのチャンネルに複数の通知元（複数のSNSトピック）をひも付けたり、複数チャンネルへ通知を出したりできる
• ワークスペース・チームやチャネル設定の数にはアカウント単位のクォータがあり、必要に応じて上限緩和を申請できる
• 近年はサービスのブランドが Amazon Q Developer in chat applications として案内される場面があるが、提供される連携機能の位置づけは同じである

内部の仕組み

AWS Chatbot は、通知の配信とコマンドの実行という2つの役割を担います。通知の流れでは、CloudWatchアラームやEventBridge、Budgetsなどが SNSトピック にメッセージを発行し、そのトピックを購読している Chatbot がメッセージを受け取ります。Chatbot は受け取った内容を解釈し、重要度やリソース情報を整形したカード形式で、ひも付けられたSlackまたはTeamsのチャンネルへ転送します。

コマンド実行の流れでは、利用者がチャンネルでコマンドを入力すると、Chatbot がそのチャンネルの チャネル設定 に紐づく IAMロール を引き受けて操作を実行します。実行できる操作はこのロールの権限の範囲に限られ、さらに ガードレールポリシー を重ねることで、ロールが広めでも全体として許可される操作を絞り込めます。

設計パターン / ベストプラクティス

• 通知の入口をSNSに統一する: アラームやイベントを一度SNSトピックに集約し、そこから Chatbot に渡す構成にすると通知元の追加・変更が容易になる
• チャンネルを用途で分ける: 本番アラート用、コスト通知用、開発向けなどチャンネルを分け、それぞれに適した通知元と権限をひも付ける
• 権限は最小限から始める: 最初は読み取り中心の権限に絞り、必要に応じて操作権限を足していく。ガードレールで全体の上限を固定しておく
• 重要度でフィルタする: すべてのイベントを流すとノイズになるため、EventBridgeやアラームのしきい値で重要な通知だけをチャンネルへ送る
• インシデント運用に組み込む: アラーム受信からチャットでの一次調査・連絡までを同じチャンネルで完結させ、対応の経緯を残す

運用・監視

• どのチャンネルにどの通知元・どのIAMロールがひも付いているかを定期的に棚卸しし、不要なチャネル設定を整理する
• チャット経由で実行されたコマンドや通知の配信状況は CloudTrail や CloudWatch のログ・メトリクスで追跡できる
• 通知が届かない場合は、SNSトピックの購読設定・チャネル設定・チャットツール側のアプリ承認のいずれかを順に確認する
• ノイズが多い場合は通知元のしきい値やイベントパターンを見直し、本当に必要な通知だけが流れる状態を保つ

コスト

AWS Chatbot の連携機能そのものは追加料金なしで利用できます。ただし、通知の入口に使う SNS のメッセージ発行や、通知元となる CloudWatch・EventBridge など、連携する各サービスの利用にはそれぞれの料金が発生します。また、チャットから実行したコマンドが他のAWSサービスのAPIを呼ぶ場合、その操作の結果として各サービス側で課金されることがあります。最新の料金体系は公式の料金ページで確認してください。

セキュリティ

• チャット経由で実行できる操作は チャネルロール の権限に限られる。本番リソースを変更しうる権限は付けず、読み取り中心に絞るのが基本
• ガードレールポリシー を全チャネルに適用し、たとえロールが広めでも実行可能な操作の上限を固定する
• 連携するSlackワークスペースやMicrosoft Teamsのチームは信頼できるものに限定し、誰がチャンネルで操作できるかをチャット側の参加管理でも制御する
• すべての操作と通知配信は CloudTrail に記録されるため、誰がいつチャットからどの操作を行ったかを監査できる
• 機密性の高い情報を含む通知をチャンネルへ流す場合は、チャンネルの公開範囲と参加メンバーを管理し、不要な共有を避ける

関連サービス・比較

通知の配信という点では Amazon SNS と役割が重なって見えますが、SNS が汎用のメッセージ配信基盤であるのに対し、AWS Chatbot はチャットツールに特化して整形表示とコマンド実行まで担う点が異なります。実際には両者を組み合わせ、SNS を入口、Chatbot をチャット連携層として使います。

ハンズオン / CLI例

# 通知の入口となるSNSトピックを作成
aws sns create-topic --name ops-alerts

# CloudWatchアラームの通知先に上記SNSトピックを指定（ARNは前の出力を使う）
aws cloudwatch put-metric-alarm \
  --alarm-name high-cpu \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:ops-alerts

# 既存のSlack向けチャネル設定を一覧で確認
aws chatbot describe-slack-channel-configurations \
  --query "SlackChannelConfigurations[].{Name:ConfigurationName,Channel:SlackChannelName,Role:IamRoleArn}"