Choosing an EBS volume type: gp3, io2, st1, sc1

Published February 10, 2026

Every EBS volume is block storage attached to an EC2 instance, and every volume type does the same basic job: it stores bytes and serves reads and writes. What differs is how AWS prices performance. Some types bill you for IOPS and throughput above a free baseline. Some bake performance into the size of the volume. Some don’t offer performance guarantees at all and charge a fraction of the price for it.

Picking wrong doesn’t break anything: a database will run on sc1, and a log archive will run on io2. It just means paying for headroom you don’t use, or hitting a ceiling you didn’t expect. This guide works through what each type is for, what it actually costs using our live pricing data, and where the crossover points are.

The six types AWS sells today

Prices below are on-demand, us-east-1, per our storage pricing pages; check your own region there since rates shift a few cents per GB across geographies.

General Purpose SSD: gp3 over gp2

gp3 replaced gp2 as the AWS default in 2020, and the pricing tells you why. gp2 ties IOPS to volume size: 3 IOPS per GB, capped at 16,000, which means a 100 GB gp2 volume is stuck at 300 IOPS no matter what your workload needs. gp3 decouples the two: every volume gets 3,000 IOPS and 125 MiB/s free regardless of size, and you pay separately if you need more.

Two things stack in gp3’s favor: it’s 20% cheaper per gigabyte, and it separates capacity from performance instead of forcing you to overprovision size just to get IOPS. A 50 GB gp2 volume only gets 150 IOPS; the same workload on gp3 gets 3,000 IOPS for free at a fifth of the price. There’s no scenario where gp2 wins on cost. Its only remaining use is a volume nobody has gotten around to migrating. AWS’s migration tool does it live, without downtime, so there’s rarely a reason to wait.

Provisioned IOPS: what io2 actually buys you

io2’s pitch is performance guarantees, not a better price on IOPS. Every IOPS on io2 is billed, with no free tier:

At every IOPS level gp3 can reach, it’s cheaper, by a factor of 6 to 10x at the same 500 GB size. gp3’s extra-IOPS rate is $0.005/IOPS-month; io2’s tier-1 rate is $0.065/IOPS-month, thirteen times higher. There’s no crossover point where io2 becomes the cheaper way to buy raw IOPS, because AWS doesn’t price it that way.

io2 exists for two reasons, and neither is about hitting a price target:

You need more than 16,000 IOPS. That’s gp3’s hard ceiling. io2 scales to 256,000 IOPS on a single volume (with io2 Block Express), with volume-level tiered pricing that gets cheaper per IOPS as you go up: $0.0650/IOPS-month up to 32,000, $0.0455 from 32,000-64,000, $0.03185 beyond that. If your workload genuinely needs 50,000+ sustained IOPS, there’s no gp3 alternative; the comparison above stops applying and it’s just what io2 costs.

You need the durability and consistency SLA. io2 is rated for 99.999% durability (gp3 and gp2 are 99.8-99.9%) and guarantees sub-millisecond latency with IOPS delivered consistently 99.9% of the time. gp3 is fast in practice but doesn’t carry that guarantee. For a primary transactional database where a missed IOPS target or an unplanned volume failure means an incident, that guarantee is worth paying for even at 6x the per-IOPS cost. For a read replica, a staging database, or anything with redundancy elsewhere in the architecture, it usually isn’t.

Provision on gp3 up to its ceiling, and only reach for io2 when you’ve actually hit that ceiling or when a specific SLA requires it, not because “provisioned IOPS” sounds like the premium option for a database.

Throughput HDD: st1 and sc1 for sequential, non-latency-sensitive data

st1 and sc1 are magnetic, priced purely on GB-month with no IOPS to buy, and built for large sequential reads and writes rather than random access: a different volume shape from SSD, not just a slower one. Neither supports being a boot volume, and both have a 125 GiB minimum size.

At 10 TB, the storage bill alone shows the spread:

That’s a 5.3x range for the same 10 terabytes, and none of it involves buying extra IOPS or throughput; st1 and sc1 don’t let you. What you get is proportional to size: a bigger st1 volume gets more baseline throughput, the same way gp2’s IOPS scaled with size.

st1 fits: Kafka brokers, Hadoop/EMR intermediate storage, log processing pipelines, large ETL staging, anything that streams through gigabytes sequentially and doesn’t do random seeks.

sc1 fits: cold backups, infrequently accessed archives, data you’re keeping around for compliance rather than active use. It’s the cheapest EBS storage that still gives you block-device semantics (as opposed to S3, which is usually cheaper still for pure archival but isn’t a mountable volume).

Neither is a database volume. Random I/O on an HDD-backed type falls off fast because the underlying media has to seek, and the IOPS ceiling (500 and 250) will throttle a transactional workload long before the throughput numbers look like the problem.

The instance side of the equation

A provisioned volume can only deliver what the attached instance can move. Every EC2 instance has its own EBS bandwidth ceiling; check yours on the instance detail pages. Current xlarge-size general-purpose instances (m7i.xlarge, m7g.xlarge, c7g.xlarge, r7g.xlarge) cap out around 40,000 IOPS and 1,250 MB/s of EBS-optimized bandwidth. Provisioning a 50,000-IOPS io2 volume behind one of those instances leaves roughly 10,000 IOPS unreachable; you’d be paying io2 rates for capacity the instance can’t use. If you’re sizing for a high-IOPS workload, check the instance’s ceiling before you check the volume’s, and use the comparison tool if you’re deciding between instance sizes that might change it.

How to decide

1. Is it a boot volume, or does it need random-access IOPS at all? If yes, that rules out st1 and sc1 immediately: start from gp3.
2. Does the workload need more than 16,000 IOPS, or a 99.999% durability / sub-millisecond latency SLA? If yes, use io2. If no, gp3 covers it for a fraction of the price.
3. Is the access pattern large and sequential (streaming, batch, log ingestion)? st1 is usually cheaper than gp3 for the same job and was built for exactly this.
4. Is the data cold (backups, archives, rarely-read history)? sc1, or S3 if you don’t need block-device access at all.
5. Still on gp2 or io1? Migrate to gp3 or io2. Same API, live resize with no downtime, and gp3 is a flat 20% cheaper than gp2 with better-decoupled performance.
6. Check the instance’s EBS bandwidth ceiling on the instance detail pages before provisioning IOPS or throughput beyond what the instance can actually deliver.

Making the call

Default to gp3. It’s cheaper than gp2 per gigabyte, its 3,000 free IOPS and 125 MiB/s cover the large majority of application and database workloads, and its extra-IOPS pricing beats io2 at every level it can reach. Start here unless something specific rules it out.

Move to io2 only for a specific reason. Either the workload needs more than 16,000 IOPS (gp3’s hard ceiling), or the durability/latency guarantee matters enough to justify roughly 6 to 10x the per-IOPS cost. “It’s a database” isn’t that reason by itself; a lot of databases run fine on gp3.

Use st1/sc1 for sequential and cold data, never for random access. These volumes are 30-80% cheaper than gp3 for large, throughput-bound or infrequently-touched workloads, but their IOPS ceilings (500 and 250) make them a poor fit for anything transactional.

Retire gp2 and io1 when convenient. There’s no cost or performance case for staying on the previous generation; migration is live and free.

Bottom line: the price differences between EBS types aren’t marketing tiers, they’re real 5-10x swings for the same gigabyte depending on access pattern. Match the type to how the data is actually read and written, check gp3’s free baseline before paying for anything extra, and reach for io2 or the HDD tiers only when the workload’s shape calls for it, not its label.