Unattached EBS Volumes | Reduce AWS Storage Costs

The problem

EBS charges are based on provisioned storage, not active attachment. When instances are replaced, scaled down, or manually deleted, their volumes can stay behind and keep billing with no workload using them.

Why it happens

EC2 instances are terminated manually without cleanup workflows for attached volumes.
Auto Scaling and migration work leaves data volumes behind for later review that never happens.
Teams keep orphaned disks "just in case" and lose track of whether they still contain useful data.

What this means for cost

Estimated monthly

$40 to $2,200/mo

Estimated annual

$480 to $26,400/yr

This waste pattern often shows up as $40 to $2,200/mo in recurring monthly cost, or roughly $480 to $26,400/yr if it sits untouched for a year.

How to detect unattached EBS volumes

The main signal is an EBS volume in the available state after the instance, Auto Scaling node, or migration target that used it has already moved on.

List volumes in the available state:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].{VolumeId:VolumeId,Size:Size,Type:VolumeType,AZ:AvailabilityZone,CreateTime:CreateTime,Tags:Tags}'

From there, sort by age, size, and tags. Older gp3 or io1 volumes with no recent owner tags are usually the first ones worth reviewing.

Cross-check with recent instance terminations, backups, or migration projects before deleting anything. A detached volume with no snapshot and no clear owner may still contain the only copy of application data.

What this detector actually checks

Cloud Waste Hunter only flags volumes that are already in the available state. The detector then:

estimates monthly cost from the volume size, region, and volume type
records age, tags, and creation time as review evidence
raises severity from medium to high once the detach age is long enough to look like cleanup drift rather than a fresh operational transition

That means this page is about orphaned block storage, not low-utilization attached volumes or snapshot retention.

How to fix unattached EBS volumes

A safe cleanup path is:

Verify the volume is not referenced by a running or planned workload.
Snapshot it if you need a recovery window.
Delete the volume once ownership and retention are clear.

aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 --description "Pre-delete backup"
aws ec2 delete-volume --volume-id vol-0123456789abcdef0

Longer term, enforce tagging and lifecycle review on detached volumes so they do not accumulate silently after operational changes.

Caveats and overlap boundaries

Detached volumes are often low-risk cleanup candidates, but not always. Migration rollback plans, incident forensics, and staged cutovers can all justify short-term retention. The storage waste pattern here is not “detached equals bad.” It is detached storage with no clear owner, no expiry, and no remaining workload role.

If the storage review finds billable S3 upload residue instead of block devices, continue into S3 Incomplete Multipart Uploads. That detector is about abandoned object-upload state, not EC2-attached storage.

How Cloud Waste Hunter helps

Cloud Waste Hunter surfaces detached EBS volumes with size, age, tags, region pricing, and estimated monthly savings so operators can separate intentional retention from true orphaned spend. For related storage cleanup work, continue into the AWS Storage Cost Optimization guide.

FAQ

Are unattached EBS volumes always safe to delete?

No. Some are intentional backups or staged data volumes. Review tags, snapshot status, and last known workload ownership before deletion.

Why does Cloud Waste Hunter treat some detached volumes as higher severity?

The detector escalates older detached volumes because a fresh detach can be part of a normal operational workflow, while long-lived available volumes are more likely to be orphaned cost.

Unattached EBS volumes cost and cleanup