Skip to content

EBS Volumes

Amazon Elastic Block Store (EBS) provides block-level volumes that attach to EC2 instances over the network and persist independently of the instance’s life. A volume behaves like a disk: the instance puts a file system on it and owns it.

This section also covers burst capacity and baseline IOPS, Multi-Attach and durability and RAID. Point-in-time copies are covered under snapshots.

  • A volume lives in one Availability Zone and attaches to instances in that same zone. EBS gives no multi-AZ redundancy of its own; snapshots are the mechanism for crossing zones and Regions.
  • Volumes persist independently of the instance. They can be detached from one instance and attached to another.
  • Size, volume type, IOPS and throughput can all be changed on a running volume using Elastic Volumes, without detaching it. Changing type from gp2 to gp3 is the common case.
  • Encryption at rest uses AWS KMS. Encryption is set at creation and cannot be toggled on an existing volume — see Encrypting an existing volume below.
  • Point-in-time snapshots are stored in Amazon S3 and are incremental after the first one.
  • Only Provisioned IOPS volumes (io1 and io2) can be attached to more than one instance at a time.
  • EBS backs EC2 and is also used by managed services built on EC2, such as Amazon RDS. It is not the storage layer for every AWS service: Amazon Redshift, for instance, uses its own cluster storage.
Featuresc1st1gp2gp3io1io2 Block Express
MediaHDDHDDSSDSSDSSDSSD
Use caseInfrequently accessed, throughput-oriented dataBig data, warehouses, log processingTransactional workloads, boot volumesTransactional workloads, boot volumes, broad rangeSustained IOPS above 16,000Sub-millisecond latency, above 80,000 IOPS or 2,000 MiB/s
Volume size125 GiB – 16 TiB125 GiB – 16 TiB1 GiB – 16 TiB1 GiB – 64 TiB4 GiB – 16 TiB4 GiB – 64 TiB
Max IOPS per volume25050016,00080,00064,000256,000
Max throughput per volume250 MiB/s500 MiB/s250 MiB/s2,000 MiB/s1,000 MiB/s4,000 MiB/s
Baseline12 IOPS per TiB40 IOPS per TiB3 IOPS/GiB, minimum 1003,000 IOPS and 125 MiB/s includedProvisionedProvisioned
BurstingYes, throughput creditsYes, throughput creditsYes, to 3,000 IOPSNo — sustains provisioned performance indefinitelyNoNo
Durability99.8–99.9%99.8–99.9%99.8–99.9%99.8–99.9%99.8–99.9%99.999%
Multi-AttachNoNoNoNoYesYes
Boot volumeNoNoYesYesYesYes

Two notes on the table. Maximum IOPS on gp3 and io2 Block Express requires an instance built on the Nitro System; other instance types can attach volumes provisioned up to 64,000 IOPS but reach around 32,000. AWS now documents io2 only in its Block Express form. A previous-generation standard magnetic volume type also still exists, delivering roughly 100 IOPS, and should not be used for new work.

gp3 is the current general-purpose volume and the default choice for most workloads, including boot volumes. Its distinguishing property is that performance is provisioned separately from capacity: a small volume can be fast.

  • 3,000 IOPS and 125 MiB/s are included in the price of storage, at any volume size.
  • Additional IOPS can be provisioned up to 80,000, at a ratio of 500 IOPS per GiB of volume size — so the maximum needs a volume of at least 160 GiB.
  • Additional throughput can be provisioned up to 2,000 MiB/s, at 0.25 MiB/s per provisioned IOPS — so the maximum needs at least 8,000 IOPS and 16 GiB.
  • gp3 does not use burst credits. It sustains its provisioned performance indefinitely.
  • Priced around 20 percent lower per GiB than gp2.
  • On AWS Outposts, gp3 is capped at 16 TiB, 16,000 IOPS and 1,000 MiB/s.

gp2 — previous-generation General Purpose SSD

Section titled “gp2 — previous-generation General Purpose SSD”

gp2 ties performance to capacity, which is why gp3 replaced it. Baseline IOPS scale at 3 IOPS per GiB between a floor of 100 and a ceiling of 16,000, so a 300 GiB volume gets 900 IOPS and the maximum is only reached at 5,334 GiB. Volumes smaller than 1 TiB can burst to 3,000 IOPS on accrued credits. Throughput runs between 128 MiB/s and 250 MiB/s depending on size, reaching the maximum at 334 GiB.

Existing gp2 volumes can be migrated to gp3 in place with an Elastic Volumes modification.

io1 and io2 Block Express — Provisioned IOPS SSD

Section titled “io1 and io2 Block Express — Provisioned IOPS SSD”

Provisioned IOPS volumes decouple IOPS from capacity entirely: the required IOPS are specified and billed, whether or not they are used.

  • io1 supports up to 64,000 IOPS and 1,000 MiB/s, on volumes of 4 GiB to 16 TiB, with the same 99.8–99.9% durability as general-purpose volumes. Reaching 1,000 MiB/s requires 64,000 provisioned IOPS on a Nitro-based instance.
  • io2 Block Express supports up to 256,000 IOPS and 4,000 MiB/s, on volumes of 4 GiB to 64 TiB, and is designed for 99.999% durability and average latency under 500 microseconds for 16 KiB operations. It also supports NVMe reservations, which io1 does not.

AWS recommends io2 over io1 for better performance, consistency and durability at a lower price. io1 remains for existing deployments.

gp3 covers the great majority of production workloads and costs less, because only the performance actually needed is bought on top of a free baseline. Provisioned IOPS earns its price in three situations: sustained demand above 80,000 IOPS or 2,000 MiB/s per volume, a requirement for consistently sub-millisecond latency, or a durability requirement that justifies io2’s 99.999% design target. Multi-Attach is also exclusive to io1 and io2.

Designed for large, sequential, throughput-heavy workloads: big data, data warehouses, log processing, ETL. Baseline throughput is 40 MiB/s per TiB with bursts to 250 MiB/s per TiB, capped at 500 MiB/s and 500 IOPS per volume. Minimum size 125 GiB. Cannot be a boot volume.

The lowest-cost EBS volume, for data accessed infrequently where cost matters more than speed. Baseline throughput is 12 MiB/s per TiB with bursts to 80 MiB/s per TiB, capped at 250 MiB/s and 250 IOPS per volume. Minimum size 125 GiB. Cannot be a boot volume.

Both HDD types measure IOPS at a 1 MiB I/O size, which is why their IOPS figures look small next to SSD volumes measured at 16 KiB: they are built for streaming, not for small random reads.

Encryption cannot be enabled on a volume that already exists. The path from an unencrypted root volume to an encrypted one runs through a snapshot:

  1. Create a snapshot of the unencrypted volume.
  2. Copy the snapshot, selecting the encryption option and a KMS key.
  3. Create an AMI from the encrypted snapshot.
  4. Launch new instances from that AMI.

Snapshots inherit the encryption status of their source, so an encrypted volume always yields an encrypted snapshot, and a volume restored from an encrypted snapshot is always encrypted.