Why EBS costs sneak up on you
EBS does not have its own dashboard the way EC2 or RDS do. Volumes and snapshots live inside the EC2 console, under separate tabs that most people only visit when they are actively attaching a new disk. As a result, EBS is one of the easiest places for AWS spend to accumulate without anyone noticing — the charges show up as 'EC2 - Other' in your bill, disconnected from any specific instance you can point to.
The two biggest sources of EBS waste are unattached volumes and old snapshots. Both are cheap individually and expensive in aggregate.
Unattached volumes: the most common EBS waste
When you terminate an EC2 instance, the root volume is usually deleted automatically (unless you changed the 'delete on termination' setting). Additional data volumes you attached separately often are not — they persist in an 'available' state, meaning no instance is using them, but AWS keeps billing at full rate.
A 500GB gp3 volume costs $40/month whether it is attached to a running instance or sitting unattached in a region nobody looks at. Ten forgotten volumes across a team is $400/month for storage nobody is reading from or writing to.
How to find them
- ✓Go to EC2 → Elastic Block Store → Volumes and filter State = available
- ✓Sort by Size to prioritize the most expensive ones first
- ✓Check the Created date — volumes older than 30 days with no Name tag are almost always safe to remove
- ✓Repeat this in every region you use — EBS volumes are regional and the console only shows your current region
What to do before deleting
- ✓Create a snapshot first — it costs a fraction of the volume's monthly price and gives you a restore point
- ✓If the volume has no Name tag, no snapshot history, and predates any current project, it is almost certainly safe to delete outright
- ✓Delete the volume once you have a snapshot or have confirmed it is genuinely unneeded
Snapshots: the cost that compounds silently
Every AMI you bake, every manual snapshot, and every automated backup policy leaves behind an EBS snapshot billed at roughly $0.05/GB/month. A single 100GB snapshot is $5/month — trivial on its own. The problem is that snapshots accumulate and rarely get reviewed, because nothing in day-to-day operations forces you to look at the Snapshots tab.
Daily automated snapshots of a 200GB volume generate 30 snapshots a month. Even with EBS's incremental storage model (each snapshot after the first only stores changed blocks), a year of daily snapshots on an active volume can add up to $100-$300/month for a single source volume — and most teams have more than one.
How to find snapshot waste
- ✓Go to EC2 → Elastic Block Store → Snapshots, filter Owner = self
- ✓Sort by Start Time to surface the oldest snapshots first
- ✓Check the Volume column — if it shows no source volume, the snapshot is orphaned from a volume that was already deleted, and it is safe to remove if you no longer need the data
- ✓If you use Data Lifecycle Manager or AWS Backup, review the retention period on each policy — 'keep forever' is rarely the intended setting
gp2 vs gp3: a quick, low-risk win
If you still have volumes on the older gp2 type, migrating to gp3 is one of the few EBS changes that saves money with essentially no downside. gp3 is roughly 20% cheaper per GB than gp2 at the same baseline performance, and you can resize or change the volume type on a running, in-use volume without downtime through the EC2 console or CLI.
This is not a waste-elimination step — it applies to volumes you are actually using — but it is worth doing at the same time as an EBS audit since it requires no architecture change and no risk assessment.
Setting a retention policy so this does not happen again
A one-time cleanup fixes the current waste. It does not stop new unattached volumes and orphaned snapshots from accumulating next quarter. If you use Data Lifecycle Manager, set an explicit retention count or age limit on every policy rather than leaving snapshots to accumulate indefinitely. For unattached volumes, the more reliable fix is not a policy — it is something that actually checks volume state on a schedule and flags anything sitting idle.
Driftak scans connected AWS accounts for EBS volumes in the 'available' state (not attached to any instance) alongside stopped EC2 instances, unassociated Elastic IPs, stopped RDS instances, and load balancers with no healthy targets, and estimates the monthly cost of each. Alerts go out through Slack, email, Telegram, or a webhook when something new turns up idle, so a forgotten volume gets caught in days instead of surfacing as a mystery line item eight months later.
Connecting takes a read-only IAM Role — Driftak never requests write or delete permissions, and the policy is public so you can review exactly what it can see before you connect.