概要
EC2 インスタンスのステータスチェックが失敗したら再起動する、ディスクがあふれそうなら古いログを消す。CloudWatch アラームが鳴るたびに人が同じ手順を踏んでいるなら、その手順を Systems Manager Automation のランブックにして、アラームから自動で動かすのが定番の形です。
ところが、CloudWatch アラームの「アクション」には Automation のランブックを実行する選択肢がありません。アラームの状態変化を Amazon EventBridge のルールで受け、ルールのターゲットにランブックを直接指定するのが、コードを書かずに済む方法です。SNS トピックに Automation を購読させる、Lambda 関数を間に挟む、といった方法と比べて、管理するものが最も少なくなります。
この記事では、アラームからランブックまでの経路と、その途中で必要になる 2 つの IAM ロールを整理します。実践では、EC2 のステータスチェックを見張るアラームが ALARM になったら、インスタンスを再起動するカスタムランブックが自動で動くところまでを確かめます。

クラウドおさる見張り台の鐘(アラーム)が鳴ったら、当番の猿が手順書どおりに動く。猿山では毎回寝ぼけた当番を起こしているでござるが、今日は鐘の音で手順書が勝手に動く仕掛けを作るでござるよ。
この記事のメリット
- CloudWatch アラームから Automation のランブックを実行する経路(EventBridge ルール)を説明できるようになる
- SNS・Lambda・AWS Config を使う方法と比べて、どれが要件に合うかを判断できるようになる
- アラームの状態変化を特定のアラーム・特定の状態に絞るイベントパターンを書けるようになる
- EventBridge がランブックを起動するためのロールと、ランブックが AWS を操作するためのロールを区別できるようになる
執筆者とキャラクター紹介
執筆者:土肥(とひ)
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。


クラウドおさる



はじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。



基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。



猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
アラームのアクションで直接できること
CloudWatch アラームは、状態が変わったときに次のアクションを直接実行できます。
| アクション | 内容 |
|---|---|
| Amazon SNS | トピックに通知を送る |
| AWS Lambda | 関数を呼び出す |
| EC2 アクション | インスタンスの停止・終了・再起動・復旧(EC2 のメトリクスのアラームのみ) |
| Auto Scaling アクション | Auto Scaling グループをスケールする |
| Systems Manager | OpsItem の作成、Incident Manager のインシデントの作成(ALARM 状態のみ) |
再起動だけなら EC2 アクションで足ります。しかし「再起動して、起動したことを確かめて、ログを集める」のように手順が複数あるなら、ランブックにまとめたくなります。ランブックの実行はこの一覧に無いので、アラームが EventBridge に送る状態変化のイベントを使います。
選択肢の比較
| 方法 | 結果 |
|---|---|
| EventBridge ルールでアラームの状態変化を受け、ターゲットに Automation のランブックを指定する | 正しい。コードを書かずにランブックが動く |
| アラームの通知先の SNS トピックに Automation を購読させる | できない。SNS のサブスクリプションのプロトコルに Automation は無い |
| AWS Config のルールでアラームを評価する | 向かない。Config はリソースの設定を評価するもので、アラームの状態変化は扱わない |
アラームから Lambda 関数を呼び、関数の中で StartAutomationExecution を呼ぶ | 動くが、関数のコード・ランタイム・権限を自分で管理し続けることになる |



「SNS で通知しているのだから、そこに Automation をつなげばよい」と考えがちでござるが、SNS から Automation へは直接つなげないのでござる。鐘の音を手順書に届けるのは EventBridge、と覚えておくでござるぞ。
アラームの状態変化のイベント
アラームの状態が変わると、CloudWatch は EventBridge のデフォルトのイベントバスに CloudWatch Alarm State Change というイベントを送ります。ルールのイベントパターンで、どのアラームの、どの状態への変化かを絞り込みます。
{
"source": ["aws.cloudwatch"],
"detail-type": ["CloudWatch Alarm State Change"],
"detail": {
"alarmName": ["soa-web-status-check"],
"state": {
"value": ["ALARM"]
}
}
}alarmName を省くとすべてのアラームに反応し、state.value を省くと OK に戻ったときにもランブックが動いてしまいます。特定のアラームが ALARM になったときだけ動かすなら、両方を指定します。


2 つの IAM ロール
この構成では、権限を持つ主体が 2 つあります。
| ロール | 引き受けるサービス | 必要な権限 |
|---|---|---|
| EventBridge ルールのロール | events.amazonaws.com | ssm:StartAutomationExecution(ランブックの開始。リソースはランブックの automation-definition/ に加えて document/ と automation-execution/* も許可する)。ランブックに別のロールを渡すなら、そのロールの iam:PassRole も |
Automation の引き受けロール(AutomationAssumeRole) | ssm.amazonaws.com | ランブックの中で呼ぶ API(この記事では ec2:RebootInstances、ec2:DescribeInstances) |
ランブックのパラメータ AutomationAssumeRole を指定すると、Automation はそのロールでランブックの各ステップを実行します。必須のパラメータに値が無いと、ルール自体は作れても、ランブックは実行されません。



鐘を聞いて手順書を開く係(EventBridge のロール)と、手順書どおりに倉庫の扉を開け閉めする係(Automation のロール)は別の猿でござる。どちらの札が足りなくても仕掛けは止まるのでござるな。
実践
EC2 インスタンス soa-web のステータスチェックを見張るアラーム soa-web-status-check と、インスタンスを再起動するカスタムランブック soa-RebootInstance が用意されている状態から始めます。アラームが ALARM になったらランブックを実行する EventBridge ルール soa-alarm-to-automation を作り、アラームの状態を手動で ALARM にして、ランブックが自動で動くことを確かめます。
前提条件
- リージョン:
ap-northeast-1(東京) - 以下のリソースが作成済みであること
まだ用意していない場合は、「作り方の参考」の記事の手順で作れます。リソース名は、この記事の名前に読み替えてください。
| リソース種別 | リソース名 | 内容 | 作り方の参考 |
|---|---|---|---|
| EC2 インスタンス | soa-web | 再起動の対象(Amazon Linux 2023、t3.micro) | Amazon EC2 でインスタンスを起動しSSH接続する |
| CloudWatch アラーム | soa-web-status-check | soa-web の StatusCheckFailed_Instance が 1 以上で ALARM | Amazon CloudWatch でメトリクスとアラームを設定する |
| Automation ランブック(カスタム) | soa-RebootInstance | パラメータ InstanceId のインスタンスを再起動し、running になるまで待つ | ― |
| IAM ロール | soa-automation-reboot-role | ランブックが引き受けるロール(EC2 の再起動と参照を許可)。ランブックの AutomationAssumeRole の既定値に設定済み | ― |
| IAM ロール | soa-eventbridge-automation-role | EventBridge ルールのロール(soa-RebootInstance の開始と、soa-automation-reboot-role の iam:PassRole を許可) | ― |
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| EventBridge ルール | soa-alarm-to-automation | アラームの ALARM への変化を受けてランブックを実行する |
手順 1: ランブックの中身を確かめる
AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1(東京)であることを確認します。上部の検索バーに Systems Manager と入力し、「Systems Manager」を選択します。
左側ナビゲーションの「変更管理ツール」→「ドキュメント」を選択し、「自分が所有」タブで soa-RebootInstance を開きます(上部の検索バーに soa-RebootInstance と入力して開いても構いません)。ドキュメントの詳細は英語で表示されます。「Content」タブで、ランブックの中身を確認します。
- パラメータ:
InstanceId(再起動するインスタンス)とAutomationAssumeRole(既定値はsoa-automation-reboot-roleの ARN) - ステップ
rebootInstance:aws:executeAwsApiで EC2 のRebootInstancesを呼ぶ - ステップ
waitForRunning:aws:waitForAwsResourcePropertyでインスタンスの状態がrunningになるまで待つ


続けて、EC2 のコンソールで soa-web のインスタンス ID(i- で始まる値)を控えておきます。手順 3 で使います。
手順 2: イベントパターンを書く
上部の検索バーに EventBridge と入力し、「Amazon EventBridge」を選択します。左側ナビゲーションの「ルール」を選択し、「ルールを作成」をクリックします。最初に「ビルダーモード」を選ぶ画面が出る場合は、「アドバンストビルダー」を選びます。
「ルールの詳細を定義」で、以下を設定して「次へ」をクリックします。
- 名前:
soa-alarm-to-automation - イベントバス:
default
「イベントパターンを構築」で、以下を設定します。
- イベントソース: 「AWS イベントまたは EventBridge パートナーイベント」
- 作成のメソッド: 「カスタムパターン (JSON エディタ)」
- イベントパターン: 次の JSON を貼り付ける
{
"source": ["aws.cloudwatch"],
"detail-type": ["CloudWatch Alarm State Change"],
"detail": {
"alarmName": ["soa-web-status-check"],
"state": {
"value": ["ALARM"]
}
}
}

「次へ」をクリックします。
手順 3: ターゲットにランブックを指定する
「ターゲットを選択」で、以下を設定します。
- ターゲットタイプ: 「AWS のサービス」
- ターゲットを選択: 「Systems Manager オートメーション」
- ドキュメント:
soa-RebootInstance - 「自動化パラメータを設定」: 値の指定方法は「定数」のまま、
InstanceIdに手順 1 で控えたインスタンス ID を入力する。AutomationAssumeRole - オプションにはランブックの既定値(soa-automation-reboot-roleの ARN)が入っているので、そのままにする - 実行ロール: 「既存のロールを使用」で
soa-eventbridge-automation-roleを選択


「次へ」をクリックし、タグの画面も「次へ」で進みます。確認画面で内容を確かめ、「ルールの作成」をクリックします。ルールの一覧に soa-alarm-to-automation が「有効」で表示されることを確認します。
手順 4: アラームを ALARM にする
ステータスチェックを本当に失敗させるのは難しいので、SetAlarmState でアラームの状態を一時的に ALARM にします。状態が変わるので、EventBridge には本物の状態変化と同じイベントが届きます。
コンソール下部の「CloudShell」をクリックし、次のコマンドを実行します。
aws cloudwatch set-alarm-state \
--alarm-name soa-web-status-check \
--state-value ALARM \
--state-reason "EventBridge から Automation を起動するテスト"CloudWatch のコンソールで左側ナビゲーションの「アラーム」→「すべてのアラーム」を選択し、soa-web-status-check を開きます。「履歴」タブに、ALARM への状態の更新が記録されていることを確認します(次の評価で、アラームは実際のメトリクスに合わせて OK に戻ります)。


手順 5: ランブックが動いたことを確かめる
Systems Manager のコンソールで、左側ナビゲーションの「変更管理ツール」→「オートメーション」を選択します。ドキュメント名が soa-RebootInstance の実行が一覧に追加されています。実行 ID をクリックして、実行の詳細を開きます。
- 実行ステータスが「成功」になっている
- 「実行したステップ」に
rebootInstanceとwaitForRunningが並び、どちらも「成功」になっている - 折りたたまれている「入力パラメータ」を展開すると、
InstanceIdがsoa-webのインスタンス ID になっている





鐘を鳴らしただけで、誰も手順書を開かずに再起動まで終わったでござる。人が動いたのは「鐘を鳴らした」ところだけでござるな。
EC2 のコンソールで soa-web を選択し、「ステータスとアラーム」タブ、または「モニタリング」タブでインスタンスが稼働中のままであることも確認できます。



「アラームから手順書を動かしたい、しかもコードは増やしたくない」と聞かれたら、EventBridge のルールでランブックを直接呼ぶ形を思い出すのでござる。SNS や Config につなぐ選択肢と取り違えぬようにするでござるよ。
まとめ
| やりたいこと | 使うもの |
|---|---|
| アラームで通知だけ送る | アラームのアクション(SNS) |
| アラームで EC2 を 1 回再起動するだけ | アラームの EC2 アクション |
| アラームで複数の手順(ランブック)を実行する | EventBridge ルール(アラームの状態変化)→ ターゲットに Automation のランブック |
- CloudWatch アラームのアクションには、Automation のランブックを実行する選択肢が無い
- アラームは状態が変わると
CloudWatch Alarm State Changeイベントを EventBridge に送る。ルールのイベントパターンでalarmNameとstate.valueを絞る - EventBridge ルールのターゲットに Systems Manager オートメーションを選ぶと、Lambda を挟まずにランブックを実行できる
- SNS のサブスクリプションに Automation は指定できない。AWS Config はアラームの状態変化を扱わない
- EventBridge ルールのロール(ランブックの開始と
iam:PassRole)と、ランブックの引き受けロール(ランブックが呼ぶ API)は別物
参照先
- アラームアクション – Amazon CloudWatch
- アラームイベントと EventBridge – Amazon CloudWatch
- EventBridge イベントに基づくオートメーションを実行する – AWS Systems Manager
- aws:executeAwsApi — AWS API オペレーションの呼び出しと実行 – AWS Systems Manager
- aws:waitForAwsResourceProperty – AWS リソースプロパティを待つ – AWS Systems Manager
- Amazon EventBridge のイベントパターン – Amazon EventBridge
















