Visual overview
SSD families emphasize IOPS/latency; HDD families emphasize sequential throughput.
Technical reference
EBS type follows workload I/O pattern: SSD and HDD families optimize different behavior.
General SSD for broad workloads with configurable performance characteristics.
For I/O-intensive, latency-sensitive workloads requiring provisioned IOPS.
For large, sequential, frequently accessed throughput workloads.
For large, sequential, infrequently accessed data at lower cost.
Performance starts with the I/O pattern
EBS volume types are grouped around different storage performance and cost profiles. SSD-backed volumes are designed for transactional workloads where IOPS and small or random I/O matter. HDD-backed volumes are designed for throughput-oriented workloads that process large sequential streams. Choosing between them begins with the workload's I/O pattern rather than with total capacity alone.
General Purpose SSD volumes such as gp3 are the normal starting point for a wide range of applications. Provisioned IOPS SSD options such as io2 target workloads that require more demanding or consistent IOPS characteristics. Throughput Optimized HDD (st1) is suited to frequently accessed, throughput-intensive sequential workloads, while Cold HDD (sc1) targets less frequently accessed sequential data where lower storage cost matters more than IOPS.
Why gp3 is different from simply buying a larger disk
Modern EBS design separates storage capacity from performance more deliberately than traditional disk thinking. With gp3, performance can be provisioned independently within supported limits, which means a workload should not be oversized in gigabytes merely to obtain more I/O performance. This improves both cost reasoning and right-sizing because capacity and performance can be tuned as different requirements.
Provisioned IOPS volumes are appropriate when the application has stronger performance or durability requirements than general-purpose storage is designed to provide. HDD-backed volumes trade random-I/O capability for economical sequential throughput. Root volumes and transactional databases are therefore usually SSD-oriented, while large sequential processing workloads can be candidates for HDD options when the application characteristics permit them.
Snapshots separate backup from the live volume
A snapshot captures a point-in-time state of an EBS volume and is managed independently from the original volume. Snapshots are incremental at the storage level after the first snapshot, but each snapshot can be used as the basis for restoring a complete new volume. This lets backup retention continue even if the original volume is later modified or deleted.
A recovery plan should distinguish high availability from backup. A snapshot is excellent for restoring data to a previous point in time, but restoration is not the same as keeping an application continuously available during a failure. Multi-AZ application architectures, database replication and automated recovery mechanisms address availability, while snapshots and AWS Backup address recoverability and retention.
Key takeaways
- 01
SSD-backed EBS targets transactional I/O; HDD-backed EBS targets large sequential throughput patterns.
- 02
gp3 is a strong general-purpose default and lets capacity and supported performance dimensions be considered separately.
- 03
io-class volumes fit more demanding IOPS requirements; st1/sc1 fit appropriate sequential-throughput workloads.
- 04
Snapshots provide point-in-time recovery but do not by themselves create application high availability.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.