Auto Scaling グループのスタンバイを利用した EC2 停止→起動の手順を確認してみた
はじめに
Auto Scaling グループ（以下、ASG）配下の EC2 インスタンスをメンテナンスする際、一時的にスタンバイ状態にして作業し、終わったら InService に戻すという運用があります。
AWS re:Post のナレッジセンターにも基本的な手順が紹介されています。
このとき、スタンバイから元に戻す手順の順序を誤ると、意図しない新規インスタンスが起動されてしまい、元のインスタンスを戻せなくなるケースがあります。今回はこの挙動を実際に検証してみました。
前提：スタンバイ状態にするまでの準備
検証に入る前に、スタンバイ状態にするまでの準備と前提知識を整理します。
環境
ASG test-standby-asg を以下の設定で作成し、EC2 インスタンスが 1 台 InService で起動している状態からスタートします。
- 希望するキャパシティ（以下、希望容量）：1
- 最小キャパシティ：1
- 最大キャパシティ：1
最小キャパシティの変更が必要
インスタンスをスタンバイに設定する際、希望容量は自動的にデクリメントされます。デクリメント後の希望容量が最小キャパシティを下回る場合はエラーになるため、最小=1・希望=1 の状態ではスタンバイにできません。
AutoScalingGroup test-standby-asg has min-size=1, max-size=1, and desired-size=1. To place into standby 1 instance, please update the AutoScaling sizes appropriately.
そのため、あらかじめ最小キャパシティを 0 に変更してからスタンバイに設定します。
最小=0 に変更後、スタンバイに設定すると正常に EnteringStandby になりました。
スタンバイ中に EC2 を停止しても新規インスタンスは起動されない
スタンバイ中のインスタンスはヘルスチェックの対象外です。EC2 コンソールから停止しても、ASG は新規インスタンスを起動しません。
メンテナンス作業（停止→起動等）を終え、EC2 のステータスチェックに合格した状態から、復旧手順の検証に進みます。
検証：復旧手順の順序で挙動が変わるか
スタンバイから元の状態に戻すには、以下の 2 つの操作が必要です。
- インスタンスを InService に戻す
- ASG の最小キャパシティを 1 に戻す
この順序の違いで挙動がどう変わるかを検証しました。
パターンA：ASG 設定変更を先にする（NG）
先に ASG のグループサイズを元に戻します。希望容量が 0 のままだと最小を 1 にできない（バリデーションエラー）ため、希望容量も 1 にして更新します。
更新した結果、インスタンスが 2 台になってしまいました。元のインスタンスは Standby のまま、新たに Pending 状態のインスタンスが起動されています。
スタンバイのインスタンスは ASG のメンバーではありますが、希望容量のカウントには含まれません。そのため ASG は「InService が 0 台」と判断し、希望容量=1 を満たすために新規インスタンスを起動したわけです。
さらに、元のインスタンスを InService に戻そうとしてもエラーになります。
AutoScalingGroup test-standby-asg has min-size=1, max-size=1, and desired-size=1. To place in service 1 instance, please update the AutoScaling sizes appropriately.
新しいインスタンスが InService として存在しているため、最大=1 の制約に引っかかり、元のインスタンスを戻せません。
パターンA の結果：意図しない新規インスタンスが起動され、元のインスタンスを InService に戻せなくなった。
パターンB：InService に戻すのを先にする（OK）
環境をリセットし、同じスタンバイ状態（希望容量=0、スケーリング制限 0-1、インスタンス 1 台が Standby）から開始します。
先にインスタンスを InService に戻します。
InService に戻りました。注目すべき点は、希望容量が自動的に 0 → 1 にインクリメントされていることです。
公式ドキュメントにも、InService に戻すと希望容量がインクリメントされると記載されています。
After you put the instance back in service, the desired capacity is incremented to reflect how many instances are in the Auto Scaling group.
その後、グループサイズの編集から最小キャパシティを 1 に戻します。
最終状態：希望容量=1、スケーリング制限 1-1、元のインスタンス 1 台が InService で正常に復旧できました。
パターンB の結果：元のインスタンスのまま正常に復旧できた。
まとめ
| 手順 | 結果 |
|---|---|
| ASG 設定変更（希望容量+最小を 1 に戻す）→ InService | NG：新規インスタンスが起動され、元のインスタンスを戻せなくなる |
| InService → ASG 設定変更（最小を 1 に戻す） | OK：元のインスタンスのまま正常復旧 |
ポイントは以下の通りです。
- スタンバイのインスタンスは ASG の希望容量にカウントされない
- 希望容量を先に上げると、ASG は InService が足りないと判断して新規インスタンスを起動する
- InService に戻す操作は希望容量を自動でインクリメントするため、先に実行すれば新規起動は発生しない
参考になれば幸いです。
参考情報
- Amazon EC2 Auto Scaling API Reference - EnterStandby
- Temporarily remove instances from your Auto Scaling group
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました
