SSM State Manager の関連付けの実行時に停止中の対象マネージドノードがある場合の挙動を確認してみた

はじめに

テクニカルサポートの 片方 です。
State Manager の関連付け をスケジュール実行している環境で、実行タイミングに対象のマネージドノードが停止していた場合、どのような挙動になるのか気になりました。
例えば、State Manager で AWS-UpdateSSMAgent などの Command ドキュメントを関連付け、タグを条件に複数の EC2 インスタンスを対象としているケースを考えます。

このとき、スケジュール実行時点で対象の EC2 インスタンスが停止していると、SSM Agent は動作していないため、State Manager や Run Command の実行結果がどのように表示されるのか判断できないケースがありました。
また、停止していた EC2 インスタンスが後から起動した場合に、関連付けが自動的に適用されるのか、それとも次回のスケジュール実行まで待つ必要があるのかも、運用上気になるポイントです。

そこで本ブログでは、State Manager の関連付け実行時に停止中の対象マネージドノードがある場合の挙動について、実際に検証を行い確認した内容を整理しました。

先に結論から

State Manager の関連付け実行時に対象マネージドノードが停止している場合の挙動は、ターゲットの指定方法やマネージドノードの状態によって異なりました。

今回確認した範囲では、State Manager 側で「成功」と表示される場合でも、対象ノード上でコマンドが実行されているとは限りませんでした。State Manager のステータスだけで判断せず、関連実行ターゲット、Run Command のコマンド履歴、対象ノードごとの実行結果をあわせて確認することが重要です。

対象マネージドノードが停止中の場合の挙動

「インスタンスタグを指定」した場合、State Manager のステータスおよび実行履歴は成功として表示されました。ただし、実行 ID を選択して関連実行ターゲットを確認すると、「実行ターゲットが見つかりません」と表示され、対象ノード上で AWS-UpdateSSMAgent が実行されたわけではありませんでした。

「リソースグループを選択」した場合、State Manager 側のステータスは Pending、状況の詳細は Creating と表示されました。関連実行ターゲットでは「実行ターゲットが見つかりません」と表示され、対応する Run Command も確認できませんでした。

「すべてのインスタンスを選択」した場合も、State Manager 側のステータスは Pending、状況の詳細は Creating と表示されました。一方で、Run Command 側には対応するコマンド履歴が作成され、全体的なステータスは「成功」、詳細なステータスは「タグにインスタンスがない」と表示されました。ただし、この「成功」は対象ノード上でコマンドが実行されたことを意味しません。

「インスタンスを手動で選択」については、対象マネージドノードが停止中の状態だと選択できなかったため、対象 EC2 インスタンスが起動中の状態で関連付けを作成し、その後対象 EC2 インスタンスを停止してから関連付けを再実行しました。この場合、State Manager 側では成功と表示されましたが、関連実行ターゲットでは「実行ターゲットが見つかりません」と表示され、停止中時点では対応する Run Command も確認できませんでした。

いずれのケースでも、対象マネージドノードが停止中の時点では、対象ノード上で AWS-UpdateSSMAgent は実行されていませんでした。

停止していたマネージドノードを後から起動した場合

停止していたマネージドノードを後から起動し、Systems Manager からオンラインとして認識されると、State Manager によって関連付けが実行される場合があります。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/state-manager-about.html

今回確認した範囲では、起動後の挙動もターゲットの指定方法によって差分がありました。

1 台のみ起動中、1 台が停止中の場合

補足

cron 式でスケジュールされた関連付けで ApplyOnlyAtCronInterval を有効にすると、関連付けの作成直後や更新直後の即時実行を抑止し、次回の指定された Cron 間隔まで実行を待機できます。なお、ApplyOnlyAtCronInterval は rate 式ではサポートされません。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/state-manager-associations-creating.html?utm_source=openai

オフセットを使用するには、コンソールの [次に指定した Cron の間隔でのみ関連付けを適用する] オプションを選択するか、コマンドラインから ApplyOnlyAtCronInterval パラメータを指定する必要があります。これらのオプションのいずれかをアクティブにすると、関連付けを作成した後、State Manager がすぐに実行されないようにできます。

確認してみた: 対象マネージドノードがすべて停止中の場合

今回は、検証用の EC2 インスタンスを 2 台用意しました。どちらの EC2 インスタンスにも同じタグを付与しています。
また、このタグを利用して、リソースグループも作成しました。

まずは、ターゲット条件に一致する対象マネージドノードがすべて停止中の場合の挙動を確認します。
検証時点では、対象となる 2 台の EC2 インスタンスをどちらも停止状態にしています。
対象の EC2 インスタンスが停止しているため、SSM Agent は動作していません。そのため、Systems Manager から見ると、対象ノードは関連付けを実行できるオンラインのマネージドノードとしては扱われません。
以下は、対象の EC2 インスタンス 2 台が停止している状態です。

次に、State Manager で関連付けを作成します。
今回は、Command ドキュメントとして AWS-UpdateSSMAgent を指定しています。
それでは、ターゲットの選択方法による挙動の違いを確認していきます。

インスタンスタグを指定した場合

まずは、ターゲットの選択で「インスタンスタグを指定」を選択した場合の挙動を確認します。
関連付けの作成画面で、ターゲットの選択に「インスタンスタグを指定」を選択し、検証用 EC2 インスタンスに付与したタグを指定します。

関連付けを作成後、State Manager の関連付け画面を確認します。
確認した環境では、対象マネージドノードがすべて停止中であっても、State Manager 側のステータスは「成功」と表示されました。

実行履歴を確認しても、ステータスは「成功」、状況の詳細は Success と表示されていました。
一方で、実行 ID を選択して関連実行ターゲットを確認すると、「実行ターゲットが見つかりません」と表示されていました。

この結果から、ターゲットの選択で「インスタンスタグを指定」を選択した場合、対象マネージドノードがすべて停止中でも、State Manager 側の実行履歴は成功として扱われることが分かりました。
ただし、関連実行ターゲットには実行対象が表示されていません。そのため、この「成功」は、対象マネージドノード上で AWS-UpdateSSMAgent が実行され、正常終了したことを意味するものではありません。

今回の結果をまとめると、以下のとおりです。

State Manager 側で「成功」と表示されていても、対象ノードに関連付けが適用されたとは限りません。

今回のケースでは、対象マネージドノードが停止中で SSM Agent が動作していないため、対象ノード上でコマンドは実行されていませんでした。State Manager のステータスだけで判断せず、実行履歴の関連実行ターゲットや Run Command のコマンド履歴もあわせて確認することが重要です。

停止していたマネージドノードを起動した場合

今回の検証では、「次に指定された cron 間隔でのみ関連付けを適用する」オプションは選択していません。
※ 以降の検証でも同様に、このオプションは選択していません。

停止していた EC2 インスタンスを起動し、Systems Manager からオンラインとして認識されるか確認します。
対象の EC2 インスタンスがオンラインになった後、State Manager の関連付けを確認すると、関連付けが実行されていました。
対象の EC2 インスタンスが Systems Manager からオンラインとして認識された後、State Manager の実行履歴を再度確認すると、停止中に作成されていた実行 ID に関連する形で Run Command が実行されていました。
この挙動は、後述する「すべてのインスタンスを選択した場合」と同様です。

リソースグループを選択した場合

次に、ターゲットの選択で「リソースグループを選択」を選択した場合の挙動を確認します。
今回は、検証用 EC2 インスタンスに付与したタグを条件にしたリソースグループを事前に作成しています。関連付けの作成画面では、ターゲットの選択に「リソースグループを選択」を選択し、作成済みのリソースグループを指定します。

関連付けを作成後、State Manager の関連付け画面を確認します。

確認した環境では、対象マネージドノードがすべて停止中の場合、State Manager 側のステータスは「保留中」と表示されました。また、状況の詳細は Creating と表示されていました。

実行履歴を確認すると、実行 ID は作成されていました。
ただし、実行 ID を選択して関連実行ターゲットを確認すると、インスタンスタグを指定した場合と同様に 「実行ターゲットが見つかりません」 と表示されていました。
Run Command のコマンド履歴を確認しても同様に、この関連付けに対応する Run Command は確認できませんでした。

今回の結果をまとめると、以下のとおりです。

「インスタンスタグを指定」を選択した場合は、State Manager 側のステータスおよび実行履歴が成功として表示されました。一方で、「リソースグループを選択」を選択した場合は、State Manager 側のステータスが「保留中」、状況の詳細が Creating と表示されました。
ただし、どちらの場合も、実行 ID を選択して関連実行ターゲットを確認すると「実行ターゲットが見つかりません」と表示され、Run Command のコマンド履歴にも対応する実行は確認できませんでした。
そのため、State Manager 側のステータス表示には差分があるものの、対象マネージドノード上でコマンドが実行されていない点は同じです。

停止していたマネージドノードを起動した場合

対象の EC2 インスタンスがオンラインになった後、State Manager の関連付けを確認すると、関連付けが実行されました。
このとき、停止中に作成されていた実行 ID が再利用されるのではなく、新しい実行 ID が作成されていました。
また、Run Command 側にも新しいコマンド履歴が作成され、対象ノード上で AWS-UpdateSSMAgent が実行されていることを確認できました。
一方で、以下のように、対象マネージドノードがすべて停止中だったときに作成された Pending / Creating の実行履歴は、確認時点では残っていました。

すべてのインスタンスを選択した場合

次に、ターゲットの選択で「すべてのインスタンスを選択」を選択した場合の挙動を確認します。
関連付けの作成画面では、ターゲットの選択に「すべてのインスタンスを選択」を選択します。
関連付けを作成後、State Manager の関連付け画面を確認します。
確認した環境では、対象マネージドノードがすべて停止中の場合、State Manager 側のステータスは「保留中」と表示されました。また、状況の詳細は Creating と表示されていました。

実行履歴を確認すると、実行 ID は作成されていました。
ただし、実行 ID を選択して関連実行ターゲットを確認すると、「実行ターゲットが見つかりません」と表示されていました。

続いて、Run Command のコマンド履歴を確認します。
確認した環境では、この関連付けに対応する Run Command が作成されていました。
ただし、Run Command 側のステータスは以下のとおりでした。

• 全体的なステータス: 成功
• 詳細なステータス: タグにインスタンスがない

検証時点では、State Manager 側の実行履歴の作成日が Sun, 07 Jun 2026 07:30:33 GMT と表示されていました。
Run Command のコマンド履歴にも、同時刻に作成された AWS-UpdateSSMAgent の履歴があることを確認しました。

ここで表示される Run Command の全体ステータスが「成功」であっても、必ずしもすべての対象ノード上でコマンドが処理されたことを意味するわけではありません。特にタグ指定で対象に一致するインスタンスが見つからない場合でも、Run Command のステータスが Success になることがあります。`

今回のケースでは、対象マネージドノードがすべて停止中であり、Systems Manager からオンラインとして認識される実行可能な対象が存在しなかったため、実行対象なしの状態として扱われています。

そのため、Run Command の履歴は作成されているものの、対象ノード上で AWS-UpdateSSMAgent は実行されていません。

今回の結果をまとめると、以下のとおりです。

この結果から、ターゲットの選択で「すべてのインスタンスを選択」を選択した場合、対象マネージドノードがすべて停止中だと、State Manager 側のステータスは「保留中」、状況の詳細は Creating と表示されることが分かりました。
また、実行履歴の関連実行ターゲットでは「実行ターゲットが見つかりません」と表示されました。

一方で、Run Command 側には対応するコマンド履歴が作成されており、全体的なステータスは「成功」、詳細なステータスは「タグにインスタンスがない」と表示されました。
ただし、この Run Command 側の「成功」は、停止中の対象マネージドノード上でコマンドが成功したことを意味しません。対象ノードは停止中で SSM Agent が動作していないため、対象ノード上でコマンドは実行されていませんでした。

停止していたマネージドノードを起動した場合

対象の EC2 インスタンスがオンラインになった後、State Manager の関連付けを確認すると、関連付けが実行されていました。
今回の確認では、State Manager 側では、停止中に作成されていた実行 ID がそのまま利用され、ステータスが成功に更新されていました。

一方で、Run Command 側では新しいコマンド履歴が作成されていました。
Run Command の実行結果を確認すると、対象ノード上で AWS-UpdateSSMAgent が実行されていることを確認できました。

インスタンスを手動で選択した場合

次に、ターゲットの選択で「インスタンスを手動で選択」を選択した場合の挙動を確認します。
なお、「インスタンスを手動で選択」では、Systems Manager から操作可能なマネージドノードとして認識されているノードのみが一覧に表示されるため、停止中の EC2 インスタンスは選択できませんでした。今回は以下の流れで検証しました。

1. 対象の EC2 インスタンス 2 台を起動した状態にする
2. State Manager の関連付けを作成する
3. ターゲットの選択で「インスタンスを手動で選択」を選択する
4. 関連付けが正常に実行されることを確認する
5. 対象の EC2 インスタンス 2 台を停止する
6. State Manager の cron 式などを編集し、関連付けを再実行する

まず、対象の EC2 インスタンスが起動中の状態で、State Manager の関連付けを作成します。
関連付けの作成画面では、ターゲットの選択に「インスタンスを手動で選択」を選択し、検証用の EC2 インスタンス 2 台を指定します。
起動中の状態では、対象マネージドノードに対して関連付けが実行され、State Manager 側のステータスは「成功」となりました。

次に、対象の EC2 インスタンス 2 台を停止します。

その後、State Manager の cron 式などを編集し、関連付けを再実行しました。
今回は、例として以下のようにスケジュールを変更しています。

cron(0 */30 * * * ? *) ⇒ rate(16 hours)

確認した環境では、対象マネージドノードが停止中であっても、State Manager 側のステータスは「成功」と表示されました。また、実行履歴側でも、実行 ID のステータスは「成功」、状況の詳細は Success と表示されていました。

一方で、実行 ID を選択して関連実行ターゲットを確認すると、「実行ターゲットが見つかりません」と表示されていました。

続いて、Run Command のコマンド履歴を確認しました。
確認した環境では、この再実行に対応する Run Command のコマンド履歴は確認できませんでした。
この結果から、「インスタンスを手動で選択」を選択している場合でも、関連付けの実行タイミングで対象マネージドノードが停止中であれば、対象ノード上で AWS-UpdateSSMAgent は実行されないことが分かりました。

また、State Manager 側では「成功」と表示されていても、関連実行ターゲットでは「実行ターゲットが見つかりません」と表示され、Run Command のコマンド履歴にも対応する実行は確認できませんでした。

今回の結果をまとめると、以下のとおりです。

停止していたマネージドノードを起動した場合

対象の EC2 インスタンスがオンラインになった後、State Manager の関連付けを確認すると、関連付けが実行されていました。
対象の EC2 インスタンスが Systems Manager からオンラインとして認識された後、State Manager の実行履歴を再度確認すると、停止中に作成されていた実行 ID に関連する形で Run Command が実行されていました。
今回の確認では、実行 ID 0a03df8b-f02b-494d-a5d8-85a2a18e4447 に対して、対象ノード上で AWS-UpdateSSMAgent が実行されたことを確認できました。

Run Command 側にも新しいコマンド履歴が作成され、対象ノード上で AWS-UpdateSSMAgent が実行されていることを確認できました。

確認してみた: 対象マネージドノードのうち 1 台のみ起動中の場合

インスタンスタグを指定、リソースグループを選択、すべてのインスタンスを選択した場合

次に、対象マネージドノードのうち 1 台のみが起動中の場合の挙動を確認します。
今回は、検証用の EC2 インスタンス 2 台のうち、1 台を起動中、もう 1 台を停止中の状態にしました。

以下は、対象の EC2 インスタンスのうち 1 台が起動中、1 台が停止中の状態です。

この状態で State Manager の関連付けを実行します。
確認した環境では、State Manager 側のステータスは「成功」と表示されました。
また、実行 ID を選択して関連実行ターゲットを確認すると、起動中のマネージドノードのみが表示されていました。

一方で、停止中のマネージドノードは関連実行ターゲットに表示されませんでした。
このことから、対象条件に一致するマネージドノードが 2 台存在していても、関連付けの実行タイミングで 1 台が停止中の場合、State Manager の実行対象として表示されるのは Systems Manager からオンラインとして認識されているマネージドノードのみであることが分かりました。
なお、Run Command 側の履歴においても、停止中のマネージドノードへの実行は確認できませんでした。

今回の結果をまとめると、以下のとおりです。

この結果から、1 台以上のマネージドノードがオンラインの場合、State Manager の関連付けはオンラインのマネージドノードに対して実行され、関連付け全体のステータスは成功となることを確認できました。
ただし、この「成功」は、停止中のマネージドノードにも関連付けが適用されたことを意味しません。停止中のマネージドノードは関連実行ターゲットに表示されず、対象ノード上で AWS-UpdateSSMAgent は実行されていませんでした。

停止していたマネージドノードを起動した場合

停止していた EC2 インスタンス (マネージドノード) を起動し、Systems Manager からオンラインとして認識されるか確認します。
以前と同様に、「次に指定された cron 間隔でのみ関連付けを適用する」オプションは選択していません。
対象の EC2 インスタンスがオンラインになった後、State Manager の関連付けを確認すると、関連付けが実行されていました。
対象の EC2 インスタンスが Systems Manager からオンラインとして認識された後、State Manager の実行履歴を再度確認すると、成功した実行 ID に関連する形で Run Command が実行されていました。
今回の確認では、実行 ID 79258a37-ce2d-48ea-a565-e4bd177af5a7 に対して、対象ノード上で AWS-UpdateSSMAgent が実行されたことを確認できました。
こちらでは、Success:1 が Success:2 に変化しており、関連実行ターゲットでも、起動した EC2 インスタンスの関連付けが追加されています。

Run Command 側にも新しいコマンド履歴が作成され、後から起動した対象マネージドノードのみで AWS-UpdateSSMAgent が実行されていることを確認できました。

各結果の詳細は省略しますが、「インスタンスタグを指定」「リソースグループを選択」「すべてのインスタンスを選択」では同様の検証結果となりました。

インスタンスを手動で選択した場合

次に、ターゲットの選択で「インスタンスを手動で選択」を選択した場合の挙動を確認します。
なお、「インスタンスを手動で選択」では、Systems Manager から操作可能なマネージドノードとして認識されているノードのみが一覧に表示されるため、停止中の EC2 インスタンスは選択できませんでした。今回は以下の流れで検証しました。

1. 対象の EC2 インスタンス 2 台を起動した状態にする
2. State Manager の関連付けを作成する
3. ターゲットの選択で「インスタンスを手動で選択」を選択する
4. 関連付けが正常に実行されることを確認する
5. 対象の EC2 インスタンス 1 台のみを停止する
6. State Manager の cron 式などを編集し、関連付けを再実行する

まず、対象の EC2 インスタンスが起動中の状態で、State Manager の関連付けを作成します。
関連付けの作成画面では、ターゲットの選択に「インスタンスを手動で選択」を選択し、検証用の EC2 インスタンス 2 台を指定します。
起動中の状態では、対象マネージドノードに対して関連付けが実行され、State Manager 側のステータスは「成功」となりました。次に、対象の EC2 インスタンス 1 台を停止します。
その後、State Manager の cron 式などを編集し、関連付けを再実行しました。
今回は、例として以下のようにスケジュールを変更しています。

cron(0 */30 * * * ? *) ⇒ rate(14 days)

確認した環境では、1 台が停止中の状態で関連付けを再実行すると、関連付けステータス別インスタンス数は Pending:1, Success:1 と表示されました。

実行履歴では、ステータスは「保留中」、状況の詳細は InProgress と表示されていました。

関連実行ターゲットを確認すると、停止中のマネージドノードが InProgress と表示されていました。

Run Command 側でも、該当するコマンドが進行中として存在していました。

今回の結果をまとめると、以下のとおりです。

停止していたマネージドノードを起動した場合

対象の EC2 インスタンスがオンラインになった後、State Manager の関連付けを確認すると、関連付けが実行されていました。
対象の EC2 インスタンスが Systems Manager からオンラインとして認識された後、State Manager の実行履歴を再度確認すると、成功した実行 ID (95a88718-5bac-4535-ac6b-7a67da0beb41) に関連する形で Run Command が実行されていました。

Run Command 側では、先ほど進行中だったコマンドが成功となり、コマンド履歴として確認できるようになりました。

起動後の結果をまとめると、以下のとおりです。

この結果から、「インスタンスを手動で選択」した場合、1 台が停止中の状態で関連付けを再実行すると、停止中のノードは InProgress として扱われ、Run Command 側にも進行中のコマンドとして残ることが分かりました。
その後、停止していたマネージドノードを起動すると、進行中だった実行が成功に遷移し、対象ノード上で AWS-UpdateSSMAgent が実行されました。

まとめ

State Manager の関連付けでは、ステータスが「成功」と表示されていても、対象ノード上でコマンドが実行されているとは限りません。運用時は、State Manager の実行履歴だけでなく、関連実行ターゲットと Run Command のコマンド履歴も併せて確認することをおすすめします。
本ブログが誰かの参考になれば幸いです。

参考資料

• AWS Systems Manager State Manager - AWS Systems Manager
• 関連付けの作成 - AWS Systems Manager
• State Manager の仕組みについて - AWS Systems Manager

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました