I tried replacing the root volume using the new "Direct EBS Volume Specification" feature of EC2 Replace Root Volume
This page has been translated by machine translation. View original
Introduction
On July 9, 2026, an option to directly specify an EBS volume was added to EC2's Replace Root Volume feature.
The conventional Replace Root Volume allowed you to either restore to the state at launch time, or replace by specifying a snapshot ID or AMI ID. With this update, you can now replace the root volume by directly specifying an existing EBS volume using the --volume-id parameter. This is available in all commercial regions and GovCloud.
In this article, we will actually replace the root volume using the --volume-id parameter and verify that the volume contents are switched.
For information about the basic Replace Root Volume feature that appeared in 2021, see here.
Support for Auto Scaling was also added in 2025.
Verification Details
Verification Environment
| Item | Value |
|---|---|
| Region | ap-northeast-1 (AZ: ap-northeast-1a) |
| Instance Type | t3.micro |
| AMI | Amazon Linux 2023 (ami-0af8344e5a6a14ac7) |
| Volume Type | gp3, 8 GiB |
| Connection Method | SSM Run Command (AWS-RunShellScript) |
Overview of Verification Steps
- Launch an EC2 instance and create a marker file on the root volume
- Take a snapshot and create an EBS volume from it
- Append to the marker file on the instance (to create a difference from the snapshot point)
- Execute Replace Root Volume with
--volume-id - Check the marker file after replacement to demonstrate that the contents revert to the state at the time of the snapshot
Creating the Marker File
aws ssm send-command \
--instance-ids i-04******** \
--document-name AWS-RunShellScript \
--parameters 'commands=["echo \"MARKER_LINE_1: created at 2026-07-10T19:45:28Z\" > /root/marker.txt","sync"]'
The first line (MARKER_LINE_1) is written to /root/marker.txt, and sync is used to reliably flush it to disk.
Taking a Snapshot and Creating an EBS Volume
We take a snapshot at the point when only MARKER_LINE_1 exists.
aws ec2 create-snapshot \
--volume-id vol-04******** \
--description "Replace Root Volume test - marker line 1 only"
Snapshot snap-0b********** was created and confirmed as completed. An EBS volume is created in the same AZ from this snapshot.
aws ec2 create-volume \
--snapshot-id snap-0b********** \
--availability-zone ap-northeast-1a \
--volume-type gp3
vol-04********** (in available state) was created.
Appending to the Marker File
Next, we append a second line to the root volume of the current instance. This creates a difference between the EBS volume at the time of the snapshot (only 1 line) and the current root volume (2 lines).
aws ssm send-command \
--instance-ids i-04******** \
--document-name AWS-RunShellScript \
--parameters 'commands=["echo \"MARKER_LINE_2: added after snapshot at 2026-07-10T19:46:53Z\" >> /root/marker.txt","sync"]'
The contents of the root volume at this point:
MARKER_LINE_1: created at 2026-07-10T19:45:28Z
MARKER_LINE_2: added after snapshot at 2026-07-10T19:46:53Z
Executing Replace Root Volume
We execute Replace Root Volume by directly specifying an EBS volume with the --volume-id parameter.
aws ec2 create-replace-root-volume-task \
--instance-id i-04******** \
--volume-id vol-04********** \
--delete-replaced-root-volume
The task was created and transitioned from pending → succeeded in 26 seconds. The EC2 instance state remained running throughout, but an automatic reboot of the instance occurs during processing.
aws ec2 describe-replace-root-volume-tasks \
--replace-root-volume-task-ids replacevol-09**********
{
"ReplaceRootVolumeTasks": [
{
"ReplaceRootVolumeTaskId": "replacevol-09**********",
"InstanceId": "i-04********",
"TaskState": "succeeded",
"StartTime": "2026-07-10T19:47:15+00:00",
"CompleteTime": "2026-07-10T19:47:41+00:00",
"DeleteReplacedRootVolume": true
}
]
}
Since --delete-replaced-root-volume is specified, the old root volume is automatically deleted after the replacement is complete.
Verification After Replacement
aws ssm send-command \
--instance-ids i-04******** \
--document-name AWS-RunShellScript \
--parameters 'commands=["cat /root/marker.txt"]'
MARKER_LINE_1: created at 2026-07-10T19:45:28Z
We were able to confirm that MARKER_LINE_2 was gone and the contents had switched to only the first line contained in the specified EBS volume. Since this EBS volume was created from a snapshot in this case, the result is the contents at the time the snapshot was taken.
Constraints
The main conditions for directly specifying an EBS volume with Replace Root Volume are as follows.
- The replacement EBS volume must exist in the same AZ as the instance
- The volume state must be available (unattached)
- An encrypted root volume cannot be replaced with an unencrypted volume (unencrypted → encrypted is possible)
- Specifying
--delete-replaced-root-volumeautomatically deletes the old root volume (if not specified, it remains in available state)
Use Cases
Here we introduce scenarios where this update is expected to be useful. Note that performance measurements were not conducted in this article.
Reducing Intermediate Steps of Snapshot Creation and Completion Waiting
If you prepare an EBS volume in advance, you can skip the process of specifying a snapshot and creating a new volume at the time of executing the replacement task.
Combination with EBS Volume Clones
If you clone a healthy root volume using EBS Volume Clones added in October 2025, it can potentially be used as a rollback method in the event of a failure.
Directly Applying a Pre-prepared EBS from Another Instance as the Production Root
An EBS volume that has been attached to a test instance and had package updates or configuration changes applied can be detached and then directly applied as the root volume of a production instance.
Utilizing Pre-initialized EBS Volumes
EBS volumes created from snapshots have a first-touch penalty on the first read, but by pre-reading all blocks with dd or fio to initialize them, this penalty can be suppressed. Since directly specifying an EBS volume does not create a new volume at the time Replace Root Volume is executed, a pre-initialized volume can be brought in as-is. Enabling FSR was previously the representative option, but it may serve as an alternative in cases where preparation time is available.
Summary
The --volume-id parameter has been added to EC2 Replace Root Volume, making it possible to apply an existing EBS volume directly as the root volume without specifying a snapshot or AMI when executing Replace Root Volume.
In this verification, we specified an EBS volume created from a snapshot and confirmed that the contents of the root volume switched to the contents of the specified volume.
It seems useful in workflows where a pre-prepared and verified EBS volume is applied, as well as in cases where you want to use a pre-initialized volume.
