SSMオートメーションの失敗をAWS ChatbotでSlack通知してみる（Lambda不要）

2026.02.25
クラスメソッドオペレーションズの原田です。
SSMオートメーションドキュメントを使って、EC2を自動で起動し、特定の処理を実行させるケースは多いと思います。
しかしオートメーションドキュメント自体は便利ですが、何かしらのエラーや処理失敗した場合の検知に課題を感じることはないでしょうか。これまで私も毎回AWSコンソールを見に行く必要がありました。

例えば、EC2の起動に失敗したり、RunCommandのタイムアウトなどが該当します。
そこで今回は異常が発生した際に、Amazon Q Developer in chat applications (旧称：AWS Chatbot)からSlackへ通知を飛ばし、即座にメンバー間で共有できる仕組みを構築しました。
Lambdaなどで実装すれば柔軟な設定ができますが、詳細がすぐ必要でなく、とにかく異変に気付ければ良い場合には実装の手間も掛かりません。
 仕様仕様としては何かしらの問題があれば、Slackに通知すること。
オートメーションドキュメントのエラー詳細までは記載せず異変に気付ければいい。
時間を掛けずに実装できること
この3つを条件にしました。
 必要なものIAMロール
SNSトピック
EventBridge
AWS Chatbot
 IAMロールまず、必要なリソースとしてまずは基本となるIAMロールの作成です。今回は2つのIAMロールを作成する必要があります。
EventBridgeで利用します
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
ポリシーはSNSトピックに対しての通知が必要です。

※アカウントIDやリージョン、トピック名は自身の環境に合わせて書き換えてください
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sns:Publish"
        ],
        "Resource": "arn:aws:sns:ap-northeast-1:123456789012:TestTopic"
      }
    ]
  }
AWS ChatbotでもIAMロールとポリシーの設定が必要です
{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Principal": {
       "Service": "chatbot.amazonaws.com"
     },
     "Action": "sts:AssumeRole"
   }
 ]
}
今回ポリシーに関しては、AWS管理ポリシーのAmazonSSMReadOnlyAccessを設定します。

必要に応じて、カスタムポリシーを作成してください。
 SNSトピックSNSトピックが必要な理由は、EventBridgeからAWS Chatbotへ直接連携することができないためです。

できればいいのに！と思ったのですが、AWS ChatbotがSNSトピックをサブスクライブして通知を受け取る必要があり、情報源として設定する必要があるとのことです。
タイプはスタンダードを選択します。その他はデフォルトのままトピックの作成をクリックします。
【注意】SNSトピックのアクセスポリシーについて

作成したSNSトピック側で、EventBridgeからの書き込みを許可する必要があります。トピックの「アクセスポリシー」タブを編集し、以下のステートメントを追加（または上書き）してください。
{
  "Sid": "AllowEventBridgePublish",
  "Effect": "Allow",
  "Principal": {
    "Service": "events.amazonaws.com"
  },
  "Action": "sns:Publish",
  "Resource": "arn:aws:sns:ap-northeast-1:123456789012:TestTopic"
}
※ここでもResourceのARNは自身の環境に合わせて書き換えてください。
 EventBridgeルールの設定を行いますが、ルールが新しいメニューになっています。

下記の様にAWSからのイベントの場合はビジュアルビルダーという視覚的に理解しやすい操作へ変更されたようです。
このビジュアルビルダーでは、
AWS のサービスによって生成されたイベントのスキーマとサンプルペイロード、独自のアプリケーション、および EventBridge SaaS パートナーを検索して表示できます。
これらのイベントをトリガーイベントとして使用してルールを作成できます。

スケジュールされたルール
スケジュールされたルールは「スケジューラー」セクションに移動しました。引き続き、スケジュールされたルールの表示、編集、作成が可能です。
スケジュール設定のEventBridgeルールはスケジューラーから登録するように変わっています。
下記メニューの部分が以前のルールです。

こちらが定期実行などスケジュールを設定する項目へと変更されたようです。

では、今回はAWSのイベントになるのでビジュアルビルダーから設定します。

左に表示されるイベントとターゲットをドラッグアンドドロップで配置します。



今回はオートメーションドキュメントを利用しているので

イベントには、EC2AutomationExecutionStatusChangeNotificationを選び、ターゲットにはSNSトピックを設定し、作成したSNSトピックとIAMロールが候補に出てきますので選択するだけで完了です。


少し紛らわしいですが、SSMにも関わらず名前がEC2となっています。

（SSM（Systems Manager）は、かつて「Amazon EC2 Simple Systems Manager」という名称で、その名残が残っているようです）

SSMオートメーション全般のステータス変化をキャッチするための設定になります。
イベントパターンは以下です。

今回は失敗、タイムアウトもしくはキャンセルのイベントを通知するようにしました。
{
  "source": ["aws.ssm"],
  "detail-type": ["EC2 Automation Execution Status-change Notification"],
  "detail": {
    "Status": ["Failed", "TimedOut", "Cancelled"]
  }
}
 Amazon Q Developer in chat applications(AWS Chatbot)まだSlackワークスペースとの連携が終わっていない場合は連携する必要があります。

設定済クライアント > 新しいクライアントを設定からSlackを選択すると、Slackワークスペースに認証させるページへリダイレクトするので「許可する」を選択します。
(有効化されない場合はワークスペース管理者の許可が必要です)
次にチャンネルの設定を行います。

プライベートチャンネルの場合は、チャンネルIDが必要です。

（パブリックチャンネルはチャンネル名の候補が出力されるのでそのまま選択できます）

アクセス許可は先程AWS Chatbot用に作成したロールを選択します。

通知用に作成したSNSトピックを選択します。

 検証上記を設定したらオートメーションドキュメントを実行して実際にSlackに通知されるかを確認してみます。

今回は、リソースなど特に利用せず、実行後に失敗するものを用意します。

ドキュメントの内容は以下です。
schemaVersion: '0.3'
description: '意図的に失敗するAutomation'
mainSteps:
  - name: ForceFailure
    action: aws:executeScript
    isEnd: true
    inputs:
      Runtime: python3.11
      Handler: handler
      Script: |
        def handler(events, context):
          raise Exception("テスト失敗: EventBridge通知確認用")
このオートメーションドキュメントを実行すると無事にSlackへ通知が届くことが確認できました！

 まとめ今回の構成のポイントは、「最小限の手間で、異常に気付ける仕組みを作った」点にあります。
Lambda不要で、AWSのマネージドサービスを組み合わせるだけで完結します。実際10-15分で作業は完了しました。
Amazon Q Developer (AWS Chatbot) を介しているため、SlackからそのままAWSリソースの状況を確認することも可能です。
もちろん、エラーのスタックトレースを細かく通知したい、あるいは特定のキーワードに応じて処理を分岐させたいといった要望がある場合は、SNSの先にLambdaを挟むなどの拡張が必要になります。
しかし、まずは「何かあったらすぐに気づける」状態を作るだけで良いのであれば今回のAWS Chatbotでも十分です。
AWS Chatbotは最近名称が「Amazon Q Developer in chat applications」に統合されるなど、AIによるチャット体験も強化されています。通知だけでなく、Slack上からのトラブルシューティングなど、さらに一歩進んだ活用にも期待したいですね！