以下の内容はhttps://xp-cloud.jp/blog/2026/04/02/100000より取得しました。

SSM Run Command×EventBridge Scheduler×SNSで実現する“失敗時だけ通知”運用

AWS Systems Manager AWS

はじめに

こんにちは。今回はEventBridge Schedulerを使ってRun Commandを自動実行し、
失敗したときだけSNSで通知する構成についてご紹介します。

Run Commandを使用することで、メンテナンス前後のサーバーの稼働状況や主要サービス、
エージェントの動作確認など毎回サーバーにログインして手動実行する手間を減らすことができます。

さらにはEventBridge Schedulerを組み合わせ、指定した時刻に自動実行することも可能です！

今回はコマンドの自動実行、スケジューリング、そして異常時のみSNS通知する構成を検証します。
ぜひ参考にしてみてください。

検証構成

  • EC2： 1台 (SSMマネージドインスタンス)
  • IAMロール： 2つ (EventBridgeルール用ロール / Scheduler用実行ロール)
  • Run Command： 手動実行および Scheduler 経由の自動実行で使用
  • EventBridge ルール：1本（Run Command の失敗イベントを検知）
  • EventBridge Scheduler： 1本（Run Command を自動実行）
  • SNS トピック：1つ（メール通知用）

IAMロール・ポリシー作成

今回、EventBridgeルールからSNSへ通知するためのロールは、ルール作成時に自動生成されたものを利用しました。
ここでは、Scheduler用実行ロールを作成していきます。

  • AWSコンソール＞IAM＞ロール＞ロールを作成をクリック
  • 信頼されたエンティティタイプを選択＞カスタム信頼ポリシーに以下のJSONコードを入力
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "scheduler.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
  • 許可ポリシーは選択せずに、次へ＞任意のロール名を入力＞ロールを作成をクリック

次に、作成したロールにポリシーを付与します。
今回は、EventBridge Scheduler から SSM の Run Command を実行するためのポリシーを設定します。

  • 作成したロールを開き、許可ポリシー欄から許可を追加＞インラインポリシーを選択
  • ポリシーエディタでJSONを選択＞以下のJSONコードを入力＞次へ
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ssm:SendCommand",
      "Resource": [
        "arn:aws:ssm:ap-northeast-1::document/AWS-RunShellScript",
        "対象のEC2のインスタンスARNを記載"
      ]
    }
  ]
}
  • 任意のポリシー名を入力＞ポリシーの作成

手動で Run Command を実行する

IAMロールとポリシーまで準備ができたら、次はRun Commandを実行していきましょう。
まずは、対象EC2に対してRun Commandを作成し、成功するコマンドと失敗するコマンドを手動実行して挙動を確認します。
今回は AWS-RunShellScript を使用して、負荷の軽い簡単なコマンドを実行します。

①成功するコマンドを実行する

  • AWSコンソール＞AWS Systems Manager＞左メニューからRun Commandをクリック
  • 画面右側のRun Commandをクリック
  • コマンドドキュメント一覧から AWS-RunShellScript を選択
  • コマンドパラメータのCommandsに、以下のようなコマンドを入力します。
date
hostname
uptime
df -h /
  • ターゲット欄から、インスタンスを手動で選択する＞インスタンス欄で対象のインスタンスを選択します。 その他の設定はデフォルトでOKです。
  • 画面下部の実行ボタンをクリック

実行後、コマンド履歴の一覧に戻るので、対象のコマンドを選択します。
ステータスと詳細のステータスが成功であること、対象インスタンスが想定したEC2であることを確認します。
ターゲットと出力欄の出力の表示ボタンをクリックし、
Outputを選択すると出力結果を確認できるので併せて確認してみてください。

②失敗するコマンドを実行する

では、次に明示的にコマンドを失敗させて結果をみてみましょう。
①と同じ手順で、コマンドパラメータのCommandsには以下のコマンドを入力します。

echo "test start"
date
exit 1

コマンドの意図は以下としています。
- echo "test start"： 実行が始まったことを確認する
- date： 実行途中までは正常に動いていることを確認する
- exit 1：最後に明示的に異常終了させる

対象インスタンスは先ほどと同じEC2インスタンスを選択して実行します。
実行後は①と同じ手順で以下を確認します。
1. ステータス：失敗である
2. Output：test startと実行時間が出力されている
3. Error：failed to run commands: exit status 1が出力されている

この3点が確認できれば成功です！
対象EC2が Run Command を受け取れて、実行結果をOutputから確認し、
失敗時にはFailedとして判定されることも確認できました。

SNSトピックを作成する

ここでは、Run Command が失敗した際の通知先として SNS トピックを作成します。
今回はメールで通知を受け取れるように設定します。

  • AWSコンソール＞Amazon SNS＞左メニューからトピックを選択＞トピックの作成をクリック
  • タイプ：スタンダードを選択＞任意の名前を入力
  • 表示名：分かりやすい任意の通知名を入力＞トピックの作成をクリック
    今回の検証では「RunCommandFailure」にしました。

次にメールサブスクリプションを設定します。

  • 作成したトピックを開き、サブスクリプションの作成をクリック
  • プロトコル：Eメール
  • エンドポイント：通知を受けたいメールアドレス
  • サブスクリプションを作成 をクリック

この後、確認メールが届きます。
届いたメールの「Confirm subscription」のリンクをクリックしてください。
SNS画面に戻り、ステータスが確認済みになればOKです。

EventBridgeルールを作成する

Run Command の失敗を検知し、SNSへ通知するためのEventBridgeルールを作成します。
まずはイベントを設定していきましょう。

  • AWSコンソール＞Amazon EventBridge＞左メニューから「ルール」を選択＞ルールを作成 をクリック
  • イベントバス：default

構築画面の「トリガーイベント」に「EC2 Command Invocation Status-change Notification」を
ドラックアンドドロップします。
画面左「イベント」から以下を選択し、トリガーイベントを設定してください。

  • イベントソース: AWS イベント
  • AWS のサービス: Systems Manager
  • イベントタイプ: EC2 Command Invocation Status-change Notification

イベントパターン (フィルター) には以下のJSONコードを入力してください。
検証対象EC2の失敗だけを通知するため、イベントパターンでインスタンスIDを指定します。

{
  "source": ["aws.ssm"],
  "detail-type": ["EC2 Command Invocation Status-change Notification"],
  "detail": {
    "status": ["Failed"],
    "instance-id": ["対象のEC2インスタンスID"]
  }
}

次に、ターゲットを設定します。
イベント設定時と同じ要領で画面左「ターゲット」から以下を選択し、ターゲットを選択します。
ターゲット設定 – SNS トピックでは、以下を設定します。

  • ターゲットの場所： このアカウントのターゲット
  • トピック：先ほど作成したSNSトピック
  • 実行ロール：この特定のリソースのために新しいロールを作成

次は、届くメールを整形する設定をしていきます。
今回は、アラート内容を分かりやすくするため、メール本文には以下の情報を表示させます。

・「ステータス」
・「対象EC2」
・「ドキュメント」
・「Command ID」
・「実行時刻」
・「詳細は Systems Manager > Run Command の履歴から確認してください。」

  • ターゲット欄の入力変換をクリックします

  • ターゲット入力変換 : 有効化
  • 入力トランスフォーマーを選択
  • 入力パス に以下のJSONコードを入力します。
{
  "status": "$.detail.status",
  "instanceId": "$.detail.instance-id",
  "documentName": "$.detail.document-name",
  "commandId": "$.detail.command-id",
  "requestedTime": "$.detail.requested-date-time"
}

テンプレートには以下を入力してください。

"SSM Run Command の失敗を検知しました。 / ステータス: <status> / 対象EC2: <instanceId> / ドキュメント: <documentName> / Command ID: <commandId> / 実行時刻: <requestedTime> / 詳細は Systems Manager > Run Command の履歴から確認してください。"

最後に画面上部の設定タブを選択して以下を設定し、作成 をクリックしてください。

  • Rule name：任意の名前
  • イベントバス：default

Schedulerで自動実行して通知確認

ルール作成後は、SchedulerからRun Commandを実行して通知内容を確認します。
今回は、失敗通知の確認用として「1回だけ実行する検証用Scheduler」を作成します。

  • AWSコンソール＞Amazon EventBridge Scheduler＞スケジュールを作成
  • 名前：任意の名前を入力
  • スケジュールグループ：default

スケジュールのパターンでは一回限りのスケジュールを選択し、任意の日付と時刻を設定してください。
「フレックスタイムウィンドウ」はオフにして、「次へ」をクリックします。

ターゲットの詳細では以下を選択します。

  • すべてのAPI
  • すべての AWS のサービス：Systems Manager
  • API：SendCommand

SendCommand欄に以下のJSONコードを入力して、Schedulerから送るRun Commandの内容を設定します。

{
  "DocumentName": "AWS-RunShellScript",
  "InstanceIds": [
    "対象のEC2インスタンスID"
  ],
  "Parameters": {
    "commands": [
      "echo \"scheduler test start\"",
      "date",
      "exit 1"
    ]
  }
}

入力が完了したら、「次へ」をクリックします。
アクセス許可欄では、以下を選択して次へをクリック

  • 既存のロールを使用
  • 既存の役割を選択：冒頭で作成したIAMロールを選択

スケジュールの確認と作成のページにて内容を確認し、問題なければスケジュールを作成します。

動作確認

最後に動作確認です。 動作確認では、主に次の３点を見ればOKです！

  • 失敗時に SNS のメール通知が届くこと
  • Scheduler から Run Command が実行されること
  • Systems Manager の Run Command 履歴で、対象EC2に対して実行されていること

まずはメールを見てみましょう。

表示名も「RunCommandFailure」になっていますね。
実行時刻と対象EC2も問題なく、Systems Manager の Run Commandから実行されていそうです。

では次に、メールに表示されているCommand IDから Run Commandの実行履歴をみてみます。

こちらも、失敗となっていて、実行時刻もスケジュールしたものになっていますね。
では、出力内容はどうでしょう。


コマンドがスタートして、 実行途中までは正常に動いた後に失敗しています。
想定通りですので、検証成功です！

まとめ

今回は、Run Command を EventBridge Scheduler で自動実行し、失敗したときだけ SNS で通知する構成を確認しました。

例えば、毎回サーバーにログインして行っていたメンテナンス前の稼働確認や、 主要サービスの起動確認、ディスク使用率の確認などを自動化したい場面で活用しやすい構成です。
今回はEventBridgeルールのイベントパターンで「対象のEC2インスタンスID」を指定しましたが、
SSMドキュメント名でも絞り込めるため、 別用途の実行結果を除外し、必要な通知だけを受け取る運用も可能です。

EventBridge Schedulerのスケジュール次第では定期的に自動実行させることもできます。
定期実行の設定方法については、こちらの記事でも紹介しています。
また、今回は 1 台の EC2 を対象に検証しましたが、同様の考え方で複数台への横断実行にも広げやすい構成です。
ぜひ、日々の運用で活用してみてください。　



以上の内容はhttps://xp-cloud.jp/blog/2026/04/02/100000より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14