An unattached EBS volume is the purest form of cloud waste there is. It holds data nobody reads, serves no instance, and bills at exactly the same rate as a volume doing real work. There is no performance trade-off to weigh and no capacity headroom to preserve. It is a line on your invoice with nothing on the other side of it.

They are also easy to find, which makes them the right place to start. Everything here comes from a single read-only API call.

Why volumes end up detached in the first place

Almost nobody creates an orphaned volume deliberately. They accumulate through three routine paths.

The DeleteOnTermination default. When you launch an instance, its root volume is normally set to delete when the instance terminates. Any additional volume attached at launch is not. That default is protective, and it is correct as a default, because the data volume is usually the one you would be devastated to lose. It also means every terminated instance that carried a second disk leaves that disk behind, still billing, with no instance to point back to.

Rebuilds and blue-green cutovers. Replace an instance rather than modify it, and the old volume survives the swap. The new instance works, nobody looks back, and the old disk quietly stays.

Failed or abandoned Terraform runs. A partial apply can create a volume and then fail before attaching it. Because it was never in the state file as attached, a later destroy does not necessarily remove it.

None of these are mistakes exactly. They are the accumulated residue of normal operations, which is why the total tends to grow steadily rather than appear all at once.

What one actually costs

An available volume bills for provisioned capacity at its type's per-GB rate, every hour, until deleted. The rate depends on the type it happens to be, not on whether it is attached.

Volume typeStorage, per GB-month500 GB, per monthPer year
gp3$0.08$40.00$480
gp2$0.10$50.00$600
io1$0.125 plus provisioned IOPS$62.50 plus IOPS$750 plus IOPS
standard (magnetic)$0.05 plus per-request charges$25.00 plus requests$300 plus requests

Figures are us-east-1 list prices and move by region. The shape is what matters: a single forgotten half-terabyte volume is a few hundred dollars a year, and accounts that have been running for a while rarely have just one.

Two costs are deliberately excluded from that table because they cannot be read off a volume description. On io1 and io2 the provisioned IOPS component is billed separately and is frequently larger than the storage line. On standard volumes there is a per-request charge that depends entirely on access patterns. An honest report quotes the storage saving, says the IOPS component exists, and does not invent a figure for it.

Finding them

An unattached volume reports status=available. Attached volumes report in-use. One call per region:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --region ap-south-1 \
  --query 'Volumes[].{ID:VolumeId,GB:Size,Type:VolumeType,Created:CreateTime,AZ:AvailabilityZone}' \
  --output table

Two things to know before you act on the output.

It is per-region. describe-volumes answers for the region you call it in. Orphans collect in regions nobody looks at, often ones opened for a proof of concept and never closed, so a sweep that checks only your primary region will under-report. Loop over every enabled region.

Age is the signal, not existence. A volume detached twenty minutes ago is probably somebody mid-task. One detached since March is nobody's. CreateTime is the closest reliable proxy available from the description, and it is a proxy: it tells you when the volume was made, not when it was last used.

The related leak that hides better

There is a second version of this that is easier to miss, because the resource does not look abandoned at all.

A stopped EC2 instance stops billing for compute. Its EBS volumes keep billing in full.

This catches people because stopping an instance feels like turning it off, and in every way that matters for the compute charge it is. The storage is untouched by that, which is the entire point of stopping rather than terminating: the disk survives so you can start again. If you are never going to start it again, you are paying to preserve a disk for a machine that is not coming back.

These volumes never show as available, because they are still attached. They will not appear in the query above. You have to go the other way, from stopped instances to their block device mappings:

aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=stopped \
  --region ap-south-1 \
  --query 'Reservations[].Instances[].{ID:InstanceId,Since:StateTransitionReason}' \
  --output table

The block device mappings on an instance carry volume IDs but not sizes, so pricing the exposure means a second describe-volumes call against those IDs.

Our own analyzer waits 14 days before reporting a stopped instance. An instance stopped for an afternoon is somebody working. One stopped for a fortnight is a machine nobody restarted. Flagging the first kind trains people to ignore the report, which costs more than the finding is worth.

Deleting one safely

Deleting an EBS volume is irreversible and immediate. There is no recycle bin. The only safe order is snapshot first, verify, then delete.

# 1. Snapshot, and label it so the next person knows why it exists
aws ec2 create-snapshot \
  --volume-id vol-0abc123 \
  --description "pre-deletion backup, orphaned since 2026-03" \
  --region ap-south-1

# 2. Wait for it to complete — do not skip this
aws ec2 wait snapshot-completed --snapshot-ids snap-0def456 --region ap-south-1

# 3. Then delete
aws ec2 delete-volume --volume-id vol-0abc123 --region ap-south-1

A snapshot costs roughly $0.05 per GB-month and is billed incrementally, on changed blocks rather than provisioned size, so it is usually a small fraction of what the volume was costing. That trade is almost always worth making. It is also the reason to put a retention date in the description: snapshots taken "just in case" and then forgotten are the next cost leak, and they are the one this exact habit creates.

Check for encryption and attachments first. A volume that is part of a Multi-Attach configuration can be detached from one instance and still in use by another. Confirm the Attachments array is genuinely empty rather than trusting the status alone.

What a report can and cannot tell you

Everything above is mechanical. The judgement is in what a tool claims about it, and this is where cost reports usually overreach.

A scanner can prove a volume is unattached and prove what it costs. It cannot prove the volume is safe to delete. It does not know whether that disk holds the only copy of something. So the finding should say what is true, which is that the volume is detached and billing, and leave the decision where it belongs.

One disclosure about our own numbers, since this page argues for stating them plainly. InfraSync prices unattached volumes at the gp3 rate regardless of the volume's actual type. For an unattached gp2 volume, which bills at $0.10 per GB-month, the reported figure of $0.08 is therefore a floor rather than an estimate. It understates. We would rather a customer find the real number is larger than the report promised than the other way round, but you should know which direction the error runs.

The wider rule that comes from is covered in the AWS cost optimization guide: a claim may never exceed the evidence behind it.

Frequently asked questions

Do unattached EBS volumes still cost money?

Yes, at the full rate for their provisioned size. An EBS volume in the available state bills identically to one attached to a running instance. Detaching a volume saves nothing at all; only deleting it does.

How do I find unattached EBS volumes across all regions?

Run aws ec2 describe-volumes with the filter Name=status,Values=available once per enabled region. The API answers only for the region it is called in, so a single call under-reports. Orphans concentrate in regions opened for a proof of concept and never closed.

Why do EBS volumes survive when the instance is terminated?

Because DeleteOnTermination defaults to true only for the root volume. Any additional volume attached at launch defaults to false, so it survives termination by design. That default protects data volumes, which is usually right, and it is also the single most common source of orphaned volumes.

Does stopping an EC2 instance stop EBS charges?

No. Stopping an instance ends the compute charge but every attached EBS volume continues billing in full. That is the point of stopping rather than terminating, since the disk survives so you can start again. If the instance is never restarted, you are paying to preserve a disk for a machine that is not coming back.

Should I snapshot before deleting an EBS volume?

Almost always. Volume deletion is immediate and irreversible, and a snapshot is billed incrementally on changed blocks rather than provisioned size, so it typically costs a small fraction of the volume. Wait for the snapshot to reach completed before deleting, and put a retention date in the description so the snapshot does not become the next forgotten cost.

How long should a volume be detached before it is safe to clean up?

There is no universal number, and existence alone is a weak signal. A volume detached for twenty minutes is usually someone mid-task. Our analyzer waits 14 days before reporting a stopped instance for the same reason: flagging normal short-lived states trains people to ignore the report.