EBS volume cleanup means finding the disks you are paying for but not using, the unattached volumes left behind when instances were terminated, the oversized disks provisioned far larger than the data on them, and the orphaned snapshots that quietly accumulate, then deleting them safely once you have confirmed nothing depends on them. Because EBS charges for capacity you provisioned rather than data you store, a 500 GB volume that is 12 percent full costs the same as a full one, and an unattached volume costs the same as a busy one. Clearing this storage has no performance impact, which makes it one of the safest savings on AWS.
This how-to sits under our complete guide to AWS cost optimization, the pillar for this cluster, and it is part of the Cut step in our See, Cut, Lock, Run method. Idle storage almost always travels with idle compute, so run this alongside finding and killing idle EC2 instances, and use the Cost and Usage Report to rank the largest storage dollars first.
An unattached volume might be a deliberate cold spare, a forensic copy held for compliance, or a disk waiting to be re-attached during a migration. Low usage is a flag, not a verdict. The discipline is entirely in the confirmation step.
Find the unattached EBS volumes first
The fastest dollars are in volumes whose state is "available" rather than "in-use". An available volume is attached to nothing, doing nothing, and billed in full. List every volume across every account and region, filter to the available state, and you have your first target list. Sort it by size, because a handful of large available volumes usually outweigh dozens of tiny ones. Check the creation date and any tags: a volume that has been available for months with no owner tag is almost certainly forgotten, while one created yesterday may be mid-migration. Snapshot anything you are unsure about before you delete it, so the data is recoverable cheaply if someone surfaces who needed it.
Then catch the oversized disks
Oversized disks are harder to see because they are attached and in use, they are just far larger than the data on them. Compare the provisioned size of each in-use volume against the actual filesystem usage reported from the instance, and the gaps stand out: a 1 TB disk holding 80 GB is paying for 920 GB of empty space every hour. Resizing down on EBS is not a one-click operation, it requires creating a smaller volume and migrating the data, so weigh the saving against the effort and prioritise the largest gaps. Where a workload genuinely needs the headroom, leave it; where the size was a guess that never got revisited, that is real recoverable spend.
Match the volume type to the workload
Disk type is its own saving. As of May 2026, gp3 is the general-purpose SSD default and is materially cheaper per gigabyte than the older gp2, while letting you provision IOPS and throughput separately rather than buying a bigger disk just to get more performance. Many environments still run gp2 volumes provisioned before gp3 existed. Migrating suitable gp2 volumes to gp3 cuts the per-gigabyte cost and often the performance-padding cost at the same time. For cold data that rarely needs fast access, the throughput-optimised and cold HDD types are cheaper still. Verify the current EBS volume types and per-gigabyte pricing in the AWS documentation for your region before you migrate, as pricing and type availability change.
Want every wasted gigabyte found and cleared?
Our AWS cost audit inventories every EBS volume and snapshot across all accounts, ranks the unattached and oversized disks by dollars, and runs the safe snapshot-then-delete process for you. On the performance model you pay only from realized savings. No savings, no fee.
Book an AWS cost audit →Do not forget the snapshots
Every snapshot you keep has a storage cost, and snapshots breed. Automated backup policies create them on a schedule, terminated instances leave their snapshots behind, and old AMIs sit on snapshots nobody references anymore. Find snapshots whose source volume no longer exists, snapshots far older than your retention policy requires, and AMIs that are deregistered but whose snapshots were never removed. Snapshots are incremental, so deleting one does not always free its full apparent size, but at scale the savings are real. Set a lifecycle policy so snapshots expire automatically rather than accumulating, which moves this from a one-time cleanup to a standing control.
| What you find | Reading | Action |
|---|---|---|
| Volume in "available" state | Attached to nothing, billed in full | Snapshot, confirm owner, delete |
| Large disk, low filesystem use | Paying for empty space | Resize down or migrate data |
| gp2 volume, modern workload | Older, pricier SSD type | Migrate to gp3 |
| Snapshot with no source volume | Orphaned backup | Confirm retention need, delete |
EBS volume types, states, and snapshot behavior reflect AWS as of May 2026. Confirm gp3 pricing and resize procedures in the AWS console for your region before acting, as defaults and pricing vary.
The AWS Cost Optimization Field Guide includes the queries we use to list available volumes and orphaned snapshots across every account, and the gp2-to-gp3 migration checklist. It is the downloadable companion to this how-to.
The short version
Start with unattached EBS volumes in the available state, the purest waste. Snapshot anything uncertain, confirm there is no owner or dependency, then delete. Catch oversized disks by comparing provisioned size to real usage, migrate suitable gp2 volumes to gp3, and clear orphaned snapshots and old AMIs. Add a snapshot lifecycle policy so the cleanup sticks. Storage cleanup is a fast, safe move in any AWS cost optimization engagement, and it contributed to the result in our SaaS on AWS case study.