Amazon EBS Pricing: Why Deleted EC2 Instances Never Stop the Volume Bill

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.

Amazon EBS pricing bills storage, provisioned IOPS/throughput, snapshots, and Fast Snapshot Restore independently. In us-east-1 (June 2026), gp3 storage is $0.08/GB-month and standard snapshots are $0.05/GB-month. Most surprises come from detached volumes and snapshot chains that outlive the EC2 instances that created them.

The post you are reading is the bill story. For the encryption and snapshot-hygiene operational angle, our EBS encryption and snapshot lifecycle guide covers KMS configuration and DLM policies; for IOPS-sensitive workload economics, run the numbers in our EBS IOPS cost calculator.

How Does Amazon EBS Pricing Work? Six Billing Dimensions

If you only audit one dimension first, start with detached gp3 volumes — they bill indefinitely after instance termination.

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.

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.

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.

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.

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).

New — June 18, 2026: Compute Optimizer’s EBS recommendations now factor IOPS- and throughput-exceeded signals (free CloudWatch metrics, Nitro-based instances only), so Week 1 surfaces both idle volumes and volumes silently throttled by under-provisioned IOPS/throughput — the two cost-and-performance failure modes in one pass.

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 when scoping the gp3 IOPS provisioning for migrations.

More in This Series

Part of the AWS Service Pricing series (June 2026).

• Previous: Part 1
• Next: Part 3
• Browse all: Cost Optimization & FinOps category
• FinOps pillar: FinOps shift-left: cost feedback in the pull request

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 before committing to migration.

Frequently asked questions