EC2 Auto ScalingでIP,IDを変えずにOS更新「ルートボリューム置換」を試してみた

EC2オートスケールの新機能「ReplaceRootVolume」を使えば、インスタンスIDとIPを維持したままOS領域のみ入替が可能になりました。実機検証で確認したダウンタイムと設定の要点を解説します。
2025.11.28
2025年11月20日、Amazon EC2 Auto Scaling において、インスタンスリフレッシュ時にインスタンスを終了（Terminate）させず、ルートボリュームのみを置換する機能（ReplaceRootVolume）がサポートされました。
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/amazon-ec2-auto-scaling-root-volume-replacement/
Auto Scaling管理外の EC2インスタンス単体については、2021年の時点で「ルートボリュームの置換」はサポートされていました。
https://dev.classmethod.jp/articles/ec2-enables-replacing-root-volumes/
今回のアップデートは、この機能が Auto Scaling グループの「インスタンスリフレッシュ」機能と統合された 点にあります。これにより、手動対応ではなく、Auto Scalingのライフサイクル管理の中で「インスタンスIDを変えずにOSを一斉更新する」運用が可能になりました。
実際にAWS CLIを用いてこの機能を検証し、挙動の詳細とダウンタイム時間をログベースで確認した内容を紹介します。
 検証の概要と判定基準本機能の最大のメリットは、インスタンスの側（インスタンスID/IP）は維持したままで、中身（OS/ディスク）だけを入れ替えられる点です。
 検証環境リージョン: オレゴン (us-west-2)
OS: Amazon Linux 2023 (ARM64)
インスタンスタイプ: t4g.nano
構成: Auto Scaling グループ (Min=1, Max=1)
 検証用 User Data今回の検証では、OSが初期化されたことを判別するために、以下のUser Dataスクリプトを設定しました。インスタンス起動時（およびルートボリューム置換後の初回起動時）に、Nginxのデフォルトページに「その時点の時刻」を書き込みます。
#!/bin/bash
# Nginxのインストールと起動
dnf install -y nginx
systemctl start nginx
systemctl enable nginx

# メタデータ取得とindex.html生成
INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
# 現在時刻を取得（ここが更新されるかどうかが検証のポイント）
CREATED_AT=$(date -u +"%Y-%m-%d %H:%M:%S UTC")

# HTMLファイルへの書き込み
cat <<EOF > /usr/share/nginx/html/index.html
Instance ID: ${INSTANCE_ID}
Page Created: ${CREATED_AT}
EOF
 判定ロジックID/IPの維持: 更新前後でインスタンスIDとパブリックIPが変わっていないこと。
ボリュームの置換: Nginxが返すHTML内の「Page Created」時刻が、更新処理実行時の時刻に変化していること。
 1. 初期状態の確認CloudFormationにて環境を構築後、マネジメントコンソールおよびCLIで状態を確認しました。

インスタンスリフレッシュで交換対象のインスタンス（root-volume-test-asg-instance）が正常に起動しています。
(上段がASG管理下の検証対象インスタンス。ID: i-0daa377a... / 起動時刻: 17:11 JST)
稼働中のインスタンスのパブリックIPアドレスに対してリクエストを送信し、Webサーバの応答を確認しました。
curl http://34.221.xxx.xxx
実行結果:
Instance ID: i-0daa377a********
Page Created: 2025-11-28 08:12:32 UTC
この時点でのインスタンスIDは i-0daa377a********、IPは 34.221.xxx.xxx です。

※コンソールの起動時刻（JST 17:11）と、Webページ生成時刻（UTC 08:12）の整合性も取れています。
 2. インスタンスリフレッシュの実行 (CLI)OSの中身を更新した新しいAMI（v2）を作成し、起動テンプレートのバージョンを更新しました。

続いて、新機能である ReplaceRootVolume 戦略を指定してインスタンスリフレッシュを実行しました。
ここで重要な点として、本機能を利用するためには MixedInstancesPolicy（混合インスタンスポリシー） の構成が必須となります。単体の起動テンプレート指定では動作しないため、desired-configuration 内でポリシーを明示しています。
aws autoscaling start-instance-refresh \
  --auto-scaling-group-name root-volume-test-asg \
  --strategy ReplaceRootVolume \
  --desired-configuration '{
    "MixedInstancesPolicy": {
      "LaunchTemplate": {
        "LaunchTemplateSpecification": {
          "LaunchTemplateId": "lt-07681aad********",
          "Version": "2"
        },
        "Overrides": [
          {
            "InstanceType": "t4g.nano",
            "ImageId": "ami-0d937885********" 
          }
        ]
      }
    }
  }' \
  --preferences '{"MinHealthyPercentage":0, "InstanceWarmup":300}' \
  --region us-west-2
コマンド実行後、ステータスが InProgress となり、更新処理が開始されました。
 3. ダウンタイムの計測結果リフレッシュ実行中、対象IPアドレスに対して10秒間隔でHTTPリクエストを送るスクリプトを実行し、サービス断時間を計測しました。
監視ログ（抜粋）:
Timestamp,Status,HTTPCode
2025-11-28 08:13:28,SUCCESS,200
2025-11-28 08:13:38,FAILED,0     <-- 通信断開始
2025-11-28 08:13:48,FAILED,0
2025-11-28 08:14:03,FAILED,0
2025-11-28 08:14:18,FAILED,0
2025-11-28 08:14:33,FAILED,0
2025-11-28 08:14:43,SUCCESS,200  <-- 復旧
結果:

通信断が発生していた期間は約50秒〜60秒でした。
これは t4g.nano インスタンスのOS再起動（Reboot）に要する時間とほぼ同等です。純粋なOS起動時間のみで見ると従来のインスタンス作り直し（Terminate & Launch）と大きな差はありませんが、再起動レベルの時間で確実に復旧することが確認できました。
 4. 検証結果：IDと中身の確認更新完了後、再度インスタンスにアクセスし、IDとページ生成時刻を確認しました。
curl http://34.221.xxx.xxx
実行結果:
Instance ID: i-0daa377a******** <-- 変更なし！
Page Created: 2025-11-28 08:14:35 UTC  <-- 更新された！
 結果の分析インスタンスID/IPの維持: i-0daa377a******** およびIPアドレスは初期状態から変化していません。
ルートボリュームの置換: Page Created の時刻が、リフレッシュ処理中の時刻（08:14:35）に更新されています。これは、OSが新しいルートボリュームから起動し、User Dataスクリプトが再実行されたことを証明しています。
以上のログより、「インスタンスIDを維持したまま、ルートボリュームのみが正常に置換された」と判断しました。
 5. どのようなケースで高速化するのか？今回の検証のような軽量なWebサーバであれば、インスタンスを新規作成しても1〜2分で完了するため、時間的なメリットは感じにくいかもしれません。しかし、以下のような「

IPアドレスやMACアドレスの変更がボトルネックになる」環境においては、この機能が更新時間を劇的に短縮できる可能性があります。
ライセンスサーバへの登録:

MACアドレスやIPアドレスに紐づく商用ソフトウェアを利用しており、インスタンスが変わるたびにライセンスの再発行や登録解除・再登録の手続きが発生する場合。
IPアドレスベースのアクセス制限:

対向システムのファイアウォール設定変更が必要で、IPが変わるたびに申請フローが発生する場合。
大規模な初期プロビジョニング:

インスタンス起動後に数ギガバイト単位のデータをダウンロードする必要があるが、ローカルディスク（EBSデータボリューム）を維持できるため、差分更新だけで済む場合。
 考慮事項と制約検証を通じて確認した注意点は以下の通りです。
MixedInstancesPolicy構成のASGであること:

公式ドキュメントの [Instance Refresh Requirements] セクションにも記載がある通り、ReplaceRootVolume 戦略を使用する場合は Auto Scaling グループ自体が MixedInstancesPolicy で構成されている必要があります。

単一の起動テンプレートを使用する一般的な構成（Standard）のままでは利用できないため、既存環境に適用する場合はASGの設定変更が必要となることがあります。
メモリ・ディスクデータは消失: OS再起動を伴うためメモリ内容はクリアされます。また、ルートボリュームは丸ごと交換されるため、ボリューム内のログやデータは消失します。必要なデータはEBSデータボリュームやS3へ退避させる設計が必要です。
User Dataの再実行: ルートボリュームが置き換わるため、cloud-initによる初期化処理（User Data）は再度実行される可能性があります。べき等性を考慮したスクリプトにする必要があります。
インスタンスストアは非対応: EBSルートボリュームである必要があります。
 まとめEC2 Auto Scalingの ReplaceRootVolume 戦略を検証しました。
インスタンスID・IPアドレス・MACアドレスが変わらない
ダウンタイムはOS再起動レベル（今回の検証では約50秒）
これまで「IPが変わると困る」「MACアドレスが変わるとライセンス認証が外れる」といった理由で、Auto Scalingの活用（Immutable Infrastructure化）を諦めていたシステムにとって、有力な選択肢の一つになるはずです。
ぜひ一度、検証環境でお試しください。
EC2 Auto ScalingでIP,IDを変えずにOS更新「ルートボリューム置換」を試してみた

検証の概要と判定基準

検証環境

検証用 User Data

判定ロジック

1. 初期状態の確認

2. インスタンスリフレッシュの実行 (CLI)

3. ダウンタイムの計測結果

4. 検証結果：IDと中身の確認

結果の分析

5. どのようなケースで高速化するのか？

考慮事項と制約

まとめ

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS
