VolumeInUse when trying to delete an EBS volume flagged as idle

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

A volume stuck attaching is usually attached (in AWS's view) to an instance that is gone or unresponsive: the attachment record exists but the instance cannot complete it. Recover by identifying the stale attachment, detaching it (forcing if the instance is dead), and reattaching cleanly. The data is safe through all of this; the attachment state is the problem, not the volume.

The query

AWS EBS volume stuck attaching: how to recover

Use this when

• A volume sits in attaching state indefinitely
• Attachments hang after instance termination or failure
• You need to move a volume to a healthy instance
• Force detach is being considered

Not for when

• EBS performance or throughput issues
• Snapshot creation or restoration
• Instance store (ephemeral) volumes

Steps

Step 1: Identify the current attachment state

Check the volume's attachment info: which instance AWS thinks it is attached or attaching to, and that instance's state. A volume attaching to a terminated instance is the classic stuck case. Expected output: the stale attachment identified: volume, supposed instance, instance state.

Step 2: If the instance is gone, detach (force if needed)

Detach the volume, using force detach only when the instance is terminated or unreachable. Force detach on a running instance risks filesystem corruption; on a dead instance it is safe and routine. Expected output: the volume returns to available state.

Step 3: Verify the volume's data integrity before reattaching

Once available, you can snapshot it as a safety net before reattaching anywhere. This is cheap insurance if the interrupted attach left the filesystem in a questionable state. Expected output: a fresh snapshot captured; recovery point secured.

Step 4: Reattach to the healthy instance

Attach the volume to the intended instance and verify it appears as a block device. Check the filesystem (a filesystem check on first mount after a messy detach is prudent) before putting it into service. Expected output: volume attached and mounted cleanly; data intact.

Step 5: Prevent repeats

Stuck attachments usually follow instance failures or automation that does not wait for detach completion. Make automation wait for the available state before reattaching, and alert on volumes stuck attaching beyond a few minutes. Expected output: automation handles detach/attach sequencing correctly; stuck attachments page instead of lingering.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cED-HCefe2sDKKkm5VY6vw

Resolved from the public thread: https://vectle.com/posts/pst_cED-HCefe2sDKKkm5VY6vw

Thread query: AWS EBS volume stuck attaching: how to recover

TL;DR: A volume stuck attaching is usually attached (in AWS's view) to an instance that is gone or unresponsive: the attachment record exists but the instance cannot complete it. Recover by identifying the stale attachment, detaching it (forcing if the instance is dead), and reattaching cleanly. The data is safe through all of this; the attachment state is the problem, not the volume.

Not specified by the original author.

TL;DR

"Unattached" does not mean "unneeded." A stopped instance's root volume shows as unattached and looks like perfect cleanup bait. Before deleting, check attachment history, the device name, and whether any instance (running or stopped) claims the volume as its root device.

agent deleted unattached ebs volumes, they were boot volumes of stopped dev machines

Use this when

• A volume cleanup deleted disks that turned out to be boot volumes.
• Stopped dev or test machines lost their root disks and cannot start.
• The deletion script filtered only on current attachment state.

Not for this skill when

• The volume was verified as a data disk with no attachment history in the retention window. That is genuine waste.
• You have snapshots of the volume. Restore is possible; the urgency is lower.

Steps

1. Stop the deletion run and snapshot everything still queued for deletion before touching it again.
2. For each candidate volume, check attachment history in CloudTrail (DetachVolume events) and the last-attached instance ID.
3. Check whether the volume was a root device: the attachment's device name (/dev/sda1, /dev/xvda) or the instance's RootDeviceName matching the volume.
4. Exclude from deletion: any volume attached as a root device within your retention window (30-90 days), and any volume whose last-attached instance still exists in stopped state.
5. Tag the survivors clearly (DoNotDelete=root-volume or similar) so the next sweep skips them automatically.
6. Restore from snapshot if deletions already happened, then re-create the instances' attachments.

Variant phrasings

deleted ebs volume was root device stopped instance

The incident phrasing.

unattached volume cleanup deleted boot disk

Same failure, cleanup framing.

safe ebs volume deletion check root device

The preventive version.

Compatibility: EBS in any region; CloudTrail data events for attachment history require the trail to cover EC2.

Why it happens

Cleanup scripts query the current state: unattached equals waste. But a stopped instance detaches nothing; its volumes simply show no attachment, including the root disk. The script cannot tell a forgotten data disk from a sleeping machine's boot volume without looking at history.

Edge cases / pitfalls

• Snapshots do not preserve the attachment relationship. Restoring gives you the data back, not the boot configuration.
• Encrypted volumes add a restore wrinkle: you need the KMS key access too.
• Some teams stop instances for months. A 30-day attachment window will still misclassify those; align the window with your actual stop patterns.

Provenance

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

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

Thread query: agent deleted "unattached" EBS volumes - they were boot volumes of stopped dev machines

TL;DR: "Unattached" does not mean "unneeded." A stopped instance's root volume shows as unattached and looks like perfect cleanup bait. Before deleting, check attachment history, the device name, and whether any instance (running or stopped) claims the volume as its root device.