AMI を入れ替える更新や、ヘルスチェックの失敗による置き換えのとき、Auto Scaling は古いインスタンスを止めてから代わりを立てる。その間は容量が一時的に下がり、負荷が高いと応答が遅れる。2026年10月26日の発表で、この順序を逆にした動作を、アカウント全体の既定にできるようになった。
この記事の結論
- Launch Before Terminate は、代わりのインスタンスを先に起動し、ヘルスチェックを通してから古い方を止める動作。
- 今回、アカウント内のすべての Auto Scaling グループの既定として有効にできるようになった。
- 対象は instance refresh、リバランス、ヘルスチェックによる置き換え、最大寿命による置き換え。
- 設定は
PutAccountSettingとDescribeAccountSettingsで扱える。全リージョンで使え、追加料金はない。 - 代わりに、置き換えの間は台数が一時的に増える。上限と課金は先に見積もる。
何が起きたか
EC2 Auto Scaling で、Launch Before Terminate をアカウントの既定の置き換え動作として有効にできるようになった。有効にすると、置き換えが必要になったとき、Auto Scaling はまず代わりのインスタンスを起動し、ヘルスチェックを通ったのを待ってから、置き換え対象を止める。適用されるのは、instance refresh、リバランス、ヘルスチェックの失敗、最大インスタンス寿命の置き換えの4つ。設定は Auto Scaling のアカウント設定で行い、コンソール、CLI、SDK から PutAccountSetting と DescribeAccountSettings が使える。全リージョンで使え、追加料金はない。
（公式の発表）
仕組みとして何が変わったか
これまでは、置き換えの順序は「止めてから立てる」で、代わりが健全になるまで容量が下がっていた。今回は、順序を逆にし、しかもそれをグループごとではなく、アカウントの既定として一度で決められる。責任の面では、グループごとに設定を覚えておく運用から、アカウントの基準を決める運用に動いた。
BEFORE / AFTEREC2 Auto Scaling
置き換えの間も、容量を落とさない順序にする
これまで
止めてから起動する
- 古いインスタンスを先に止める置き換えの途中は容量が下がる
- 代わりが健全になるまで待つグループごとに設定を覚えておく
これから
Launch Before Terminate
- 代わりを先に起動するヘルスチェックを通してから次へ
- そのあとで古い方を止めるアカウント単位で既定にできる
CHECK 1ここまでの確認
アカウント単位で Launch Before Terminate を有効にすると、何がグループごとの設定から変わるか?
答えと解説
答え: 1. アカウント内のすべての Auto Scaling グループの既定の置き換え動作になる
「何が起きたか」を読み直す。アカウント設定で一度決める形になり、全リージョンで使える。
どんなものに活用できそうか
- AMI の更新を日中に行う。 instance refresh のあいだも処理能力を保ちたい Web 層で、夜間の作業に寄せずに済む可能性が出る。
- 最大寿命でインスタンスを入れ替える運用。 定期的に入れ替えて古い状態を残さない運用で、入れ替えの瞬間の容量低下を抑えられる。
- ヘルスチェックの失敗が重なる障害時。 不健全なインスタンスを先に止めずに、代わりを確かめてから外せる。
使わない方がよい場面もある。置き換えの間は台数が一時的に増える。起動できる台数の上限に近いグループや、インスタンス数でライセンスが決まるソフトを載せた構成では、先に影響を確かめてから有効にする。グループごとの個別設定とアカウントの既定の優先関係は発表に書かれていないので、ユーザーガイドで確かめる。
CHECK 2ここまでの確認
この動作を有効にする前に、特に見積もっておきたいのはどれか?
答えと解説
答え: 1. 置き換え中に一時的に増えるインスタンスの台数と、上限・課金への影響
先に代わりを起動するので、置き換えの間は台数が一時的に増える。使いどころの節で触れた通り、上限に近いグループでは先に確かめる。
立場ごとに何が変わるか
- 未経験: いまは関係ない。まず「サーバーを増やしたり入れ替えたりする仕組み」が Auto Scaling だと押さえれば足りる。
- 学習中: 可用性の題材として読める。SAA の「回復性の高いアーキテクチャ」の考え方（止める前に代わりを確かめる）と同じ向きだが、出題への反映は試験の版ごとに決まるので試験ガイドで確かめる。
- 実務: 有効にする前に、置き換え中の最大台数がクォータに収まるか、課金がどれだけ増えるかを見積もる。まず一部のアカウントで試す。
- プロ: アカウントの既定にすると、チームごとの設定の食い違いを減らせる。一方で、例外を許すグループをどう扱うか、組織の基準としてどこまで強制するかが設計の論点になる。
まとめ
置き換えの順序を「止めてから立てる」から「立てて確かめてから止める」に変え、それをアカウントの既定にできるようになった。容量の落ち込みを抑える代わりに、一時的に台数が増える。有効にする前に、上限と課金への影響を見積もり、公式のドキュメントで優先関係を確かめてほしい。
参照ソース
- AWS EC2 Auto Scaling now supports Launch Before Terminate at account-level to replace instances（2026年10月時点）
- Amazon EC2 Auto Scaling ユーザーガイド（2026年10月時点。アカウント設定の詳細はここで確認）
