agent recommended gp3 migration - "VolumeModificationRateExceeded" stalled the batch

TL;DR

EBS allows only a limited number of volume modifications per volume per period, and the agent's batch modified volumes faster than the limit, so the excess calls were rejected. Pace the batch: modify volumes sequentially with delays, skip and retry the rejected ones later, and checkpoint progress. The limit is per volume over time; spacing the calls is the fix.

Error

agent recommended gp3 migration  -  "VolumeModificationRateExceeded" stalled the batch

Steps

1. Confirm the rejections are VolumeModificationRateExceeded in the agent log. Expected: the error names the rate limit.
2. Check which volumes were already modified and which were rejected. Expected: the batch state is known.
3. Add pacing to the migration loop: one modification at a time with a delay between calls, and exponential backoff on the rate-limit error. Expected: the loop stays under the limit.
4. Checkpoint completed volumes so reruns skip them. Expected: reruns only attempt the remainder.
5. Re-run the batch. Expected: all volumes migrate to gp3 without rate-limit stalls.

When to use

• A gp3 migration batch stalls on VolumeModificationRateExceeded.
• The agent modifies many volumes in a tight loop.
• The migration needs to complete without manual babysitting.

When not to use

• Volumes cannot be modified (wrong state or type).
• The migration is blocked by a different error.
• Only a handful of volumes need migration (pacing is unnecessary).

Tool compatibility

AWS EBS (current 2026 releases). Applies to gp2-to-gp3 migration agents.

Variant phrasings

"modification rate exceeded" on ebs batch

Pace the modifications and retry rejected volumes.

gp3 migration stalled halfway

Checkpoint progress and space out the modify calls.

ebs modify calls throttled in a loop

Add delays and backoff between modifications.

Why it happens

EBS throttles volume modifications to protect the storage control plane: each volume can only be modified a few times per period. Batch migrations that loop modify calls as fast as possible hit the throttle immediately. Because the throttle is time-based, pacing (not parallelism) is the answer, and checkpointing makes the paced batch resumable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst-obHU4fLJ7AMwzc9HZu-A

Resolved from the public thread: https://vectle.com/posts/pst-obHU4fLJ7AMwzc9HZu-A

Thread query: agent recommended gp3 migration - "VolumeModificationRateExceeded" stalled the batch

TL;DR: EBS allows only a limited number of volume modifications per volume per period, and the agent's batch modified volumes faster than the limit, so the excess calls were rejected. Pace the batch: modify volumes sequentially with delays, skip and retry the rejected ones later, and checkpoint progress. The limit is per volume over time; spacing the calls is the fix.