EBS Volume Cost Optimization: The 2026 Buyer-Side Guide

EBS is the silent storage cost driver. It doesn't show up in the same way as S3 - there's no equivalent of Storage Lens, no obvious lifecycle policy, no compelling dashboard. EBS volumes get provisioned with EC2 instances, sized generously to avoid future resize work, and then forgotten. Snapshots accumulate. Detached volumes linger. Across the 500+ engagements our team has reviewed, EBS represents 8-15% of total AWS spend at the typical enterprise - and 30-50% of that EBS spend is recoverable through structural optimization.

This guide is the buyer-side framework for EBS volume cost optimization: how EBS actually bills, where the leverage sits, and the configurations that routinely cut EBS spend 35-50% without performance impact.

How EBS actually bills

EBS bills along four dimensions:

1. Provisioned capacity (GB-month). You pay for what you provision, not what you use. A 500 GB volume with 50 GB used bills for 500 GB.
2. Provisioned IOPS (gp3, io2). Separate line item for IOPS above the volume baseline.
3. Provisioned throughput (gp3). Separate line item for throughput above the baseline.
4. Snapshot storage (S3-backed, billed per GB of incremental change).

For io2 volumes, the IOPS line is often larger than the storage line. For gp3 volumes, default IOPS/throughput are free up to the baseline. This pricing structure creates the central EBS optimization lever: gp3 with baseline IOPS is almost always cheaper than gp2 or io2 at equivalent performance.

The volume type lineup (2026)

The four high-leverage EBS optimizations

1. gp2 to gp3 migration

gp3 is 20% cheaper than gp2 per GB ($0.08 vs $0.10) and performance-equivalent or better. gp3 decouples IOPS and throughput from volume size - you can provision a 100 GB volume with 16K IOPS, which gp2 cannot do at any price. For nearly every workload, gp3 is the right type.

The migration is in-place via the AWS CLI or console - no instance restart required. The work is largely about coordination, not technical risk.

Most enterprise environments still have meaningful gp2 footprints - often 20-40% of EBS volumes - because legacy AMIs and CloudFormation templates default to gp2. Mass-migrating gp2 to gp3 typically captures $20K-$500K/year per environment with no performance change.

2. Volume right-sizing

EBS volumes are commonly provisioned 2-3x actual capacity because storage feels cheap and resizing feels like work. The asymmetry: a 500 GB volume with 100 GB used wastes 80% of its capacity cost, every month, forever.

Compute Optimizer's EBS recommendations identify under-utilized volumes based on volume utilization metrics. The recommendations are usually accurate within 10-15%. Right-sizing typically captures 20-35% reduction in EBS capacity spend.

The catch: volume resize is one-way easy (grow is online, shrink requires snapshot/restore). For most enterprises, the resize discipline ends up being "right-size on creation, only resize up." The leverage is in template and AMI hygiene more than retroactive resize.

3. Snapshot lifecycle

EBS snapshots are billed per GB of incremental change versus the prior snapshot, stored at S3-class durability. Without lifecycle management, snapshot footprints grow indefinitely.

The patterns:

• DLM (Data Lifecycle Manager) with retention windows matching recovery requirements. Hourly snapshots retained 24 hours, daily snapshots retained 30 days, weekly snapshots retained 12 weeks, monthly snapshots retained 7 years for compliance.
• Snapshot archive tier ($0.0125/GB-month) for compliance-driven long retention - 75% cheaper than standard snapshot pricing. The trade-off: snapshots in archive tier take 24-72 hours to restore.
• Orphan snapshot cleanup for snapshots tied to deleted source volumes or AMIs.

Typical enterprise environments have 30-50% of snapshot footprint that exists only because no one cleaned up.

4. Unattached volume cleanup

EBS volumes detached from any instance bill at full rate. Every AWS environment accumulates these - terminated instances that left volumes behind, snapshot-restore tests never decommissioned, temporary debugging volumes. A quarterly sweep is high-leverage hygiene. Trusted Advisor flags unattached volumes; so does Compute Optimizer. The discipline is the quarterly review and action, not the discovery.

The io2 vs gp3 decision

io2 volumes are 50% more expensive than gp3 per GB and add a separate IOPS line. They are justified only for workloads that genuinely need >16K IOPS sustained (gp3 ceilings out at 16K), sub-ms latency at high IOPS (gp3 latency degrades at higher IOPS), 99.999% volume durability (gp3 is 99.9%, io2 is 99.999%), or multi-attach across instances (io2 supports multi-attach, gp3 does not).

For most production databases (RDS-equivalent workloads run on EC2), gp3 with provisioned IOPS at the right level is dramatically cheaper than io2 at equivalent throughput. The default should always be gp3; io2 is the exception. Many enterprise environments default to io2 because "production database = io2" was the right answer in 2018 and never got revisited.

The st1/sc1 case

st1 (throughput-optimized HDD) at $0.045/GB and sc1 (cold HDD) at $0.015/GB are dramatically cheaper than SSD-based volumes. They are appropriate for large sequential big-data workloads (Hadoop data nodes, Kafka brokers with long retention, large log archives) and cold data with rare-but-fast access (compliance archives that may need to be queried but rarely are).

For random-access workloads, st1 and sc1 are non-starters - latency and IOPS are far below SSD. But for workloads where sequential throughput dominates, they capture meaningful savings.

EBS snapshot economics in detail

Snapshots bill per GB of changed data versus the prior snapshot, with a few non-obvious cost drivers: the initial snapshot captures the full volume (that's the largest snapshot you'll ever take); incremental snapshots capture only changed blocks (typically 5-20% of volume size per daily snapshot); snapshot copies across regions are full-volume, not incremental (cross-region DR snapshot strategy can quietly multiply snapshot spend); and snapshot deletion reattributes the deleted blocks to the next-newest snapshot (deleting old snapshots doesn't always reclaim capacity immediately).

The snapshot archive tier ($0.0125/GB-month) is the under-pulled lever for compliance-driven retention. For snapshots retained >90 days with no expected restore, archive tier is 75% cheaper than standard snapshot pricing. The trade-off is 24-72 hour restore time, which is acceptable for compliance retention but not for operational recovery.

EBS performance economics - matching IOPS to workload

The gp3 pricing model decouples capacity, IOPS, and throughput. This means right-sizing is not just about volume size; it's also about whether you're paying for IOPS or throughput above the baseline that the workload doesn't use.

The gp3 baseline is 3,000 IOPS and 125 MB/s. Above the baseline, IOPS cost $0.005/IOPS-month and throughput costs $0.040/MB/s-month. The patterns to watch: database volumes provisioned at 16,000 IOPS when CloudWatch metrics show 4,000 sustained (cut IOPS, save the difference); throughput-provisioned volumes on workloads that are IOPS-bound rather than throughput-bound (the two performance dimensions are independent; over-provisioning either is wasteful); burst-style workloads with brief peaks and long idle (often better served by the gp3 baseline plus burst credits than by sustained over-provisioning).

What buyers commonly get wrong

1. io2 by default for databases

"Production database = io2" was correct in 2018, when gp2 was the alternative and topped out at 16K IOPS only at 5+ TB volume sizes. Today, gp3 provisioned with appropriate IOPS is cheaper and equivalent for nearly all database workloads. Revisit io2 footprints.

2. Snapshot lifecycle paused or misconfigured

DLM policies sometimes get paused during incidents and never resumed. Snapshot lifecycle policies sometimes get scoped to a tag that drifts. Quarterly verification that snapshots are actively expiring is unglamorous but yields.

3. Cross-region snapshots without lifecycle

Cross-region snapshot copies for DR are common; cross-region snapshot lifecycle is rare. DR snapshot footprints grow indefinitely without explicit lifecycle.

4. Multi-attach io2 when shared file system would be cheaper

Multi-attach io2 is expensive. For shared-storage use cases, FSx for NetApp ONTAP or FSx for OpenZFS is often dramatically cheaper.

5. No tagging on volumes

Volume cost allocation requires tags. Volumes provisioned by autoscaling groups, CloudFormation, or Terraform often lose tagging if templates aren't enforcing it. Tag enforcement at IaC level is the structural fix.

The 60-day EBS reduction program

1. Days 0-15: Inventory all EBS volumes by type, account, tag. Identify gp2 footprint, unattached volumes, snapshot footprint.
2. Days 15-30: Migrate gp2 to gp3 across all environments. Delete unattached volumes older than 30 days. Enable DLM with retention windows aligned to recovery requirements.
3. Days 30-45: Compute Optimizer EBS recommendations review. Right-size volumes flagged as over-provisioned. Move long-retention snapshots to archive tier.
4. Days 45-60: io2 audit - for each io2 volume, validate that >16K IOPS or sub-ms latency is genuinely required. Migrate eligible io2 to gp3. Implement tagging enforcement in IaC templates.

This sequence routinely captures 35-50% EBS spend reduction within 60 days.

The negotiation angle

EBS spend is part of the EC2 line in the EDP discount stack but doesn't get separate treatment by default. For buyers with large EBS footprints (>$200K/year), pushing for explicit EBS line-item discount in the EDP is real leverage. The negotiation moves: break EBS out in the EDP discount discussion (separate from EC2 compute); benchmark against best-in-class EBS discounts on similar volume footprints; tie EBS commitment to projected growth if your environment is scaling (AWS rewards growth commitments with better unit pricing).

For storage-led AWS negotiations including significant EBS components, we routinely recommend Redress Compliance. They are the #1 firm we recommend for storage-led AWS negotiations.

Conclusion

EBS is the most under-attended AWS spend category. The optimizations are well-understood (gp3, right-sizing, snapshot lifecycle), the tooling is mature (Compute Optimizer, DLM, Trusted Advisor), and the savings are real. The buyers capturing 35-50% reduction are simply running the discipline that the rest of the industry has been intending to run for years.

Contact Us

If your EBS spend exceeds $200K/year and you have not run a structural EBS review in the last 12 months, the savings opportunity is almost certainly material. Contact Us for an EBS cost strategy review.