Orphaned EBS storage is the purest form of cloud waste. Nobody chose to pay for it. It accrues silently, month after month, with no instance attached and no alarm going off. A snapshot of a volume you deleted 18 months ago can still be billing you today. If you suspect you're paying for storage that backs nothing, you're probably right — and here's how to prove it and clean it up without destroying something you actually need.
Why am I still paying for a volume nothing is attached to?
An EBS volume in the available state — created, but not attached to any instance — bills at the full gp3 or gp2 rate, exactly as if it were in use. AWS has no concept of "this disk is idle, so it's cheaper." Storage is storage.
The most common way this happens is the EC2 billing surprise: stopping an instance does not stop its EBS charges. People stop a box to "save money," the compute charge halts, and the volumes keep billing quietly in the background. A 200 GB gp3 root volume is roughly $16/month — for a disk attached to nothing, or attached to an instance that hasn't run since spring.
Then there are the true orphans: a volume left behind when its instance was terminated with "delete on termination" turned off, a disk detached during a migration and never reattached, or a volume created for a restore that finished weeks ago.
Why is the snapshot problem even worse?
Snapshots are the part people forget entirely, and they're worse for two reasons.
First, they're incremental and cheap per snapshot — roughly $0.05/GB-month, and each new snapshot only stores the blocks that changed since the last one. That low per-unit price is exactly why nobody watches them.
Second, nothing deletes them by default. A snapshot outlives the volume it was taken from, then outlives the instance, then outlives the person who created it. A nightly backup job that's been running for two years, with no retention limit, has 730 snapshots quietly stacking up. Individually trivial; collectively a real line item — and one that keeps growing forever until someone intervenes.
Do the arithmetic on a realistic case. A team snapshots a 500 GB database volume every night and never expires anything. Because snapshots are incremental, each night only adds the changed blocks — but on a busy database that might be 20 GB of churn a day. After a year that's roughly 7 TB of snapshot data accumulated from a single 500 GB volume, at ~$0.05/GB-month — hundreds of dollars a month for backups nobody will ever restore from, because who restores a database to a random Tuesday from eight months ago? The waste isn't the recent snapshots you actually rely on; it's the long tail behind them that no policy ever trims.
How do I find them?
Start with unattached volumes. The available state filter finds every volume attached to nothing:
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime]' \
--output table
For snapshots, list the ones your account owns, then find the ones whose source volume no longer exists — the clearest orphan signal:
# All snapshots you own, oldest first
aws ec2 describe-snapshots --owner-ids self \
--query 'sort_by(Snapshots,&StartTime)[].[SnapshotId,VolumeId,VolumeSize,StartTime]' \
--output table
# Volume IDs that still exist — compare against the VolumeId column above
aws ec2 describe-volumes --query 'Volumes[].VolumeId' --output text
Any snapshot whose VolumeId isn't in the second list is a snapshot of a volume that's already gone. That's your orphan shortlist — but don't pipe it straight into a delete.
Two things make this harder than a single command suggests. First, EBS is regional — a volume or snapshot only shows up when you query the region it lives in, so a genuinely thorough audit means running these commands across every region you've ever touched, not just your default. Waste loves the regions you forgot you used. Second, an available volume's age is a useful triage signal: a volume that's been unattached for a day might be mid-migration, but one that's sat available for six months is almost certainly abandoned. Sort by CreateTime and start at the top.
How do I delete them safely?
Deleting EBS storage is irreversible. A snapshot whose source volume is gone is not automatically safe to delete — it may be the only remaining copy of that data, kept deliberately as a backup. It may also back an AMI: deleting a snapshot an AMI depends on can break your ability to launch that image. Before you delete a snapshot, check whether an AMI references it, and confirm it isn't your last line of recovery. Never bulk-delete on the raw output of a one-liner without reading it first — and if you're generating deletion commands, follow running scripts safely.
To check whether a snapshot backs an AMI before deleting:
# Which AMIs (if any) reference this snapshot?
aws ec2 describe-images --owners self \
--filters Name=block-device-mapping.snapshot-id,Values=snap-0123456789abcdef0 \
--query 'Images[].[ImageId,Name]' --output table
# Only after you've confirmed it's safe:
aws ec2 delete-volume --volume-id vol-0123456789abcdef0
aws ec2 delete-snapshot --snapshot-id snap-0123456789abcdef0
For unattached volumes, consider taking a final snapshot before deleting the volume if there's any chance the data matters — a snapshot is far cheaper to keep than a full available volume, and you can delete it later once you're sure.
How do I stop it growing back?
This is the step every listicle skips, and it's the difference between a one-off cleanup and a fixed problem. If you delete today's orphans but don't change how snapshots are created, you'll be back here in six months.
The durable fix is automated retention:
- Data Lifecycle Manager (DLM) lets you attach a policy to volumes by tag: take a snapshot on a schedule and automatically delete snapshots older than N days, keeping only the most recent M. This is the native, no-cost way to stop backups accumulating forever.
- AWS Backup gives you the same retention windows across services with centralized policy and reporting, if you'd rather manage backups in one place.
Either way, the principle is the same: every snapshot should be created by a policy that also knows when to delete it. A backup with no expiry isn't a backup strategy, it's a slow leak.
There's a prevention step for volumes, too. Most orphaned volumes are root volumes left behind because "delete on termination" was turned off when the instance launched. For anything but a database or a deliberately persistent disk, set DeleteOnTermination: true at launch so the root volume goes away with the instance instead of lingering in available. And tag volumes and snapshots with an owner and a purpose at creation — the reason orphaned storage survives cleanups is that nobody can tell whether a nameless snapshot from last year is a critical backup or forgotten junk, so it gets left "just in case." A tag turns that guess into a question you can actually answer.
What else should I check?
Orphaned storage usually travels with idle compute — the stopped instance whose volume you just found is often itself waste. If you're cleaning up disks, it's worth checking the instances too. See how to find idle EC2 instances for the companion cleanup, including why stopping an instance leaves its storage bill running.
How do I find this across my whole AWS account?
Finding one orphaned volume is easy. Finding every unattached volume and every snapshot-with-no-source across every region — and separating the ones safe to delete from the ones backing an AMI or serving as someone's only backup — is the tedious, error-prone part. That's what a scan is for. Parsivex checks each region, flags unattached volumes and orphaned snapshots, notes which snapshots back an AMI, and estimates the monthly savings for each.
For what these findings mean once they show up in your report, see Orphaned EBS volume and Orphaned EBS snapshot.