Cost

Delete unattached EBS volumes

An "available" EBS volume costs the same as an attached one — find what's lingering and snapshot-then-delete before the bill compounds.

13 min·10 sections·AWS

Last reviewed 27 May 2026

Unattached EBS volumes: the basics

What does it mean for an EBS volume to be "available"?

An EBS volume has a State attribute that AWS uses to describe its attachment lifecycle: creating, in-use, available, deleting, deleted, error. The state most people misread is available — it sounds like a positive thing, almost like "ready and waiting," but it actually means the volume exists, is fully provisioned, and is not attached to any instance. AWS bills it identically to one that is attached.

Pricing is per GB-month, prorated to the second, regardless of whether bytes are being read or written. A 100 GB gp3 volume sitting in available costs roughly $8/month; a 100 GB gp2 about $10/month; io2 with provisioned IOPS can run an order of magnitude higher. The volume keeps billing until someone explicitly deletes it — there is no idle timeout, no automatic cleanup, and no warning email.

Wastage checks (EC2-012 "Unattached EBS Volumes") and AWS Cost Optimization Hub's "Delete unused EBS storage volume" recommendation both surface these resources directly. Findings range from $1.50/month for a forgotten 15 GB gp2 to over $100/month for a 1 TB encrypted database disk that was detached for a migration and never cleaned up. The dollars look small per volume; the count and the duration are what compound.

In this lesson you'll learn how unattached EBS volumes accumulate, how to tell which ones are safe to delete and which hold valuable data, and how to apply the snapshot-then-delete pattern that gives you a recovery path at roughly a fifth of the cost. You'll see the AWS CLI queries to inventory volumes by state and age, the Cost Optimization Hub recommendation shape for a deletion action, and the AWS Config rule that catches new offenders before they sit for months.

Fun fact

The DeleteOnTermination default that wasn't

Root EBS volumes default to DeleteOnTermination=true — when you terminate the instance, the root disk goes with it. Additional (non-root) volumes default to the opposite: DeleteOnTermination=false. The reasoning is conservative — AWS would rather charge you forever than auto-delete a database disk — but it means every team that mounts a data volume and later terminates the instance leaves an orphan behind. Audits routinely turn up volumes older than the engineers who created them.

Cleaning up an EBS graveyard

Nina inherits the AWS account for a healthcare imaging product. The finance team flags that EBS spend has crept up 30% year-over-year while instance count is flat. She suspects orphans.

She runs a Cost Optimization Hub query and gets back 47 unattached volume recommendations across three regions. The biggest is DB,ODP.xvdc-clear (vol-0f2b770bb6c5c84bc), 1 TB io1, savings of $106.72/month. Several smaller ones — a FUJIAWSPDICOM02-PROD-Dicom-DDrive-enc at $3.42/month, a handful of forgotten 15 GB gp2 boot disks at $1.50/month each.

Before deleting anything, Nina takes snapshots of every volume older than 30 days. Snapshots are incremental and compressed — typically 10-25% of the live volume's cost — so the recovery insurance for the whole fleet is cheaper than two months of carrying the originals.

First, inventory every volume currently in the available state, sorted by size to surface the big-ticket targets.

$ aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[].{Id:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime,Tags:Tags[?Key==`Name`]|[0].Value}' --output table

---------------------------------------------------------------------------------------------------

| DescribeVolumes |

+----------------------+-----------------------+------+--------+------------------------------+

+----------------------+-----------------------+------+--------+------------------------------+

| 2024-08-12T14:22:01Z| vol-0f2b770bb6c5c84bc | 1000 | io1 | DB,ODP.xvdc-clear |

| 2025-01-04T09:11:47Z| vol-000efb2936b1832ce | 150 | gp3 | FUJIAWSPDICOM02-DDrive-enc |

| 2025-11-30T17:03:18Z| vol-07c4a92e3f1b8b021 | 15 | gp2 | null |

| 2025-12-14T08:47:55Z| vol-04dd2581e6a7b59c2 | 30 | gp2 | test-instance-root |

+----------------------+-----------------------+------+--------+------------------------------+

# 47 volumes total, $312/mo bleed — the io1 alone is a third of it.

Sorted inventory. Volumes with null tags and dates over a year old are the obvious candidates.

Now pull the Cost Optimization Hub recommendation for the largest offender — it does the math and confirms the deletion is low-risk.

$ aws cost-optimization-hub get-recommendation --recommendation-id <id-for-vol-0f2b770bb6c5c84bc>

{

"recommendationId": "7a4f9c1e-...",

"actionType": "Delete",

"currentResourceType": "EbsVolume",

"resourceArn": "arn:aws:ec2:eu-west-1:123456789012:volume/vol-0f2b770bb6c5c84bc",

"estimatedMonthlySavings": 106.72,

"estimatedMonthlyCost": 106.72,

"estimatedSavingsPercentage": 100.0,

"implementationEffort": "VeryLow",

"restartNeeded": false,

"rollbackPossible": false,

"currentResourceDetails": { "ebsVolume": { "configuration": { "volumeType": "io1", "sizeInGigaBytes": 1000, "attachmentState": "detached" } } }

}

# rollbackPossible=false — snapshot before you act, or the data is gone for good.

Cost Optimization Hub confirms 100% savings (the volume contributes only cost, no value) but flags that deletion is irreversible.

Unattached volumes under the hooddeep dive

An EBS volume is a network-attached block device backed by replicated storage in the AZ where it was created. When you detach it from an instance — manually or as a side-effect of terminating that instance with DeleteOnTermination=false — the storage stays exactly where it was. No bytes are moved, no replicas torn down. AWS keeps billing at the same per-GB-month rate because the underlying capacity is still reserved on your behalf.

Volumes also retain metadata that hints at their origin. CreateTime tells you how long they've been around; the Attachments field is empty for unattached volumes but the volume's tags often still carry the name of the terminated instance, an AMI block-device-mapping reference, or a CloudFormation stack tag pointing at a stack that was deleted years ago. CloudWatch's VolumeReadOps and VolumeWriteOps metrics are usually zero for detached volumes — a clean signal that nothing is touching them — but check both within the last 14 days before deleting, since occasionally volumes get used by Lambda or one-off attach/detach scripts.

Snapshots are the safety net. A snapshot is an incremental, point-in-time copy stored in S3 (via the EBS snapshot service); only the changed blocks since the last snapshot are billed. Pricing is roughly $0.05/GB-month for snapshot data — so a 1 TB volume that snapshots to a 600 GB compressed footprint costs about $30/month to keep as insurance vs. ~$125/month to keep live. You can restore it to a new volume in any AZ in the same region with one API call.

# Find the last write timestamp for a volume — confirm it's truly idle.
aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name VolumeWriteOps \
  --dimensions Name=VolumeId,Value=vol-0f2b770bb6c5c84bc \
  --start-time $(date -u -d '14 days ago' +%FT%TZ) \
  --end-time $(date -u +%FT%TZ) \
  --period 86400 \
  --statistics Sum

# Inspect the AMI block device mappings to see if any AMIs reference this volume's snapshots.
aws ec2 describe-images --owners self \
  --query 'Images[].BlockDeviceMappings[?Ebs.SnapshotId!=`null`].Ebs.SnapshotId' \
  --output text

What is the impact of leaving unattached volumes lying around?

The direct cost is straightforward and easy to underestimate. A single 15 GB gp2 boot disk left behind from a test instance costs about $1.50/month — call it $18/year. Multiply that across an organization with three regions, ten teams, and five years of accumulated cruft and the same trivial figure becomes tens of thousands of dollars annually. The Fuji healthcare example in our data set had a single 150 GB encrypted disk at $3.42/month sitting next to a 1 TB io1 at $106.72/month — a $110/month bleed from two volumes nobody was using.

The second-order impact is encryption and compliance drift. Volumes that were created before your account turned on default encryption stay unencrypted forever — they're not retroactively re-keyed. If those volumes end up restored or attached during an incident response, you've reintroduced an unencrypted disk into a fleet you thought was fully encrypted. The same applies to KMS key rotation: orphan volumes keep references to keys you may have wanted to schedule for deletion, blocking cleanup of old key material.

Snapshot sprawl is the third effect. Every orphan volume tends to have at least one orphan snapshot — and EBS snapshots also bill per GB-month. A common audit finding is a fleet with $300/month of unattached volumes carrying $200/month of stale snapshots behind them. The cleanup loop has to cover both: snapshot the volume for safety, then delete the volume, then later prune the snapshots that are older than your retention policy.

Operationally, large numbers of available volumes also slow down the EC2 console and clutter every describe-volumes call your tooling makes. Drift detection tools spend cycles reconciling resources nobody owns, and on-call engineers see them as noise during incident triage.

How do you clean up safely?

Cleaning up unattached EBS volumes is a four-step loop. Skip any step and you either delete data you needed or leave the next generation of orphans growing behind you.

1. Inventory with confidence

Pull every volume in State=available per region, joined with CreateTime, Tags, and the last VolumeWriteOps timestamp from CloudWatch. Filter the list to anything older than 30 days with no writes in the last 14 — that's your safe-to-act bucket. Cross-check against AMI block device mappings: any volume whose snapshots are referenced by an active AMI deserves a closer look before deletion.

2. Snapshot before you delete

Take a snapshot of every volume you intend to delete — tag the snapshot with the volume's original name, the deletion ticket ID, and a retention date. Snapshots cost roughly 10-25% of the live volume per month. Keep them for 30-90 days depending on your data classification policy, then prune. This is the cheapest insurance you'll ever buy against "the email we sent last quarter said it was safe to delete."

3. Delete in batches with a guardrail

Cost Optimization Hub exposes a Delete EbsVolume action with restartNeeded=false and rollbackPossible=false — meaning the deletion is non-disruptive to running infrastructure but cannot be undone. Use aws ec2 delete-volume in a loop, but add a guardrail: refuse to delete anything created in the last 7 days, anything with a tag matching do-not-delete, or anything still showing CloudWatch writes. Log each deletion with the volume ID, size, and pre-deletion snapshot ID.

4. Prevent recurrence

Enable the AWS Config rule ec2-volume-inuse-check to flag any new unattached volume as soon as it appears. In your launch templates and CloudFormation stacks, set DeleteOnTermination=true on non-root volumes wherever the data isn't stateful — most ephemeral disks should auto-delete with the instance. For stateful disks, tag them clearly with Lifecycle=Stateful and a clear owner so a future cleanup script knows to skip them. Pair the Config rule with an EventBridge rule that posts to Slack whenever a new orphan appears, so the bleed never restarts.

# Snapshot-then-delete loop with safety filters.
VOLUMES=$(aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[?CreateTime<=`'$(date -u -d '30 days ago' +%Y-%m-%d)'`].[VolumeId,Size,VolumeType]' \
  --output text)

while read -r VOL_ID SIZE TYPE; do
  # Skip anything tagged do-not-delete.
  if aws ec2 describe-tags --filters Name=resource-id,Values=$VOL_ID Name=key,Values=do-not-delete --query 'Tags[0]' --output text | grep -qv None; then
    echo "Skipping $VOL_ID (do-not-delete tag)"; continue
  fi

  SNAP_ID=$(aws ec2 create-snapshot \
    --volume-id $VOL_ID \
    --description "Pre-delete snapshot of $VOL_ID" \
    --tag-specifications "ResourceType=snapshot,Tags=[{Key=Lifecycle,Value=PreDelete},{Key=SourceVolume,Value=$VOL_ID}]" \
    --query SnapshotId --output text)

  echo "$VOL_ID ($SIZE GB $TYPE) snapshotted as $SNAP_ID — deleting volume."
  aws ec2 delete-volume --volume-id $VOL_ID
done <<< "$VOLUMES"

Quick quiz

Question 1 of 5

An EBS volume has been in the available state for 18 months, has no VolumeWriteOps in the last 14 days, no do-not-delete tag, and Cost Optimization Hub flags it as Delete EbsVolume with restartNeeded=false and rollbackPossible=false. What's the right next step?

Keep learning

Dig deeper into EBS lifecycle, snapshot economics, and the AWS controls that prevent orphan accumulation.

You've completed Delete unattached EBS volumes. You now know why available is the most expensive word in the EBS state machine, how to inventory orphans honestly, and how the snapshot-then-delete loop gives you a recovery path at a fraction of the storage cost. Next time the bill creeps up while your instance count holds flat, you'll have a four-step loop — inventory, snapshot, delete, prevent — ready to run.

Back to the library

Unattached EBS volumes: the cost story

Provisioned capacity that bills continuously whether or not anything uses it

EBS volumes in the available state are fully provisioned block storage with no instance attached. AWS bills them at exactly the same per-GB-month rate as attached volumes — there is no idle discount, no grace period, and no automatic cleanup. A volume detached during a migration six months ago has been generating a bill every second since.

The cost is predictable and easy to model: gp3 runs $0.08/GB-month, gp2 $0.10/GB-month, and io1/io2 can exceed $0.125/GB-month plus provisioned IOPS charges. A single 1 TB io1 volume left orphaned is roughly $107/month — over $1,280 per year — with zero business value delivered. Multiplied across multiple teams, regions, and years of accumulated turnover, this category routinely surfaces as a top-five waste line on cloud bill audits.

The finance lens here is accumulation rate versus cleanup cost. Individual volumes look cheap; the fleet total rarely is. Cost Optimization Hub expresses each orphaned volume as a 100%-savings deletion action with implementationEffort: VeryLow — the engineering time to act is minimal. The FinOps contribution is ensuring savings are realized promptly, tracked in cost reporting, and not rebuilt through unchanged provisioning habits in the following quarters.

This lesson is for the finance partner who sees storage costs climbing without a clear explanation. It explains what an unattached EBS volume is, why AWS keeps billing for it, and how to model the savings from a cleanup — including how to treat snapshot insurance costs in the calculation. No commands required; the focus is on the tiering logic, the dollar arithmetic, and the governance levers that prevent the bleed from restarting.

Fun fact

The DeleteOnTermination default that wasn't

How a finance partner drives the EBS cleanup conversation

Priya is the FinOps lead for a healthcare technology company. At the quarterly cloud spend review she notices EBS storage costs are up 28% year-over-year while the engineering team reports no significant new workloads. She pulls Cost Optimization Hub and finds $312/month in unattached volume recommendations — 47 volumes spread across three regions, ranging from a $1.50/month forgotten boot disk to a $106.72/month 1 TB io1 database disk that was detached during a migration and never cleaned up.

Priya does not immediately approve a delete-everything action. Instead she asks engineering to run the inventory with age and last-write data, then classifies the list into two buckets: volumes older than 30 days with no CloudWatch write activity in the last 14 days (clearly safe to act on after snapshotting), and younger volumes or ones with recent I/O (needs an owner check first). The first bucket covers $290/month of the total.

Her framing for the spend review: the $290/month reduction requires roughly $30/month of snapshot insurance for 60 days, then the snapshots age out and the net saving is clean. Total one-time snapshot cost is about $60 against a $3,480 annualized saving. She records the line items in the cost-optimization tracker and books a 30-day check to confirm the volumes were deleted and the savings are visible in the next billing period.

Why this category deserves a line on the cost-optimization register

Unattached EBS volumes are one of the cleanest waste categories to model because the saving is 100% of current cost — there is no right-sizing trade-off, no performance consideration, no risk of under-provisioning. Every dollar spent on an unattached volume is pure waste, and the Cost Optimization Hub recommendation confirms this explicitly with estimatedSavingsPercentage: 100. That makes it an easy line to own in a cost-optimization register: identify the volumes, quantify the monthly bleed, track the deletion, and verify the saving appeared in the next bill.

The compounding nature is the key finance argument. A $3.42/month encrypted disk sounds trivial. But if that pattern applies to 20 volumes across 5 teams over 3 years, the real number is $3.42 × 20 × 36 = $2,462 for resources that delivered nothing. EBS waste audits routinely surface five-figure annual figures from per-volume amounts that nobody flagged individually. The finance contribution is to aggregate and surface the fleet-level total, not just the per-resource cost.

There is also a secondary cost in snapshot sprawl. Every orphaned volume tends to generate at least one orphaned snapshot — and snapshots bill per GB-month too. A full cleanup must account for both: snapshot the volume for safety, delete the volume, then prune stale pre-deletion snapshots after the retention window. Budget the snapshot cost as a 30-60 day transition expense, then model the net saving from month two onward.

Exception management matters here. Volumes tagged Lifecycle=Stateful or do-not-delete should be treated as inventory items with an owner — not as waste findings. Finance should ask for a brief owner-and-purpose annotation on any stateful volume that isn't attached, so the distinction between "intentionally detached" and "orphaned" is clear at the next audit.

The finance partner's four levers for EBS waste

Finance can't run the delete loop, but it owns the framing that turns a one-time cleanup into a durable cost reduction. Four levers, applied at the regular cadence.

1. Quantify the fleet total, not the per-volume cost

The relevant number for a cost review is total monthly spend on unattached volumes across all regions and teams, not individual item costs. Pull this from Cost Optimization Hub or directly from describe-volumes filtered to available state, multiplied by GB-month pricing per volume type. Put this number on the cost-optimization tracker as a named line item with a target close date.

2. Account for snapshot transition costs

The snapshot-before-delete pattern adds a short-term cost: roughly $0.05/GB-month for the snapshot footprint, held for 30-90 days. Budget this as a one-time transition expense and model net savings from month two onward. A 1 TB volume at $107/month produces roughly $30 in snapshot insurance costs before the clean saving begins — a 3.5-week payback period. Make this explicit in the business case so the cleanup isn't blocked by a short-term cost spike.

3. Require tagged ownership for stateful volumes

Any volume intentionally kept unattached (for example, a data disk awaiting reattachment after maintenance) should carry a Lifecycle=Stateful or Owner=<team> tag with a documented reason. Finance should include a count of tagged-stateful vs. untagged-available volumes on the storage review — the untagged number should trend toward zero over time as cleanup and tagging policies take hold.

4. Measure recurrence rate after the cleanup

Track the volume of new unattached-volume findings generated each month after a cleanup sprint. If the count stays near zero, the prevention controls (DeleteOnTermination defaults, Config rule, EventBridge alert) are working. If it climbs back, the provisioning habits haven't changed. This is the metric that tells you whether you've solved the problem or just deferred it by 90 days.

Quick quiz

Question 1 of 5

A Cost Optimization Hub report shows 38 unattached EBS volumes totaling $420/month. Eight are tagged Lifecycle=Stateful with owner annotations; the other 30 are untagged and show no CloudWatch write activity in the last 14 days. As the FinOps lead, what is the right framing for the next cost review?

Keep learning

Dig deeper into EBS lifecycle, snapshot economics, and the AWS controls that prevent orphan accumulation.

You've finished the finance view of EBS volume waste. You know how to model the fleet-level saving (not the per-volume cost), how to budget the snapshot transition expense so the business case is accurate, and the four levers — fleet-total quantification, tagged-ownership enforcement, snapshot accounting, and recurrence tracking — that make this a managed cost category rather than a recurring fire drill. Next time you see EBS costs drifting up, you'll know exactly which question to ask and what a credible remediation plan looks like.

Back to the library

Unattached EBS volumes: the headline

Storage the business is paying full price for that nothing is using

When an EC2 instance is terminated, its attached storage disks do not automatically disappear — they stay provisioned and billing unless someone explicitly deletes them. AWS charges full price for storage sitting completely idle. This is a primary driver of cloud storage costs growing year-over-year while the number of running servers stays flat.

This is a hygiene and governance issue, not a trade-off. There is no business case for an unattached volume — it is purely a clean-up backlog. The leadership question is whether the org has a standing process to catch and clear orphaned storage before it compounds, or whether it accumulates quietly until the next bill review.

A short read for the leader who wants to know why the cloud storage bill drifts up and what a well-run team does about it. You'll get the plain-English version of orphaned storage, why it compounds, and what a healthy posture looks like — a standing detection process, not a one-time cleanup. No technical implementation detail.

Fun fact

The DeleteOnTermination default that wasn't

What the pattern looks like when it's working

At one mid-size SaaS company, the engineering director, Marcus, got a question from the CFO: "Why does our cloud storage bill keep growing when we haven't launched anything new?" The answer was orphaned EBS volumes — disks left behind every time a team spun down an environment or migrated a database without running a cleanup script.

After a one-time audit cleared the existing backlog, Marcus put one rule in place: any EBS volume that has been unattached for more than 30 days triggers an alert to the owning team with a two-week response window. No response means it gets snapshotted and deleted automatically. The standing process costs almost nothing to run and keeps the orphan population near zero.

The CFO's question stopped coming up. The bill no longer drifted. That's the right end state — not a quarterly fire drill, but a process that catches orphans before they compound.

Why the bill drifts without anyone noticing

Cloud storage waste compounds because no single volume is large enough to trigger an alert, but the fleet total is. A $3/month orphaned disk gets ignored; forty of them across three regions is $1,440 a year. The mechanism is structural: AWS defaults to keeping storage when an instance is terminated, and no team member is accountable for the resulting orphans unless someone actively assigns ownership.

The second issue is that orphaned volumes are invisible in normal cost reporting. They appear as a line in EBS costs that grows steadily, but there is no "unused storage" breakout unless someone runs the Cost Optimization Hub query or sets up the Config rule. This means the waste often goes undetected for quarters or years — until a finance review spots a storage cost trend that doesn't track with usage growth.

The governance gap this exposes is the absence of a standing cleanup process. One-time audits clear the backlog; they don't prevent recurrence. The durable fix is a policy — detect orphans within 30 days, notify the owning team, delete with a snapshot safety net if there's no response. That converts an accumulating cost liability into a managed, near-zero baseline.

The leadership ask on EBS waste

The executive action is not to mandate a cleanup sprint — it's to require a standing process so orphaned storage never accumulates to audit-level numbers again.

1. Set a detection SLA: 30 days to identify, 60 days to act

Require that any EBS volume unattached for more than 30 days appears on an owner's radar within that window, and is either tagged as intentionally stateful or deleted within 60 days. This converts a bottomless accumulation problem into a bounded, manageable queue.

2. Accept tagged exceptions, not silent ones

Some volumes are legitimately unattached for operational reasons. Those are fine — but they should carry a tag that says who owns them and why. An untagged, unattached volume older than 30 days is the definition of unacceptable drift. The policy distinction is between "intentionally idle" and "forgotten."

3. Ask for the recurrence trend, not just the cleanup count

At the quarterly review, the one signal that matters is whether the number of new orphaned volumes per month is declining. A falling trend means provisioning habits are changing. A flat or rising trend means the cleanup was a one-time event and the underlying cause wasn't addressed. That's the leadership question: is this solved, or deferred?

Quick quiz

Question 1 of 5

Six months after a major EBS cleanup sprint that cleared $300/month in orphaned volumes, the monthly report shows unattached EBS volumes back at $180/month. What does this signal?

Keep learning

Dig deeper into EBS lifecycle, snapshot economics, and the AWS controls that prevent orphan accumulation.

Two takeaways: orphaned EBS storage accumulates silently because AWS defaults to keeping disks when instances terminate, and one-time cleanups don't fix the problem unless provisioning defaults and detection automation are updated at the same time. The leadership measure is not the cleanup count — it's whether new orphans per month is trending toward zero.

Back to the library

Part of the learning path Cut your storage bill

Delete unattached EBS volumes

Unattached EBS volumes: the basics

The DeleteOnTermination default that wasn't

Cleaning up an EBS graveyard

Unattached volumes under the hooddeep dive

What is the impact of leaving unattached volumes lying around?

How do you clean up safely?

1. Inventory with confidence

2. Snapshot before you delete

3. Delete in batches with a guardrail

4. Prevent recurrence

Quick quiz

Keep learning

Unattached EBS volumes: the cost story

The DeleteOnTermination default that wasn't

How a finance partner drives the EBS cleanup conversation

Why this category deserves a line on the cost-optimization register

The finance partner's four levers for EBS waste

1. Quantify the fleet total, not the per-volume cost

2. Account for snapshot transition costs

3. Require tagged ownership for stateful volumes

4. Measure recurrence rate after the cleanup

Quick quiz

Keep learning

Unattached EBS volumes: the headline

The DeleteOnTermination default that wasn't

What the pattern looks like when it's working

Why the bill drifts without anyone noticing

The leadership ask on EBS waste

1. Set a detection SLA: 30 days to identify, 60 days to act

2. Accept tagged exceptions, not silent ones

3. Ask for the recurrence trend, not just the cleanup count

Quick quiz

Keep learning

Related cost lessons