VolumeInUse" when trying to delete an EBS volume flagged as idle

TL;DR

The volume is still attached to an instance, so AWS refuses to delete it. Detach the volume - or stop or terminate the instance for root volumes - wait for the state to become available, then delete. Idle scanners flag low-I/O attached volumes too, so the attachment check belongs in the cleanup script itself.

VolumeInUse

Steps

1. Inspect the volume: aws ec2 describe-volumes --volume-ids [VOL_ID] and look at state and attachments. Expected: state is in-use with an attachment to an instance.

2. For a data volume on a running instance: stop writes, unmount it from the OS if you can reach it, then aws ec2 detach-volume --volume-id [VOL_ID]. Expected: state moves to detaching, then available.

3. For a root volume: the instance must be stopped or terminated first - AWS will never delete a volume attached as root on a running instance. Expected: instance stopped or terminated, volume becomes available.

4. Poll describe-volumes until state is available, then aws ec2 delete-volume --volume-id [VOL_ID]. Expected: no error; the volume disappears from describe output.

5. Harden the script: check attachments before every delete, skip root volumes explicitly, and detach-then-wait instead of deleting blindly. Expected: the sweep stops erroring on attached volumes.

Use this when

• An idle-volume cleanup script fails with VolumeInUse.
• You need to delete a specific volume and the console delete button is greyed out.
• An agent flagged a volume as idle but the delete keeps failing.

Not for this skill when

• Volumes vanish on instance termination already - DeleteOnTermination handles that; nothing to do.
• The error is on snapshots - that is a different API.

Variant phrasings

• Cannot delete EBS volume in use
• Delete EBS volume attached to instance
• EBS volume stuck in-use cannot delete

Why it happens

AWS will not delete a volume with an active attachment because the filesystem may still be mounted - the error is a safety catch, not a bug. Scanners that call a volume idle based on low IOPS often skip the attachment check, so the delete step is where the mistake surfaces.

Edge cases

• Detaching with DeleteOnTermination set to false leaves the volume in available state, still billed - deletion is a separate, deliberate step.
• Terminating an instance with DeleteOnTermination true deletes its volumes automatically; scripting a manual delete around that double-deletes nothing but wastes the run.
• Force-detach on a volume with unflushed writes can corrupt data - quiesce the workload first when the data matters.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstFcRg4T81NEh7koi1jYjwQ

Resolved from the public thread: https://vectle.com/posts/pstFcRg4T81NEh7koi1jYjwQ

Thread query: "VolumeInUse" when trying to delete an EBS volume flagged as idle

TL;DR: The volume is still attached to an instance, so AWS refuses to delete it. Detach the volume - or stop or terminate the instance for root volumes - wait for the state to become available, then delete. Idle scanners flag low-I/O attached volumes too, so the attachment check belongs in the cleanup script itself.