Types of EBS in AWS and How to Choose the Right One

Summary:

• AWS offers six current-generation EBS volume types across two main categories, plus a legacy magnetic option. SSD-backed types include gp3, gp2, io2, and io1. HDD-backed types include st1 and sc1. Notably, io2 Block Express is no longer a separate volume type; rather, it is the underlying high-performance architecture automatically used for io2 volumes on compatible Nitro instances. Each type is optimized for specific performance and cost profiles.
• Choosing the right volume type depends on four critical factors. These are IOPS requirements, throughput needs, latency sensitivity, and cost constraints. The gp3 type serves as the default choice for most workloads because it uniquely decouples performance from capacity, guaranteeing a baseline of 3,000 IOPS and 125 MB/s regardless of volume size. For mission-critical databases requiring sub-millisecond latency, io2 volumes running on the Block Express architecture deliver the highest performance.
• Instance type compatibility directly impacts achievable EBS performance. This is particularly true for Nitro-based EC2 instances. Architecture decisions become inseparable from storage selection.
• Elastic Volumes feature allows live modifications to EBS types and sizes without downtime. While this enables iterative optimization as workload patterns evolve, architects must account for a strict 6-hour cooldown period between modifications on the same volume.

Every millisecond of storage latency translates directly into user experience degradation. Every dollar spent on over-provisioned IOPS represents budget that could fund actual innovation. AWS Elastic Block Store presents engineers with seven volume types, each engineered for distinct performance envelopes and cost structures.

Understanding the types of EBS in AWS is not merely about memorizing specifications. It requires mapping technical capabilities to workload characteristics while anticipating how those workloads will evolve. This guide dissects each AWS EBS volume type with the depth required for production architecture decisions and the strategic framing necessary for System Design interviews.

Overview of AWS EBS volume categories

AWS organizes EBS volumes into three fundamental categories based on underlying storage technology and generation status. SSD-backed volumes deliver the low-latency, high-IOPS performance required for transactional workloads and boot volumes. HDD-backed volumes optimize for sequential throughput at lower cost, serving big data and log processing scenarios.

Previous generation volumes, specifically the magnetic type, exist primarily for legacy compatibility and should be avoided for new deployments. This categorization reflects the physical characteristics of storage media. SSDs excel at random access patterns while HDDs perform best with large, sequential operations.

The distinction between volume categories extends beyond raw performance into durability guarantees and pricing models. SSD volumes charge based on provisioned capacity and, for io-family volumes, provisioned IOPS. HDD volumes charge purely on capacity with throughput determined by volume size.

Understanding these pricing mechanics prevents the common mistake of provisioning expensive io2 volumes for workloads that would perform identically on gp3 at a fraction of the cost. Consider the following breakdown of how each category serves different architectural needs.

SSD-backed volumes for transactional workloads

SSD-backed volumes encompass five distinct types. General Purpose SSD volumes (gp3 and gp2) balance performance and cost for the majority of workloads. Provisioned IOPS SSD volumes (io2 Block Express, io2, io1) guarantee consistent performance for latency-sensitive applications.

The evolution from io1 to io2 to io2 Block Express represents AWS’s continuous improvement in durability and maximum performance ceilings. All SSD volumes support boot operations, making them suitable for root volumes on EC2 instances.

HDD-backed volumes for throughput-intensive workloads

HDD-backed volumes include Throughput Optimized HDD (st1) and Cold HDD (sc1), both designed for sequential access patterns rather than random IOPS. These volumes cannot serve as boot volumes, a critical constraint when architecting systems.

The st1 type targets frequently accessed, throughput-intensive workloads like data warehouses and log processing. The sc1 type optimizes for infrequently accessed data where cost minimization takes priority over access speed. Both types scale throughput with volume size, creating a direct relationship between capacity provisioning and performance.

General purpose SSD comparing gp3 and gp2

The gp3 volume type represents AWS’s current recommendation for general purpose storage. It decouples IOPS and throughput provisioning from volume size. This architectural change from gp2 enables precise cost optimization. You provision exactly the performance you need rather than over-provisioning capacity to achieve target IOPS. A 100 GiB gp3 volume can deliver 16,000 IOPS and 1,000 MiB/s throughput. Matching this performance would require a 5,334 GiB gp2 volume through its size-based scaling model.

The gp2 volume type uses a burst credit system where baseline performance scales at 3 IOPS per GiB. Volumes under 1,000 GiB can burst to 3,000 IOPS. This model creates unpredictable performance for workloads that exhaust burst credits, a failure mode that has caused countless production incidents.

Volumes larger than 1,000 GiB maintain consistent performance but at significantly higher cost than equivalent gp3 configurations. Migration from gp2 to gp3 requires no downtime through elastic volume modification, making the transition operationally straightforward.

The cost implications of choosing between gp3 and gp2 compound significantly at scale. A 500 GiB gp2 volume provides 1,500 baseline IOPS with burst capability. A 500 GiB gp3 volume delivers 3,000 baseline IOPS at approximately 20% lower cost. For organizations running hundreds of volumes, this difference translates into substantial monthly savings without performance compromise.

Provisioned IOPS SSD including io2 Block Express, io2, and io1

Provisioned IOPS volumes guarantee consistent performance for workloads where latency variability is unacceptable. The io2 Block Express type represents the highest performance tier available in EBS. It delivers up to 256,000 IOPS and 4,000 MiB/s throughput with sub-millisecond latency.

This performance level requires Nitro-based EC2 instances and specific instance families, creating an architectural dependency that must be planned during System Design. The io2 standard type offers up to 64,000 IOPS for instances that cannot leverage Block Express capabilities.

Durability differentiates io2 volumes from all other EBS types. Both io2 and io2 Block Express deliver 99.999% durability, compared to 99.8-99.9% for gp3 and io1. This five-nines durability means annual failure rates drop from approximately 0.1-0.2% to 0.001%. This is a meaningful difference for databases where volume failure triggers complex recovery procedures. The io1 type, while still available, offers only 99.8-99.9% durability and should be considered deprecated for new deployments.

Multi-attach capability for shared storage

The io1 and io2 volume families support multi-attach, enabling a single volume to connect to up to 16 Nitro-based instances simultaneously. This capability supports clustered applications requiring shared block storage, though it demands careful application-level coordination to prevent data corruption.

Multi-attach volumes must use a cluster-aware file system or implement application-level locking. The feature is unavailable on gp3, gp2, and HDD volumes, making provisioned IOPS the only option for shared block storage architectures.

Instance type requirements for maximum performance

Achieving maximum io2 Block Express performance requires specific EC2 instance configurations. Only Nitro-based instances support EBS optimization levels necessary for 256,000 IOPS and 4,000 MiB/s throughput. Instance families including R5b, R6i, M6i, C6i, and newer generations provide the EBS bandwidth required to saturate Block Express volumes.

Older instance types, even when Nitro-based, may bottleneck at the instance level rather than the volume level. Always verify instance EBS specifications in the AWS documentation before architecting high-performance storage configurations.

The relationship between instance type and achievable EBS performance creates a critical design consideration. A c5.xlarge instance supports maximum EBS throughput of 593.75 MiB/s. Even a perfectly configured io2 Block Express volume would be constrained to this limit. Matching instance EBS bandwidth to volume capabilities prevents paying for performance that cannot be delivered.

HDD volumes including st1 and sc1 for sequential workloads

Throughput Optimized HDD (st1) volumes target workloads characterized by large, sequential I/O operations. Data warehouses, log processing pipelines, and streaming workloads benefit from st1’s throughput-optimized design. The volume type delivers up to 500 MiB/s throughput, scaling with volume size at 40 MiB/s per TiB. A 10 TiB st1 volume provides 400 MiB/s baseline throughput with burst capability to 500 MiB/s. This makes it cost-effective for big data workloads that would be prohibitively expensive on SSD storage.

Cold HDD (sc1) volumes optimize for infrequently accessed data where storage cost dominates performance requirements. The sc1 type delivers up to 250 MiB/s throughput at the lowest per-GiB cost of any EBS volume type. Archival data, disaster recovery volumes, and cold tier storage benefit from sc1’s economics. Throughput scales at 12 MiB/s per TiB, meaning large volumes are required to achieve meaningful performance. Neither st1 nor sc1 supports boot operations, restricting their use to data volumes only.

• st1 ideal workloads: Apache Kafka log segments, Hadoop HDFS data nodes, data warehouse fact tables, video transcoding scratch space
• sc1 ideal workloads: Backup repositories, compliance archives, disaster recovery volumes, infrequently accessed reference data
• Avoid HDD for: Databases requiring random access, boot volumes, any workload with IOPS requirements exceeding 500

Previous generation magnetic volumes

Magnetic volumes, formerly called “standard” volumes, represent the original EBS offering and exist solely for backward compatibility. These volumes deliver approximately 100 IOPS on average with significant variability, making them unsuitable for any workload with consistent performance requirements. AWS does not recommend magnetic volumes for new deployments, and they are unavailable in newer AWS regions. Organizations still running magnetic volumes should prioritize migration to gp3, which offers superior performance at comparable or lower cost.

The migration path from magnetic to modern volume types is straightforward using elastic volume modification. This operation changes the volume type without requiring detachment or instance downtime, though performance characteristics change immediately upon modification completion. For volumes containing critical data, creating a snapshot before modification provides a rollback path if unexpected issues arise. The cost savings from eliminating magnetic volumes typically justify the minimal operational effort required for migration.

How to choose the right EBS type for your workload

Selecting the optimal EBS volume type requires analyzing four dimensions. These are IOPS requirements, throughput needs, latency sensitivity, and cost constraints. Most workloads should start with gp3 as the default choice, adjusting only when specific requirements (like needing more than 80,000 IOPS or Multi-Attach capabilities) exceed its capabilities. The decision framework below maps common workload patterns to appropriate volume types, providing a starting point for architecture decisions that can be refined through production monitoring.

Database workloads

Relational databases like PostgreSQL, MySQL, and Oracle require careful volume selection based on transaction rates and latency requirements. Production OLTP databases typically need io2 or io2 Block Express to guarantee consistent sub-millisecond latency during peak loads. Development and staging environments often perform adequately on gp3, reducing costs while maintaining functional parity.

The critical metric is P99 latency under load. If gp3’s single-digit millisecond latency causes unacceptable tail latencies, upgrading to io2 Block Express eliminates storage as a bottleneck.

Boot volumes and general compute

Boot volumes require SSD storage, eliminating HDD options from consideration. The gp3 type serves as the optimal choice for most boot volumes, providing sufficient IOPS for operating system operations at minimal cost. Provisioned IOPS volumes for boot storage are rarely justified unless the instance runs latency-critical applications that load from disk during operation. A 30 GiB gp3 boot volume with default 3,000 IOPS handles operating system requirements for virtually any workload pattern.

Big data and analytics

Big data workloads exhibit sequential access patterns that align with HDD volume characteristics. Hadoop data nodes, Spark shuffle storage, and Kafka log segments benefit from st1’s throughput optimization. The key consideration is whether the workload is truly sequential. Mixed random and sequential patterns perform poorly on HDD and should use gp3 instead. For cost-sensitive analytics clusters processing large datasets, st1 can reduce storage costs by 50-70% compared to gp3 while delivering equivalent throughput for sequential operations.

Real-world performance and cost comparison

The following table presents benchmark data for a typical database workload requiring 10,000 IOPS with 500 GiB storage. It compares viable volume configurations across performance and cost dimensions. This analysis demonstrates how volume selection impacts both operational characteristics and monthly expenditure.

Volume modification and migration strategies

AWS elastic volume modification enables changing volume type, size, IOPS, and throughput without detaching the volume or stopping the instance. This capability supports iterative optimization. Start with gp3, monitor actual utilization, and adjust based on observed patterns. Modifications enter a transitional state during which the volume operates at the lower of old and new performance levels. For production databases, schedule modifications during low-traffic periods to minimize impact.

Migration from older volume types follows a consistent pattern regardless of source and target types:

1. Capture baseline performance metrics using CloudWatch for comparison after migration
2. Create a snapshot as a rollback mechanism before initiating modification
3. Initiate volume modification through the console, CLI, or infrastructure-as-code
4. Monitor modification progress and volume state until completion
5. Validate performance meets expectations and update monitoring thresholds

Conclusion

Mastering the types of EBS in AWS requires understanding both the technical specifications and the economic trade-offs that drive production architecture decisions. The gp3 volume type serves as the correct default for most workloads. It offers predictable performance at reasonable cost with the flexibility to scale IOPS and throughput independently. Provisioned IOPS volumes, particularly io2 Block Express, address the narrow but critical use case of latency-sensitive databases where sub-millisecond response times justify premium pricing. HDD volumes remain relevant for throughput-oriented workloads where sequential access patterns align with their design optimization.

The ability to modify volumes without downtime transforms EBS selection from a high-stakes initial decision into an iterative optimization process. Start with gp3, instrument thoroughly with CloudWatch metrics, and adjust based on observed utilization patterns. This approach minimizes both over-provisioning waste and under-provisioning risk. As AWS continues evolving EBS capabilities, particularly around io2 Block Express performance ceilings and durability guarantees, the fundamental selection framework remains constant. Match volume characteristics to workload requirements while maintaining cost discipline.

Storage architecture decisions ripple through System Design interviews and production incidents alike. Engineers who understand what each volume type offers and why those characteristics matter for specific workloads demonstrate the architectural thinking that distinguishes senior practitioners from those who simply memorize specifications.