‘Just use EBS’ is where the easy part ends and the real decision begins, because EBS is not one disk — it is a family of six volume types whose prices and performance differ by more than an order of magnitude. Pick the wrong member and you either overpay for performance a workload never touches, or you starve a database on a volume built for streaming log files. This piece is the companion to the general EBS overview, and it stays deliberately narrow: not what EBS is, but which type to reach for and why. We walk the two media families and the IOPS-versus-throughput mental model that separates them, then every type in turn — gp3, gp2, io1, io2, io2 Block Express, st1, and sc1 — before pulling it together with a full comparison table, the cost model per type, and a decision framework that turns a workload’s shape into a single recommended volume type.
Two families: SSD for IOPS, HDD for throughput
The whole EBS type family splits cleanly in two, and every selection decision starts by choosing the right side. SSD-backed volumes — gp3, gp2, io1, io2 — are IOPS-optimized: they are built to service a large number of small, random read and write operations per second, which is what transactional databases, boot volumes, and virtually anything doing scattered small I/O actually need. HDD-backed volumes — st1 and sc1 — are throughput-optimized: they are built to stream large, sequential blocks of data cheaply, which is what a log-processing pipeline or a big-data scan needs, and they are genuinely poor at random small I/O.
The mental model that makes this stick is IOPS versus throughput. IOPS counts operations; throughput counts bytes. A workload that issues thousands of tiny 4 KB lookups is IOPS-bound — it lives or dies on how many distinct operations the volume can complete per second, and it wants SSD. A workload that reads one enormous file front to back is throughput-bound — it wants the most megabytes per second per dollar, and an HDD delivers that far more cheaply than SSD. Ask ‘is this workload counting operations or counting bytes?’ and you have already narrowed six types down to two or three. Everything below is the detail inside those two camps.
gp3: the modern default
gp3 is the answer for the overwhelming majority of volumes, and its defining feature is decoupling. Every gp3 volume ships with a free baseline of 3,000 IOPS and 125 MB/s included at no charge beyond the per-gigabyte storage price — and that baseline is the same whether the volume is 10 GB or 10 TB. Above the baseline you provision IOPS (up to 16,000) and throughput (up to 1,000 MB/s) independently, and independently of capacity. Size, IOPS, and throughput are three separate dials priced separately, so you buy exactly the performance you need without buying storage you don’t.
The practical consequence is that a huge fraction of real workloads never leave the baseline: their performance line item is literally zero and they pay only for gigabytes. When a workload does need more, you turn one dial. Need 8,000 IOPS on a 100 GB volume? On gp3 you provision 8,000 IOPS on a 100 GB volume and stop — the capacity and the performance are no longer welded together. That single property is why gp3 is cheaper, more precise, and the default recommendation for boot volumes, application disks, and most databases alike.
gp2: the legacy general-purpose type
gp2 was the old general-purpose default, and understanding its one flaw explains why gp3 exists. On gp2, performance was welded to capacity: you got 3 IOPS per gigabyte, so the only way to get more IOPS was to make the volume bigger. Want 9,000 IOPS? You had to provision a 3,000 GB volume — three terabytes — and pay for all of it, whether or not you needed the space. Performance and size were a single dial.
Worse, small gp2 volumes ran on a burst-bucket model. A volume under 1,000 GB had a low sustained baseline (3 IOPS/GB) but could burst to 3,000 IOPS by drawing down accumulated I/O credits. A load test would look great for a few minutes, then fall off a cliff the moment the credits ran out and performance collapsed to the baseline. gp3 has no burst cliff: its provisioned performance is flat and sustained. Between gp3 being roughly 20% cheaper per gigabyte, having a higher free baseline, and dropping the size-coupling and the burst bucket entirely, gp3 supersedes gp2 in essentially every dimension — migrating existing gp2 volumes to gp3 almost always comes out cheaper, faster, or both.
io1 and io2: provisioned IOPS for demanding workloads
When a workload needs high, sustained, predictable IOPS beyond what the general-purpose tier guarantees, you move to the provisioned-IOPS SSD types. io1 was the original: you provision a specific IOPS number and AWS guarantees the volume delivers it consistently, which is what latency-sensitive relational databases and large transactional systems want — not an average, but a floor.
io2 is the modern replacement and improves io1 on two axes at the same list price. First, durability: a standard gp3 or io1 volume is quoted around 99.8%–99.9% annual durability, while io2 is engineered for 99.999% — five nines, two extra orders of magnitude — which for a fleet of mission-critical database volumes meaningfully reduces expected annual data-loss events. Second, a higher IOPS-to-GB ratio: io2 lets you provision up to 500 IOPS per gigabyte (versus io1’s 50:1), so you can extract very high IOPS from a modestly sized volume without inflating capacity just to unlock performance. For any new provisioned-IOPS volume there is essentially no reason to choose io1 over io2.
io2 Block Express: the highest-performance tier
io2 Block Express is the top of the family — io2 running on a next-generation storage architecture that lifts the ceilings far above everything else. A single Block Express volume reaches up to 256,000 IOPS and 4,000 MB/s of throughput, scales to 64 TiB, and delivers sub-millisecond latency. This is the tier you reach for when replacing an on-premises SAN, or when a demanding relational database has genuinely outgrown gp3’s 16,000-IOPS cap and needs a hard performance floor with the five-nines durability io2 already provides.
Block Express also unlocks Multi-Attach: a single io2 volume can attach to multiple EC2 instances in the same Availability Zone at once. This is not a shortcut to a shared filesystem — the volume presents as a raw block device to every attached instance simultaneously, and without a cluster-aware filesystem or application that coordinates and fences writes (think clustered databases with their own locking), concurrent writers will corrupt the data. Multi-Attach is a primitive for building high-availability clustered software, not a way to make one disk behave like network file storage. If you want a shared filesystem, you want EFS.
st1: throughput-optimized HDD
Crossing over to the HDD family, st1 is the throughput-optimized hard-disk type: cheap per gigabyte and built to stream large, sequential reads and writes. Its natural home is big, scan-heavy, sequential workloads — big-data processing, log and streaming pipelines, data warehouses, and ETL jobs that march through data front to back rather than jumping around it.
Like small gp2 volumes, st1 uses a burst-credit model, but on throughput rather than IOPS: performance scales with volume size, with a baseline throughput per terabyte and the ability to burst higher by spending accumulated credits. Because the underlying media is spinning disk, st1 is excellent value per streamed megabyte but poor at random, small I/O — every random seek costs a physical head movement, so a database or boot volume on st1 would crawl. The rule is simple: st1 is for workloads whose access pattern is large and sequential and whose priority is cost per byte, never for anything latency-sensitive or random.
sc1: cold HDD, the cheapest tier
sc1 — ‘cold HDD’ — is the cheapest EBS type, and it exists for one job: data on a block device that is accessed infrequently. It shares st1’s spinning-disk media and sequential strengths but is tuned lower still, with a smaller baseline throughput and burst allowance per terabyte, in exchange for the lowest per-gigabyte price in the family.
Use sc1 when you need the data on a block volume — so object storage in S3 is not a fit — but the workload touches it only occasionally: colder logs, large backups staged on a block device, or infrequently scanned archives. The trade-off is stark: sc1 delivers the least performance of any type, so anything with regular access, random I/O, or latency sensitivity belongs elsewhere. Think of st1 and sc1 as ‘warm bulk’ and ‘cold bulk’ respectively — two rungs of cheap sequential storage where you trade performance for the lowest possible cost per gigabyte.
All six types, side by side
With every type described, the comparison is easiest to hold as a single table. Read it as a shortlist generator: fix the family from the access pattern, then pick the row that meets the performance floor at the lowest price tier.
| Type | Media | Best for | IOPS ceiling | Throughput ceiling | Latency | Durability | Price tier |
|---|---|---|---|---|---|---|---|
| gp3 | SSD | Default general purpose | 16,000 | 1,000 MB/s | single-digit ms | ~99.8–99.9% | Low |
| gp2 | SSD | Legacy general purpose | 16,000 (burst) | 250 MB/s | single-digit ms | ~99.8–99.9% | Low-mid |
| io1 | SSD | Sustained provisioned IOPS | 64,000 | 1,000 MB/s | single-digit ms | ~99.8–99.9% | High |
| io2 | SSD | High IOPS + durability | 64,000 | 1,000 MB/s | sub-ms to low ms | 99.999% | High |
| io2 Block Express | SSD | Extreme IOPS, SAN replacement | 256,000 | 4,000 MB/s | sub-ms | 99.999% | Highest |
| st1 | HDD | Big sequential throughput | ~500 | 500 MB/s | high (seek-bound) | ~99.8–99.9% | Very low |
| sc1 | HDD | Cold, infrequent bulk | ~250 | 250 MB/s | high (seek-bound) | ~99.8–99.9% | Lowest |
The shape of the table is the lesson: the SSD rows compete on IOPS and latency and climb steeply in price toward io2 Block Express, while the two HDD rows sit far below on both performance and cost. There is no single ‘best’ type — only the cheapest type that clears your workload’s actual performance floor.
Reading a workload: IOPS vs throughput vs latency
Choosing a type well means reading a workload against three different metrics, because ‘fast’ is not one number. IOPS is how many distinct operations per second the volume services — the metric that dominates for random, small I/O like a database doing thousands of index lookups. Throughput is how many bytes per second move — the metric that dominates for large, sequential I/O like a table scan or a log stream. Latency is how long a single operation takes to return — the metric that dominates when a user is blocked on one query.
These relate roughly as throughput ≈ IOPS × I/O size, which is exactly why the type families divide the way they do. A workload of 4 KB operations needs a lot of IOPS to reach high throughput — that is SSD territory, and gp3/io2 give you the IOPS dial. A workload of 1 MB operations reaches high throughput with very few operations — that is HDD territory, where st1’s cheap sequential megabytes win. Latency, meanwhile, is set mostly by media: SSD answers in single-digit milliseconds (io2 Block Express in sub-millisecond), while HDD pays a physical seek on every random access. Diagnosing which of the three is your real constraint tells you the family, and the required ceiling tells you the row.
The cost model, per type
The types price on different axes, and the recurring theme is that you pay for provisioned capacity, not consumed capacity. On the SSD side, gp3 separates the bill: storage per gigabyte-month, then IOPS and throughput billed only above the free 3,000 IOPS / 125 MB/s baseline, so a workload inside the baseline pays for gigabytes alone. gp2 bundles a fixed 3 IOPS/GB into a single slightly higher per-gigabyte price — you cannot buy IOPS without buying GB, which is precisely what makes it more expensive for IOPS-hungry, space-light workloads. io1 and io2 charge a premium per gigabyte plus a separate, and significant, charge per provisioned IOPS — and that IOPS charge bills whether or not the workload ever drives those operations, so over-provisioning io2 is one of the more expensive mistakes available.
On the HDD side the model is simpler and cheaper: st1 and sc1 bill essentially per gigabyte-month, with performance derived from size rather than separately provisioned, and sc1 sitting at the lowest per-gigabyte price of any type. The consistent trap across all of them is idle headroom: empty gigabytes bill, unused provisioned IOPS bill, and provisioned throughput you never saturate bills. The disciplined pattern — especially since Elastic Volumes lets you grow and retype live — is to provision lean for what you know today and scale up when the metrics actually demand it, rather than pre-buying a ceiling on the priciest tier.
A decision framework: workload shape to volume type
Put together, type selection reduces to a short series of honest questions about the workload’s shape, each of which points cleanly at a type:
| Workload shape | Recommended type |
|---|---|
| General-purpose, random small I/O, inside 3,000 IOPS / 125 MB/s | gp3 at baseline — performance is free |
| General-purpose but needs 3,000–16,000 IOPS or extra throughput | gp3 with IOPS/throughput dialed up |
| Sustained, guaranteed IOPS above 16,000, latency-sensitive DB | io2 (provisioned IOPS + five-nines durability) |
| Extreme IOPS/throughput, SAN replacement, >64,000 IOPS | io2 Block Express |
| One disk shared by a cluster-aware app in a single AZ | io2 Multi-Attach (shared files → EFS instead) |
| Big, sequential, throughput-bound (big data, logs, ETL) | st1 |
| Infrequently accessed bulk on a block device, cost is king | sc1 |
| Still on gp2 for any of the above SSD cases | Migrate to gp3 — cheaper, faster, or both |
Read top to bottom, the framework lands on the same unglamorous default for most systems: gp3, provisioned lean, with io2 and io2 Block Express reserved for the genuinely demanding or mission-critical cases, and the HDD pair kept for cheap sequential bulk. The discipline is to size to the workload’s real access pattern and performance floor, not to a gut-feeling ceiling — and to remember that on EBS you can change your mind live if the metrics later prove you wrong.