EBS Elastic Volumes has evolved, eliminating the 6-hour waiting period and now allowing up to 4 changes within 24 hours
This page has been translated by machine translation. View original
On January 15, 2026, the "Elastic Volumes" feature of Amazon Elastic Block Store (EBS) was enhanced. The previously required 6-hour waiting period (cooldown time) after volume changes has been eliminated, allowing up to 4 changes within a 24-hour rolling window as long as the previous change has completed.
I had the opportunity to verify this update's behavior using AWS CLI, so I'd like to share my findings.
Verification
I used the following environment for verification:
- Region: Tokyo Region (ap-northeast-1)
- AWS CLI version: 2.32.22
$ aws --version
aws-cli/2.32.22 Python/3.9.25 Linux/6.1.159-181.297.amzn2023.aarch64 source/aarch64.amzn.2023
1: Sequential Capacity Changes
First, I verified if volume size could be changed consecutively in a short period.
- Creating a 1GB gp3 volume
aws ec2 create-volume \
--size 1 \
--volume-type gp3 \
--availability-zone ap-northeast-1a \
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=test-capacity-change}]'
1st change: 1GB → 2GB
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxfe08 --size 2
Checking modification status:
aws ec2 describe-volumes-modifications --volume-ids vol-xxxxxxxxxxfe08
Result:
{
"ModificationState": "completed",
"TargetSize": 2,
"OriginalSize": 1,
"StartTime": "2026-01-16T03:32:04+00:00",
"EndTime": "2026-01-16T03:32:06+00:00"
}
The increase from 1G to 2G completed in 2 seconds. After completion, I could immediately execute the next change.
2nd change: 2GB → 3GB
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxfe08 --size 3
3rd change: 3GB → 4GB
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxfe08 --size 4
All changes completed within seconds and could be executed consecutively without waiting.
2: Volume Type Changes
Next, I tried changing volume types.
- Creating a gp3 volume
aws ec2 create-volume \
--size 1 \
--volume-type gp3 \
--availability-zone ap-northeast-1a \
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=test-type-change}]'
- Type changes (repetitive)
1st change: gp3 → gp2
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxb285 --volume-type gp2
2nd change: gp2 → gp3
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxb285 --volume-type gp3
3rd change: gp3 → gp2
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxb285 --volume-type gp2
4th change: gp2 → gp3
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxb285 --volume-type gp3
All four changes were successful.
- Attempt at 5th change
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxb285 --volume-type gp2
For the 5th change exceeding the limit, I received the following error:
An error occurred (VolumeModificationRateExceeded) when calling the ModifyVolume operation:
You've reached the maximum modification rate per volume limit.
Wait until 2026-01-17T03:33:19.145Z before you can issue the next modification request for this volume.
The error message clearly indicated the next time when modification would be possible.
3: Combined Changes
I tested changes combining capacity, type, and performance.
- Creating a 1GB gp2 volume
aws ec2 create-volume \
--size 1 \
--volume-type gp2 \
--availability-zone ap-northeast-1a \
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=test-combined-change}]'
1st change: Expanding capacity to 10GB
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxbb75 --size 10
2nd change: Changing from gp2 to gp3
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxbb75 --volume-type gp3
3rd change: Increasing IOPS from 3000 to 3500
aws ec2 modify-volume --volume-id vol-xxxxxxxxxxbb75 --iops 3500
Changes combining capacity, type, and performance could be executed consecutively without cooldown time.
While I executed these changes separately for verification purposes, for actual operations, I recommend combining changes to save modification slots:
aws ec2 modify-volume \
--volume-id vol-xxxxx \
--size 10 \
--volume-type gp3 \
--iops 3500
4: Necessity to Wait for Completion (completed)
During this verification, changes to small volumes completed in seconds, but for large volumes, completion time can take hours. I verified whether subsequent changes could be made to a volume that was still in the process of changing.
- Creating a volume from a snapshot
I created a 30GB volume from a Windows Server AMI snapshot:
aws ec2 create-volume \
--snapshot-id snap-05829ab1b1e33ec69 \
--availability-zone ap-northeast-1a \
--volume-type gp3 \
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=test-windows-volume}]'
- Executing capacity change
aws ec2 modify-volume --volume-id vol-xxxxxxxxxx38a1 --size 31
- Attempting another change during modification
While the modification state was "optimizing", I attempted another capacity change:
aws ec2 modify-volume --volume-id vol-xxxxxxxxxx38a1 --size 32
The following error occurred:
An error occurred (IncorrectModificationState) when calling the ModifyVolume operation:
Volume vol-xxxxxxxxxx38a1 cannot be modified in modification state OPTIMIZING
I confirmed that even with the relaxed frequency limit, the next change cannot be executed until the backend optimization process (optimizing) is completed.
Summary
With Amazon EBS Elastic Volumes now supporting up to 4 changes in 24 hours, operational flexibility has significantly improved for responding to sudden load increases or immediate recovery from configuration mistakes.
In this verification, changes completed in seconds, but for large volumes, completion time might take hours and performance impacts may occur during changes.
Before making changes to production environments, I strongly recommend preparing a verification environment that replicates the production setup using snapshots or AMIs, and conducting a rehearsal to confirm the required time and performance impacts.
Reference Links
