TL;DR
AutoScalingグループ内で稼働しているEC2のうち1台をスタンバイ状態へ変更し、さらにデタッチする際、いずれの操作においても「代替ノード補充」オプションを有効にしていないと稼働台数が減ってしまうため注意！
どういうケースでの話？
商用環境で常時2台のEC2インスタンスが稼働するAutoScalingグループがあったとする。
このうち1台の調子が悪いので、一時的に「スタンバイに設定」する。
このとき、サービス影響を出したくないため代替ノードを補充する。
スタンバイ移行時に「新しいインスタンスを追加」オプションを有効にして実行する。
すると当該インスタンスが「Standby」ライフサイクルへ移行すると同時に、代替インスタンスが「Pending」状態で出現し稼働準備をはじめる。
ハマりポイント
さて、問題はここから。
不良インスタンスが無事にスタンバイ状態となり、代わりの新規ノードを含めた2台が「InService」状態で元気に稼働している。
不良ノードのログ調査も完了したため、紛らわしいこいつはTerminateしてお掃除してしまいたい。
で、とりあえずインスタンス終了する前に**「ASGからデタッチしとくか」**という際に今回の問題が発生する。
デタッチの際も代替インスタンス補充要否のオプションが提示されるのだが、現状「2台がInService＋1台がStandby」なので**「インスタンス新規追加は不要だよ〜チェック入れずデタッチ…っと」**と進めてしまうと…
「ASGの台数設定に違反するからダメ〜！」と怒られてしまう。
そう、チェック無しだと「Standbyノード1台」だけでなく、「代替追加されたInServiceノード1台」も合わせてデタッチしようとしてしまう仕様らしい。これは分かりにくい…。
ということで、当該オプションにチェックを入れてリトライ。
すると「InService」ノード2台は変更されることなく、「Standby」ノード1台のみが「Detaching」へ移行してくれた。ほどなくしてASGから削除される。
まとめ
このケースは商用稼働中のASGに対するトラブル時のワークアラウンドとしてそこそこ実施される作業ではないかと思う。
とりわけエンタープライズな環境だと、想定手順通りに作業が進まないと「イレギュラー発生」扱いとなりトラブル対応がさらに紛糾することも予想されるため、このややこしい仕様は把握しておいた方がよさそう。
というか、いちいちスタンバイへ移行することなくいきなりデタッチしてしまう方がいいかも。
さらに言うと、調査目的などでインスタンスの保全が必要な場合を除いては「不良インスタンスを停止」したり「インスタンス更新でローリング置換を実施」する方がシンプルで安全だと思われる。
※ なおASGの基本的な挙動については以下の記事もどうぞ。
【EC2温故知新】AutoScalingグループの挙動をマネコンで観察してみる