EC2 Auto Scaling の Instance Refresh 新機能「Replace Root Volume」を試してみた

2026.01.01
 はじめにテクニカルサポートの 片方 です。

少し前に EC2 Auto Scaling の Instance Refresh に Replace Root Volume (ルート EBS ボリューム置換) という新しい機能が追加されました。
※ 執筆時では英語ドキュメントのみに掲載

https://docs.aws.amazon.com/autoscaling/ec2/userguide/DocumentHistory.html
Replace root volumes

Root volume replacement updates your instances by replacing only the root EBS volume while keeping the instance running. For more information, see Replace root volumes during instance refresh.

November 20, 2025
EC2 Auto Scaling の Instance Refresh は、起動中の EC2 インスタンスを段階的に入れ替えることで、安全に構成変更を反映できる仕組みで、これまでの Instance Refresh では、既存 EC2 インスタンスを終了し、新しい EC2 インスタンスを起動する方式が前提でした。

今回ご紹介する本機能を使うと、EC2 インスタンスを起動したまま、ルート EBS ボリュームだけを差し替えることが可能です。

ルート EBS ボリューム置換では、以下のようなリソースが維持されます。
ネットワークインターフェースおよび IP アドレス
非ルート EBS ボリューム
Instance Store のデータ
セキュリティグループ、IAM ロール
一方で、OS やアプリケーションが格納されているルート EBS ボリュームのみが、新しい AMI から作成されたものに差し替えられます。

そのため、固定 IP を維持したまま OS 更新を行いたい場合 や、EC2 インスタンス起動時の InsufficientInstanceCapacity エラーを避けたいケースで有効な選択肢となります。
 前提条件https://docs.aws.amazon.com/autoscaling/ec2/userguide/replace-root-volume.html
以下は公式ドキュメントで定義されている必須条件です。
Auto Scaling グループは Mixed Instances Policy を使用していること
Instance Type が 1 種類のみでも Mixed Instances Policy は必須
Mixed Instances Policy の Overrides には必ず ImageId を指定すること
使用する AMI は 単一のルート EBS ボリュームのみを含むこと
EC2 Auto Scaling グループ内の EC2 インスタンスは、Launch Template の設定と完全に一致していること
Instance Refresh 実行時の Desired Configuration にも、ImageId を含む Mixed Instances Policy を指定すること
また、Launch Template のバージョン指定にも注意が必要です。
$Latest や $Default の Launch Template バージョンは使用不可
このため、固定のバージョン番号を明示的に指定する必要があります。
 簡単な留意事項検証や実運用で特に意識しておきたいポイントを整理します。
起動中の EC2 インスタンスが前提
対象 EC2 インスタンスが存在しない（DesiredCapacity = 0）場合、何も起こらない
Warm Pool を持つ Auto Scaling グループでは使用不可
また、Replace Root Volume 実行中に Warm Pool の追加は不可
ルート EBS ボリューム置換に失敗した場合、そのインスタンスは 終了され、新規 EC2 インスタンスで置き換えられる
完了後は EC2 Auto Scaling による ヘルスチェックが再実行される
 実装してみた既存の EC2 Auto Scaling グループを使って、Instance Refresh の Replace Root Volume を実際に試してみます。

本検証は AWS CLI コマンドを使用して行いました。
!ブログ執筆時点では、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、およびアジアパシフィック (シンガポール) でのみ利用可能です。
 EC2 Auto Scaling グループの構成を確認するまず、対象となる EC2 Auto Scaling グループの現在の設定を確認します。
※ details AWS CLI コマンド例
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names <AUTO_SCALING_GROUP_NAME>
確認ポイントは以下のとおりです。
Launch Template 使用および Ver 指定していること
Warm Pool が設定されていないこと
対象インスタンスが存在すること（DesiredCapacity > 0）
この時点では、Mixed Instances Policy が未設定でも問題ありません。
!起動テンプレート ID と 起動中の EC2 インスタンスに利用した AMI ID は後ほど必要になるのでメモしてください。
 Mixed Instances Policy に切り替えるLaunch Template 使用および Ver 指定や、Warm Pool が設定されていないことなどは躓くことが少ないと思いますので、ハマりポイントの Mixed Instances Policy に切り替える点について説明します。

今回は、現状の検証構成（m5.large + 現在の AMI）をそのまま Mixed Instances Policy に写し替えます。
今回の検証では CloudShell 環境で実施します。

まずは CloudShell を起動します。

mixed-policy.json ファイルを作成します。
vi mixed-policy.json
または
nano mixed-policy.json
以下の中身を貼り付けます（例）
{
  "LaunchTemplate": {
    "LaunchTemplateSpecification": {
      "LaunchTemplateId": "lt-0b11xxxxxxxxx",
      "Version": "1"
    },
    "Overrides": [
      {
        "InstanceType": "m5.large",
        "ImageId": "ami-XXXXXXXXXXXX"
      }
    ]
  }
}
保存して、終了します。

そのファイルを指定して以下の AWS CLI コマンドを実行します。
※ 適宜修正してください
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name <AUTO_SCALING_GROUP_NAME> \
  --mixed-instances-policy file://mixed-policy.json
 再度 EC2 Auto Scaling グループの構成を確認する要件を満たしているかといったことを確認します。
※ details AWS CLI コマンド例
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names <AUTO_SCALING_GROUP_NAME>
AWS CLI コマンド出力例
~ $ aws autoscaling describe-auto-scaling-groups 
{
    "AutoScalingGroups": [
        {
            "AutoScalingGroupName": "Test-Scaling",
            "AutoScalingGroupARN": "arn:aws:autoscaling:us-east-1:xxxxxxxxxxxx:autoScalingGroup:66xxxxxx-0c26-xxxx-90xx-xxxxxxxxxxxx:autoScalingGroupName/Test-Scaling",
            "MixedInstancesPolicy": {
                "LaunchTemplate": {
                    "LaunchTemplateSpecification": {
                        "LaunchTemplateId": "lt-0035c0fb0def93cc0",
                        "LaunchTemplateName": "AL2023",
                        "Version": "1"
                    },
                    "Overrides": [
                        {
                            "InstanceType": "m5.large",
                            "ImageId": "ami-068c0051b15cdb816"
                        }
                    ]
                },
                "InstancesDistribution": {
                    "OnDemandAllocationStrategy": "prioritized",
                    "OnDemandBaseCapacity": 0,
                    "OnDemandPercentageAboveBaseCapacity": 100,
                    "SpotAllocationStrategy": "lowest-price",
                    "SpotInstancePools": 2
                }
            },
            "MinSize": 0,
            "MaxSize": 2,
            "DesiredCapacity": 1,
            "DefaultCooldown": 300,
            "AvailabilityZones": [
                "us-east-1a"
            ],
            "LoadBalancerNames": [],
            "TargetGroupARNs": [],
            "HealthCheckType": "EC2",
            "HealthCheckGracePeriod": 300,
            "Instances": [
                {
                    "InstanceId": "i-09f3d9f2090a1aaf7",
                    "InstanceType": "m5.large",
                    "AvailabilityZone": "us-east-1a",
                    "LifecycleState": "InService",
                    "HealthStatus": "Healthy",
                    "LaunchTemplate": {
                        "LaunchTemplateId": "lt-0035c0fb0def93cc0",
                        "LaunchTemplateName": "AL2023",
                        "Version": "1"
                    },
                    "ProtectedFromScaleIn": false
                }
            ],
            "CreatedTime": "2025-12-29T01:36:14.211000+00:00",
            "SuspendedProcesses": [],
            "VPCZoneIdentifier": "subnet-08f65573b02b935d8",
            "EnabledMetrics": [],
            "Tags": [],
            "TerminationPolicies": [
                "Default"
            ],
            "NewInstancesProtectedFromScaleIn": false,
            "ServiceLinkedRoleARN": "arn:aws:iam::xxxxxxxxxxxx:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling",
            "TrafficSources": [],
            "AvailabilityZoneDistribution": {
                "CapacityDistributionStrategy": "balanced-best-effort"
            },
            "CapacityReservationSpecification": {
                "CapacityReservationPreference": "default"
            },
            "InstanceLifecyclePolicy": {
                "RetentionTriggers": {
                    "TerminateHookAbandon": "terminate"
                }
            }
        }
    ]
}
(END)
設定できていますね。
 Instance Refresh 実行用 config.json ファイルを設定するReplace Root Volume を使った Instance Refresh は、AWS CLI の start-instance-refresh コマンドに渡す JSON 形式の設定ファイルで制御します。
先ほどと同様に CloudShell 環境内で config.json ファイルを作成します。
vi mixed-policy.json
または
nano mixed-policy.json
以下の中身を貼り付けます（例）
{
  "AutoScalingGroupName": "xxxxxxxxxxxxx",
  "Strategy": "ReplaceRootVolume",
  "DesiredConfiguration": {
    "MixedInstancesPolicy": {
      "LaunchTemplate": {
        "LaunchTemplateSpecification": {
          "LaunchTemplateId": "lt-xxxxxxxxxxxxxxxxx",
          "Version": "1"
        },
        "Overrides": [
          {
            "InstanceType": "m5.large",
            "ImageId": "ami-xxxxxxxxxxxxxxxxx"
          }
        ]
      }
    }
  },
  "Preferences": {
    "InstanceWarmup": 60,
    "MinHealthyPercentage": 90,
    "AutoRollback": true,
    "ScaleInProtectedInstances": "Ignore",
    "StandbyInstances": "Ignore"
  }
}
保存して終了したら、ls -l コマンドでファイルが存在するか確認します。
~ $ nano config.json
~ $ ls -l
total 4
-rw-r--r--. 1 cloudshell-user cloudshell-user 642 Dec 29 02:51 config.json
~ $ 
上記のように config.json ファイルが存在すれば問題ないので、これで終了です！

お疲れさまでした！

では、この CloudShell 環境はそのままにして実行したいと思います。
 実行してみたhttps://docs.aws.amazon.com/cli/latest/reference/autoscaling/start-instance-refresh.html

それでは、AWS CLI の start-instance-refresh コマンドを利用して、ルート EBS ボリュームの置き換えを実行します。
AWS CLI コマンド ~ 実行例
$ aws autoscaling start-instance-refresh --cli-input-json file://config.json
{
    "InstanceRefreshId": "aa4e6a73-6b74-4947-a5f6-1cad00be7ca0"
}


正常に Instance Refresh が開始されました。成功です！

マネジメントコンソール画面では、[インスタンス更新] タブの [アクティブなインスタンス更新] より進行状況なども確認可能です。
また、CloudTrail のイベント履歴としては大まかに以下の流れのようでした。

※ イベント名はあくまでも参考です
StartInstanceRefresh (開始)
RunInstances
CreateReplaceRootVolumeTask
CreateGrant
SharedSnapshotVolumeCreated
RetireGrant
CreateGrant
CreateTags (終了)
 まとめ弊社ブログにおいても、詳細を纏めております。

https://dev.classmethod.jp/articles/ec2-autoscaling-replace-root-volume/
また、時間があれば キャンセル や ロールバック 方法についても調査したいと思います。

本ブログが誰かの参考になれば幸いです。
 参考資料Document history - Amazon EC2 Auto Scaling
Replace root volumes during instance refresh - Amazon EC2 Auto Scaling
MixedInstancesPolicy - Amazon EC2 Auto Scaling
start-instance-refresh — AWS CLI 2.32.24 Command Reference
EC2 Auto ScalingでIP,IDを変えずにOS更新「ルートボリューム置換」を試してみた | DevelopersIO
Cancel an instance refresh using the AWS Management Console or AWS CLI - Amazon EC2 Auto Scaling
Undo changes with a manual or auto rollback - Amazon EC2 Auto Scaling
 クラスメソッドオペレーションズ株式会社についてクラスメソッドグループのオペレーション企業です。

運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました