---
title: Amazon EBS Pricing: Why Deleted EC2 Instances Never Stop the Volume Bill
description: EBS is billed across six dimensions — gp3 storage at $0.08/GB-month, separate IOPS and throughput line items, io2 Block Express, snapshots at $0.05/GB-month, fast snapshot restore at $0.75/DSU-hour. Deleting an EC2 instance never stops the volume bill, and the gp2→gp3 migration is one of the cleanest 20% wins in cloud cost.
url: https://www.factualminds.com/blog/amazon-ebs-pricing-orphaned-volumes-snapshots/
datePublished: 2026-06-13T00:00:00.000Z
dateModified: 2026-06-13T00:00:00.000Z
author: palaniappan-p
category: Cost Optimization & FinOps
tags: aws-ebs, ebs-pricing, aws-pricing, cost-optimization, finops, storage
---
# Amazon EBS Pricing: Why Deleted EC2 Instances Never Stop the Volume Bill
> EBS is billed across six dimensions — gp3 storage at $0.08/GB-month, separate IOPS and throughput line items, io2 Block Express, snapshots at $0.05/GB-month, fast snapshot restore at $0.75/DSU-hour. Deleting an EC2 instance never stops the volume bill, and the gp2→gp3 migration is one of the cleanest 20% wins in cloud cost.
import PricingHeroStats from '~/components/blog/PricingHeroStats.astro';
import PricingDimensionTable from '~/components/blog/PricingDimensionTable.astro';
import BillSurpriseCallout from '~/components/blog/BillSurpriseCallout.astro';
import PricingDecisionCard from '~/components/blog/PricingDecisionCard.astro';
Amazon EBS is one of those AWS services with a quietly expensive bill. The per-GB rate looks innocuous — $0.08/GB-month for gp3 storage in us-east-1, as of June 2026 — yet on mature accounts EBS regularly lands in the top three highest-spend services, often outranking the EC2 instances it is attached to. The reason is structural: EBS bills across six independent dimensions, snapshot storage compounds without supervision, and the lifecycle relationship between an EC2 instance and its volumes is the opposite of what most engineers assume.
The post you are reading is the bill story. For the encryption and snapshot-hygiene operational angle, our [EBS encryption and snapshot lifecycle guide](/blog/aws-ebs-encryption-snapshot-hygiene-kms-lifecycle/) covers KMS configuration and DLM policies; for IOPS-sensitive workload economics, run the numbers in our [EBS IOPS cost calculator](/tools/aws-iops-cost-calculator/).
## The Six EBS Billing Dimensions
## Why Deleting an EC2 Instance Never Stops the Volume Bill
The single most expensive EBS misconception: that terminating an EC2 instance terminates its volumes. It doesn't. EBS volumes are independent resources. When you terminate an instance, the attached volume is _detached_, not _deleted_ — unless `DeleteOnTermination=true` was set on the volume's block device mapping at instance-launch time, which it is for the root volume by default but rarely for additional data volumes.
The waste pattern follows from this. A developer launches a dev instance with a 100 GB data volume. The instance gets terminated when the project pauses. The volume remains, detached, billing at $8/month. Multiply by months of accumulation and across dozens of dev environments and the bill quietly climbs.
Audit any account older than 12 months and you will find detached gp3 volumes still billing. The root cause is the
default block device mapping behavior: only root volumes get `DeleteOnTermination=true` by default; data volumes
attached later are independent. Set `DeleteOnTermination=true` on every non-root volume at launch time when the
volume's lifetime is bounded by the instance, and let DLM lifecycle policies retain snapshots for the data you need
beyond the volume's life.
## The Snapshot Bill Compounds Without Supervision
Snapshots are incremental — the bill is on the actual changed blocks across the chain, not on full volume size times snapshot count. That makes the per-snapshot math intuitive (a daily snapshot of a low-churn volume adds maybe 5–10% to the snapshot footprint per day, not 100%). It also makes the cumulative bill misleading because there is no single line item that says "you have 14,000 snapshots."
Three multipliers drive the snapshot bill out of proportion:
1. **AMI snapshots from baked images.** Every AMI is backed by snapshots. Build a new AMI weekly in a CI/CD pipeline and never deregister the old ones, and 18 months later the snapshot count is in four digits.
2. **AWS Backup plans with long retention.** A daily backup plan with 35-day retention multiplies the snapshot count per volume by 35×. Apply this across 200 volumes and you have 7,000 snapshots in steady state.
3. **DLM lifecycle policies created and forgotten.** Data Lifecycle Manager policies are easy to enable and easy to leave running with no archive transition or expiry, especially when the team that created them rotates off the account.
Deregistering an AMI from the EC2 console does not delete its backing snapshots. The snapshots remain billable until
explicitly deleted. The `aws ec2 describe-snapshots --owner-ids self --filters Name=description,Values="Created by
CreateImage*"` query finds AMI-backed snapshots; cross-reference against `aws ec2 describe-images --owners self` to
identify the orphaned set. Automate the cleanup with a Lambda triggered on AMI deregistration.
## The gp2 → gp3 Migration Is the Cleanest 20% Win in Storage
gp3 is unconditionally cheaper than gp2 for most volume shapes. Storage is 20% cheaper ($0.08 vs $0.10 per GB-month) and gp3 includes 3000 IOPS in the base price regardless of volume size, while gp2 bundles IOPS at 3 IOPS per GB. The crossover happens at 1 TB — a 1 TB gp2 volume includes 3000 IOPS by default; a 4 TB gp2 includes 12,000 IOPS. Above 1 TB with high IOPS needs, you have to add gp3 IOPS line items to match.
Run the math for a typical fleet:
The migration mechanism is the AWS-native `ModifyVolume` API or the `modify-volume` CLI command. It is in-place, online, and free. The bottleneck is process — change-management approval on production volumes — not technology. For the migration script and a fleet-wide audit pattern, see our [EBS encryption and snapshot lifecycle guide](/blog/aws-ebs-encryption-snapshot-hygiene-kms-lifecycle/).
## io2 Block Express: Use Only When Sub-Millisecond IOPS Genuinely Matters
io2 Block Express is the high-performance tier — sub-millisecond latency, up to 256K IOPS per volume, durability quoted at 99.999%. The price reflects that. Storage is 56% more expensive than gp3 ($0.125 vs $0.08 per GB-month) and IOPS are billed at a substantially higher rate on a tiered curve ($0.065/IOPS-month for the first 32K, dropping to $0.038 and then $0.027 in higher tiers).
The legitimate use cases are narrow: OLTP databases with strict latency SLAs, mission-critical SAP HANA workloads, regulated financial systems where sub-ms IOPS variance affects trade execution. Everything else — including most "high-performance" application volumes — should be on gp3 with appropriate IOPS provisioned, which is dramatically cheaper for the same IOPS count.
Teams default to io2 for "important" databases out of habit. Most application databases under 1 TB with under 16K IOPS
would run identically on gp3 at a fraction of the price. Move io2 to a workload tier — reserved for explicitly-named
latency-critical systems with documented SLOs — rather than a default for production.
## Fast Snapshot Restore: The Most Expensive Forgotten Feature
Fast Snapshot Restore (FSR) initializes a snapshot in an AZ so the first reads from a restored volume hit warm blocks rather than lazy-loading from S3. The benefit is real for fleet launches where the first-read latency would otherwise impact application warm-up. The price is $0.75 per DSU-hour per snapshot per AZ — about $540/month per snapshot per AZ, or $1,620/month if enabled across three AZs.
The waste pattern: enable FSR on a base AMI snapshot during DR planning, run a single drill, and forget to disable it. Twelve months later that AMI snapshot has cost $19,440. Find every FSR-enabled snapshot with `aws ec2 describe-fast-snapshot-restores --filters Name=state,Values=enabled` and disable any that are not actively being used to launch fleets.
## Snapshot Archive: The Compliance Tier
Snapshot Archive is a 75%-discount tier for snapshots accessed less than once a year. The catch is a 24–72 hour restore time and a per-GB restore fee. The right use case is regulatory retention — financial 7-year holds, HIPAA imaging archives, contract-record compliance — where the snapshot must exist but realistically will never be restored.
The wrong use case is operational backup. If your DR plan requires a restore SLO of even a few hours, Archive is too slow. Keep operational snapshots on the standard tier and apply Archive only to the explicitly-classified retain-but-never-restore set.
## When to Use Each EBS Volume Type
## A 30-Day EBS Cost Cleanup Plan
A focused four-week cleanup typically recovers 15–30% of the EBS line on accounts that have not done one in 12+ months.
**Week 1 — Find orphans.** Run AWS Compute Optimizer for EBS, Trusted Advisor's underutilized-volume check, and Storage Lens for EBS. Build a single list of detached volumes and zero-IOPS volumes with their owners (using cost-allocation tags).
**Week 2 — Snapshot lifecycle.** Audit AWS Backup plans for retention beyond business need. Audit DLM policies for missing archive transitions and expiries. Run the AMI orphan-snapshot query to find snapshots whose AMIs are deregistered. Apply a default 90-day retention policy where none exists.
**Week 3 — gp2 → gp3 migration.** Identify every gp2 volume in the fleet. Group by application owner and run the IOPS math. For volumes under 1 TB, schedule the in-place migration; for volumes above 1 TB, validate IOPS requirements first.
**Week 4 — io2 and FSR review.** Audit every io2 volume against a "documented latency SLO" criterion; downgrade to gp3 with provisioned IOPS where the SLO does not require sub-ms. Audit every Fast Snapshot Restore-enabled snapshot; disable any not actively used for fleet launches.
Cross-reference the numbers with our [EBS IOPS cost calculator](/tools/aws-iops-cost-calculator/) when scoping the gp3 IOPS provisioning for migrations.
## What This Post Doesn't Cover
- **Cross-region snapshot replication pricing** — adds inter-region data transfer plus the destination-region storage rate; treat as a separate budget line.
- **EBS-optimized EC2 instance types** — the EBS-optimized network throughput is included in the instance price, not the EBS price; covered on the EC2 side.
- **Backup vault costs vs raw snapshot costs** — AWS Backup adds a small management overhead per recovery point; covered in a future post.
- **NVMe instance store cost** — instance store is included in EC2 instance pricing and has zero EBS bill, but loses data on instance stop/terminate. Different tradeoff entirely.
## If You Only Do One Thing This Week
Set `DeleteOnTermination=true` on every non-root volume in your launch templates and CloudFormation/CDK templates, and add a "find detached volumes" job to your weekly cost-review. The two changes together prevent the single most common EBS waste pattern — volumes outliving the instance that needed them — and surface the orphans that have already accumulated. Pair with a DLM lifecycle policy that enforces a default 90-day snapshot retention and the EBS line will trend down month over month even without further intervention.
For workloads where IOPS economics matter, validate the gp3 sizing in our [IOPS cost calculator](/tools/aws-iops-cost-calculator/) before committing to migration.
## FAQ
### Why does my EBS bill keep going when the EC2 instance is gone?
Because EBS volumes are independent resources. When you terminate an EC2 instance, the attached EBS volume is detached but not deleted unless DeleteOnTermination=true was set at attach time. The volume continues to bill at the per-GB-month rate (gp3 is $0.08/GB-month in us-east-1) until it is explicitly deleted. Snapshots of that volume continue to bill separately at $0.05/GB-month for the standard tier even after the volume itself is gone. The most common waste pattern: developers terminate dev instances expecting the volume to go with them; weeks later a 24-month cost report reveals dozens of orphaned 100 GB volumes at $8/month each.
### Is gp3 always cheaper than gp2?
For storage alone, yes — $0.08/GB-month vs $0.10/GB-month, a flat 20% saving. The nuance is that gp3 bills IOPS and throughput as separate line items above the included baseline (3000 IOPS and 125 MBps). If your gp2 volume is 1 TB or larger, gp2 includes more than 3000 IOPS in the bundled price (gp2 IOPS scale with volume size at 3 IOPS/GB), so gp3 only beats gp2 when you migrate to a smaller volume size with matched IOPS. For volumes under ~700 GB with normal IOPS needs, gp3 is always cheaper. Above that, run the IOPS math.
### What is fast snapshot restore and why is it so expensive?
Fast Snapshot Restore (FSR) is an opt-in feature that makes a snapshot fully initialized at attach time so the first reads do not hit the lazy-loading penalty. It costs $0.75 per DSU-hour per snapshot per AZ — $540/month per snapshot per AZ. Many teams enable FSR on a base AMI snapshot for disaster recovery purposes and forget about it. A single AMI snapshot enabled in three AZs costs $1,620/month with zero benefit until a DR event. Disable FSR on any snapshot that is not actively being used to launch fleets; the lazy-loading penalty only matters when you need warm-start performance on the first read.
### Are snapshots really 50% of the EBS bill on mature accounts?
Often more. Snapshots accumulate from AMI builds, AWS Backup plans, manual point-in-time snapshots, and DLM lifecycle policies. Without explicit retention enforcement, a workload with a daily AWS Backup plan that keeps snapshots for 35 days will hold roughly 35 incremental snapshots per volume in perpetuity. On accounts with hundreds of volumes, snapshot storage commonly exceeds active volume storage by 2–3×. Recovery Point Lifecycle in AWS Backup and DLM age-out policies are the primary mitigations; both are free to configure and dramatically cut the bill.
### What is the snapshot archive tier and when does it pay off?
Snapshot Archive is a low-cost storage tier at $0.0125/GB-month — 75% cheaper than the standard $0.05/GB-month — for snapshots accessed less than once a year. The catch: archived snapshots take 24–72 hours to restore and incur a per-GB restore fee. Archive is the right tier for compliance-mandated retention (7-year tax records, HIPAA-required imaging) where you must keep the snapshot but realistically will never restore it. It is the wrong tier for operational backups where a restore SLO of even a few hours matters.
### How do I find orphaned EBS volumes without writing a script?
AWS Compute Optimizer for EBS surfaces underutilized and idle volumes from CloudWatch metrics — zero IOPS and zero throughput over a 14-day lookback is the signal. AWS Trusted Advisor has a dedicated underutilized EBS volumes check on Business support and above. Storage Lens for EBS (now in the S3 Storage Lens console) shows aggregate utilization at account and OU level. Between the three, the orphan-detection workflow takes minutes; the harder part is establishing a deletion process that requires snapshot creation before delete and an owner sign-off for production volumes.
### Is multi-attach worth the price?
Multi-attach is a feature on io1 and io2 that lets up to 16 EC2 instances attach the same volume concurrently — useful for shared-disk clustered applications (Oracle RAC, SAP HANA shared-disk patterns). It does not change the per-GB or per-IOPS price; it does require io1/io2, which are 56–67% more expensive than gp3 storage and bill IOPS at a much higher rate. Multi-attach is worth it for the narrow set of workloads that genuinely need shared block storage and cannot be re-architected onto EFS or FSx. Anything that can use a file-system-based shared store should not be paying io2 prices.
---
*Source: https://www.factualminds.com/blog/amazon-ebs-pricing-orphaned-volumes-snapshots/*