EBS pricing: what to model (storage, performance, snapshots)

Use this page when you need to decide what belongs inside the EBS bill before you debate gp3 sizing, snapshot retention, or cleanup actions.

This guide is the EBS bill-boundary page: live volume GB-month, provisioned performance charges when applicable, and retained snapshot storage should be modeled as separate cost surfaces rather than blended into one storage number.

Start here: separate the EBS bill surfaces

• Live volume charges: provisioned GB-month for active volumes by type.
• Performance charges: gp3 or provisioned IOPS and throughput add-ons when they apply.
• Retained snapshot storage: backup storage accumulated from churn, retention, and copies.

EBS pricing inputs

• GB-month: average storage per volume class.
• IOPS/throughput: gp3/io1/io2 performance add-ons.
• Snapshots: GB-month from backup retention.

1) Volume storage (GB-month)

• Count provisioned volume size by class (e.g. 20 GB roots, 500 GB data, 2 TB databases).
• Multiply by your region $/GB-month per volume type.
• For fleets, model 3–5 volume classes rather than a single average (databases behave differently from roots).

2) Provisioned performance (only when it applies)

Some volume types allow (or require) you to provision IOPS and/or throughput. If you set those above baseline, it is a separate cost driver.

• IOPS: provisioned IOPS above baseline (or dedicated IOPS volume types).
• Throughput: provisioned MB/s above baseline (not relevant for every type).
• Common mistake: sizing to a single peak event. Use p95 and add a small buffer.

If you need to turn workload metrics into a defendable configuration, continue with gp3 IOPS and throughput sizing. For type-selection trade-offs, compare gp2 vs gp3.

3) Snapshots (separate storage line item)

• Snapshot storage grows with change rate and retention, not just volume size.
• Copies across regions or accounts create additional stored GB.
• Long retention on write-heavy volumes is the common “silent” snapshot cost driver.

If snapshot growth is the unclear part of the budget, go to the EBS snapshot cost guide next.

A fast estimation workflow

1. Group volumes into 3–5 classes (type + size + workload).
2. For each class: estimate GB-month and (if applicable) IOPS/throughput settings.
3. For snapshots: estimate change rate and retention window per class.
4. Validate against a real week of utilization and a real month of snapshot retention behavior.

Once the dominant driver is credible, use EBS cost optimization for production cleanup and right-sizing actions.

Common pitfalls

• Keeping unattached volumes after migrations and instance termination.
• Over-sizing volume GB to chase performance instead of tuning IOPS/throughput (or switching to gp3).
• Snapshot retention without lifecycle policies (daily snapshots kept forever).
• Non-prod volumes with prod-sized disks and prod retention policies.

Validation checklist

• Measure used space and growth rate per volume class (baseline + busy month).
• Measure p95 IOPS/throughput and verify it matches provisioned settings.
• Measure snapshot retained GB trend and confirm lifecycle policies actually delete.
• After changes, validate latency and error rates for the workload (not only IOPS).

Treat this guide as an EBS bill-boundary workflow: separate live volume GB-month, paid performance, and retained snapshot storage before you accept one rolled-up storage total.

Sources

• EBS pricing: aws.amazon.com/ebs/pricing
• EBS volume types: docs.aws.amazon.com

Related guides

FAQ