Every EC2 instance that keeps data across stops uses Amazon Elastic Block Store (EBS), a network-attached disk that lives in one Availability Zone. EBS offers several volume types, and choosing the wrong one either wastes money or leaves your database starved for I/O. Here is how they differ and how to choose.
Two families: SSD and HDD
| Type | Media | Performance model | Best for |
|---|---|---|---|
| gp3 | SSD | Baseline 3,000 IOPS and 125 MiB/s included; buy more independently | Boot volumes, most apps and databases |
| gp2 | SSD | 3 IOPS per GB, burst credits for small volumes | Legacy; migrate to gp3 |
| io2 Block Express | SSD | Provisioned IOPS with very high limits and higher durability | Critical databases needing consistent low latency |
| io1 | SSD | Provisioned IOPS (older generation) | Legacy; prefer io2 |
| st1 | HDD | Throughput-optimized, burstable | Big sequential reads: logs, data processing |
| sc1 | HDD | Cold, lowest cost | Infrequently accessed large datasets |
HDD types cannot be boot volumes and perform poorly on small random I/O, so they suit streaming workloads only.
Why gp3 replaced gp2 as the default
With gp2, performance is tied to size: 3 IOPS per GB, with a minimum of 100. A 100 GB volume gets 300 IOPS and relies on a burst bucket to reach 3,000 for short periods. When the bucket empties, the volume drops to its baseline and your database suddenly slows down. Teams often over-provisioned gp2 capacity just to get IOPS.
gp3 decouples performance from size. Every gp3 volume gets 3,000 IOPS and 125 MiB/s as a baseline regardless of size, and you can provision more IOPS and throughput independently. It is also cheaper per GB than gp2. For almost every workload, gp3 is cheaper and more predictable.
Migrating gp2 to gp3 without downtime
EBS Elastic Volumes lets you change the type, size, IOPS and throughput of an attached volume while it stays in use:
aws ec2 modify-volume --volume-id vol-0abc123 --volume-type gp3 \
--iops 3000 --throughput 125The volume moves through modifying → optimizing → completed; performance during optimization is at least the old level. Two rules: you can modify a given volume again only after a waiting period (six hours), and growing a volume does not grow the file system. After increasing size, extend the partition and file system inside the OS (growpart and resize2fs or xfs_growfs on Linux).
When io2 is worth it
Choose io2 Block Express when you need sustained IOPS beyond what gp3 offers, sub-millisecond latency consistency for critical databases, or higher durability. It costs more for both storage and provisioned IOPS, so measure first: many databases that "need io" run fine on gp3 with extra provisioned IOPS.
Instance limits matter too
A volume can only go as fast as the instance lets it. Each instance type has a maximum EBS bandwidth and IOPS. Attaching a high-performance volume to a small instance wastes money. Use EBS-optimized instance types (the default for current generations) and check the instance's EBS limits in the documentation.
Snapshots and backups
- Snapshots are incremental, point-in-time copies stored in S3 (managed by EBS). The first snapshot copies all used blocks; later ones copy only changes.
- Automate them with Amazon Data Lifecycle Manager or AWS Backup, and set retention so old snapshots are deleted.
- Copy snapshots to another Region for disaster recovery.
- Orphaned snapshots and unattached volumes are classic hidden costs; review them regularly.
Encryption
Turn on EBS encryption by default for each Region in your account. Encryption uses KMS keys, has no measurable performance cost on current instances, and encrypts data at rest, snapshots and data moving between the instance and the volume.
Practice it
The lab EBS Operations: gp2 to gp3, Online Resize and Automated Snapshots walks through a live migration, a file system resize and snapshot automation in a real account. For encryption, see KMS-Encrypted App Stack.
FAQ
Is EBS replicated?
Yes, within its Availability Zone. It does not survive the loss of the whole AZ; use snapshots (stored regionally) or replicate data at the application level for that.
Can I attach one EBS volume to several instances?
Only io1 and io2 support Multi-Attach, within one AZ, and the application must coordinate writes. For shared file access, use Amazon EFS instead.
What is the difference between EBS and instance store?
Instance store is a physical disk on the host: very fast but erased when the instance stops or fails. EBS persists independently of the instance.