📌 結論：インスタンスリフレッシュとは？
インスタンスリフレッシュ = Auto Scaling グループ内のEC2を「安全に」「段階的に」新しいものに入れ替える機能
🚌 バス会社が古いバスを新型バスに計画的に置き換えるように、
サービスを止めずにEC2インスタンスを最新の設定に更新できます！
段階的に置き換え
サービス継続可能
ヘルスチェック連携
自動ロールバック
一時停止・再開
カスタム設定
🚌 バス会社の車両更新で完全理解！
Auto Scalingグループ = バス会社の車両フリート（車両群）
全国の路線で毎日運行するバス会社を想像してください。
古いバスを新型バスに入れ替えたい...でも運行を止めずに置き換えたい！
これがまさに「インスタンスリフレッシュ」の役割です 🎯
🔄
➡️
📋 AWS用語とバス会社の対応表
Auto Scaling グループ → バス会社
複数のバス（インスタンス）を管理する組織全体
EC2インスタンス → 各バス
実際に運行する個々の車両
起動テンプレート → 車両設計図
新しいバスをどう作るかの仕様書
AMI（マシンイメージ） → バスの型式
旧型から新型への変更ポイント
MinHealthyPercentage → 最低運行台数
「最低○台は常に運行」というルール
InstanceWarmup → 試運転期間
新車が本格稼働前に様子を見る時間
チェックポイント → 中間点検
「○台置き換えたら一旦確認」
ロールバック → 旧車両に戻す
問題発生時に旧型バスで運行再開
📊 インスタンスリフレッシュの流れ
⚙️ 重要パラメータ徹底解説
この割合のインスタンスは常にHealthyな状態を維持します。
値が高いほど安全だが、更新に時間がかかります。
同時に停止できるのは1台だけ。
お客様への影響を最小限に抑える設定
この時間が経過するまでヘルスチェックをスキップ。
アプリケーションの起動時間を考慮して設定。
エンジン確認、計器チェック、テスト走行...
いきなり乗客を乗せずに慣らし運転
true：既に最新のものは置き換えない（時間短縮）
false：全インスタンスを強制的に置き換え
古い型式のバスだけを入れ替える
無駄な作業を省いて効率化
指定割合に達すると自動的に一時停止。
問題がないか確認してから続行できます。
2割・5割・全部で一旦ストップ
各段階で問題がないか点検してから次へ
🔄 ローリング更新の様子を図解！
MinHealthyPercentage = 75%（4台中3台は常に稼働）の場合
まず1台を終了して、新しいインスタンスを起動準備
新型バスが試運転中（InstanceWarmup期間）
1台目完了！次の旧型バスを入れ替え開始
全車両が新型バスに！サービス中断なしで更新完了
🚧 チェックポイント機能で安全確保
更新の途中で一旦停止して確認できる！問題があればロールバック
2台更新が終わった段階
問題がないか確認
を決定
「次のチェックポイントへ！」
「旧バージョンに戻す！」
🚌 バス会社のたとえ：
「まず2台だけ新型に入れ替えて、乗客からクレームがないか確認」
「問題なければ残りも入れ替え、問題あれば旧型に戻す」
📊 更新方法の比較
| 比較項目 | 🔄 インスタンスリフレッシュ | ✋ 手動置き換え | 📈 容量変更 |
|---|---|---|---|
| サービス継続 | ✅ 自動で維持 | ⚠️ 手動管理 | ✅ 可能 |
| 作業の手間 | ✅ 最小 | ❌ 大きい | ⚠️ 中程度 |
| ロールバック | ✅ 自動対応 | ❌ 手動 | ❌ 困難 |
| 進捗管理 | ✅ 自動追跡 | ❌ 手動 | ⚠️ 限定的 |
| チェックポイント | ✅ 設定可能 | ❌ なし | ❌ なし |
| 推奨ケース | AMI更新・設定変更 | 特定インスタンス のみ対象 |
一時的な キャパシティ調整 |
💼 こんな時に使おう！
💻 実践！AWS CLIコマンド
本番環境では90%以上を推奨。サービスへの影響を最小限に。
2. InstanceWarmupは余裕を持って：
アプリケーションの起動時間 + ヘルスチェック間隔 + バッファ時間を考慮。
3. チェックポイントを活用：
大規模環境では20%、50%、80%など段階的に確認。問題の早期発見に有効。
4. 事前にテスト環境で検証：
本番適用前に、同じ設定でテスト環境でリフレッシュを実行して確認。
5. CloudWatchアラームと連携：
エラー率やレイテンシーの急増を検知してロールバックを判断。
6. メンテナンスウィンドウで実行：
トラフィックが少ない時間帯に実行すると影響を最小化できる。
❓ よくある質問
リフレッシュ中もAuto Scalingのスケーリングポリシーは有効です。負荷に応じてインスタンス数は増減しますが、新しく起動するインスタンスは最新の起動テンプレート（新しいAMI）で作成されます。
新しいインスタンスがヘルスチェックに失敗した場合、リフレッシュは一時停止します。CheckpointPercentagesを設定していれば、各段階で確認して手動でキャンセル（ロールバック）することも可能です。
CheckpointPercentagesを設定すると、指定した割合で自動的に一時停止します。状態を確認後、ContinueInstanceRefresh APIまたはコンソールから再開できます。手動で一時停止したい場合はチェックポイントを利用してください。
ELBターゲットグループに登録されているAuto Scalingグループの場合、古いインスタンスは適切にドレイン（接続排出）されてから終了し、新しいインスタンスはヘルスチェック合格後にトラフィックを受け付けます。
ただし、リフレッシュ中は一時的に新旧両方のインスタンスが存在するため、その期間のEC2費用は発生します。MinHealthyPercentageが高いほど同時稼働インスタンスが多くなる点に注意。
🎓 まとめ
🚌 バス会社の車両更新 = インスタンスリフレッシュ
お客様（トラフィック）を乗せたまま、
古いバス（旧AMI）から新型バス（新AMI）へ
安全に・段階的に入れ替える機能です！
90%推奨
余裕を持って
安全性UP
即座に戻す