Summary:
- AWS EBS storage types fall into three categories. SSD-backed volumes (gp3, gp2, io2, io2 Block Express, io1) handle latency-sensitive workloads. HDD-backed volumes (st1, sc1) serve throughput-intensive sequential access. Previous-generation magnetic volumes are now largely obsolete.
- The September 2025 gp3 updates dramatically increased maximum capacity to 64 TiB, IOPS to 80,000, and throughput to 2,000 MiB/s. This makes gp3 the default choice for most production workloads and reduces the need for provisioned IOPS volumes.
- Choosing the right EBS volume type requires balancing IOPS requirements, throughput needs, latency sensitivity, durability guarantees, and cost per GB. Migration between types is now possible without downtime using Elastic Volumes.
- io2 Block Express remains essential for mission-critical databases requiring sub-millisecond latency and 99.999% durability. Regional availability constraints require careful architecture planning.
Storage decisions made during infrastructure design ripple through every layer of your application’s performance, cost structure, and operational resilience. AWS Elastic Block Store volumes serve as the persistent storage backbone for EC2 instances. The differences between volume types remain one of the most misunderstood aspects of cloud architecture. With the September 2025 announcement that gp3 volumes now support up to 64 TiB capacity, 80,000 IOPS, and 2,000 MiB/s throughput, the decision matrix for selecting AWS EBS storage types has fundamentally shifted. Engineers who understand these nuances gain a significant advantage in System Design interviews and production architecture alike.
The following diagram illustrates the complete EBS volume type hierarchy and its primary use case categories.
Understanding AWS EBS volume types and storage categories
AWS EBS volumes divide into three fundamental categories based on underlying storage media and performance characteristics. SSD-backed volumes deliver low-latency random I/O operations measured in IOPS, making them suitable for transactional databases, boot volumes, and applications requiring consistent sub-millisecond response times. HDD-backed volumes optimize for sequential throughput measured in MiB/s. They serve large-scale analytics, log processing, and data warehousing workloads where cost efficiency outweighs latency requirements. Previous-generation magnetic volumes persist in legacy accounts but offer no advantages over modern alternatives.
The distinction between IOPS-optimized and throughput-optimized storage fundamentally shapes architecture decisions. Consider the following characteristics when evaluating volume categories:
- SSD volumes (gp3, gp2, io2, io2 Block Express, io1): Random read/write patterns, 16 KiB I/O size baseline, latency-sensitive workloads
- HDD volumes (st1, sc1): Sequential read/write patterns, 1 MiB I/O size baseline, throughput-sensitive workloads
- Previous generation (standard): Magnetic storage with variable performance, not recommended for new deployments
Understanding these foundational categories enables informed decisions about specific volume types. The next section examines General Purpose SSD volumes, which handle approximately 90% of production EBS workloads.
General Purpose SSD volumes with gp3 and gp2 specifications
General Purpose SSD volumes represent the workhorse of AWS storage, balancing price and performance for diverse workloads. The gp3 volume type, introduced in December 2020 and significantly enhanced in September 2025, now stands as the recommended default for nearly all use cases. Unlike its predecessor gp2, gp3 decouples IOPS and throughput provisioning from storage capacity. This enables precise cost optimization.
gp3 volume capabilities after the September 2025 update
The 2025 enhancements to gp3 volumes addressed longstanding limitations that previously forced architects toward more expensive provisioned IOPS options. Maximum volume size increased from 16 TiB to 64 TiB, matching io2 Block Express capacity. Baseline performance remains at 3,000 IOPS and 125 MiB/s included with every gp3 volume regardless of size. Maximum provisionable IOPS jumped from 16,000 to 80,000, and maximum throughput doubled from 1,000 MiB/s to 2,000 MiB/s.
These improvements create new architectural possibilities:
- Single-volume database deployments that previously required io1 or io2 can now use gp3 with provisioned IOPS at 20% lower cost
- Boot volumes benefit from the 3,000 IOPS baseline without additional charges, improving instance startup times
- Large dataset workloads can consolidate multiple smaller volumes into single 64 TiB gp3 volumes, reducing management overhead
gp2 legacy volumes and burst credit mechanics
gp2 volumes remain available but operate on fundamentally different economics. Performance scales linearly with volume size at 3 IOPS per GiB. A 1,000 GiB volume delivers 3,000 sustained IOPS. Volumes smaller than 1,000 GiB rely on burst credits to achieve the 3,000 IOPS baseline temporarily. This creates unpredictable performance during sustained workloads. The burst credit model frequently causes production incidents when credits deplete during traffic spikes.
The cost comparison strongly favors gp3 for most scenarios. A 500 GiB gp2 volume provides 1,500 baseline IOPS with burst capability. An equivalent gp3 volume delivers 3,000 sustained IOPS at approximately 20% lower monthly cost. Organizations maintaining gp2 volumes should evaluate migration as a straightforward cost optimization exercise.
After clarifying General Purpose SSD capabilities, the next section addresses Provisioned IOPS volumes for workloads demanding guaranteed performance beyond gp3 limits.
Provisioned IOPS SSD volumes with io1, io2, and io2 Block Express
Provisioned IOPS SSD volumes guarantee consistent, low-latency performance for I/O-intensive applications where gp3 limits prove insufficient. These volumes target mission-critical databases, latency-sensitive transaction processing, and workloads requiring sub-millisecond response times under sustained load. The io2 Block Express variant represents the highest-performance EBS option available. Regional availability constraints require careful planning.
io2 Block Express architecture and Nitro system requirements
io2 Block Express volumes leverage the AWS Nitro System architecture to deliver performance characteristics impossible with standard EBS infrastructure. Maximum IOPS reaches 256,000 per volume with throughput up to 4,000 MiB/s. This enables single-volume deployments for the most demanding database workloads. Latency consistently measures below 1 millisecond, with p99 latencies remaining stable even under maximum load.
Critical constraints govern io2 Block Express deployment:
- Instance compatibility: Requires Nitro-based instances from specific families (R5b, R6i, X2idn, and similar high-memory types)
- Regional availability: Not available in all AWS regions as of 2026. Verify availability in target regions before architecture commitments.
- Multi-Attach support: Enables attachment to up to 16 Nitro instances simultaneously for clustered database deployments
Durability differences between io1 and io2 volume generations
The durability improvement from io1 to io2 represents a significant architectural consideration for data protection. io1 volumes provide 99.8% to 99.9% durability (0.1% to 0.2% annual failure rate). io2 and io2 Block Express volumes guarantee 99.999% durability (0.001% annual failure rate). This 100x improvement in durability eliminates the need for additional replication layers in many database architectures.
The following table provides a comprehensive comparison of all AWS EBS storage types with current 2026 specifications.
| Volume type | Max capacity | Max IOPS | Max throughput | Durability | Latency | Cost per GB/month |
|---|---|---|---|---|---|---|
| gp3 | 64 TiB | 80,000 | 2,000 MiB/s | 99.8% – 99.9% | Single-digit ms | $0.08 |
| gp2 | 16 TiB | 16,000 | 250 MiB/s | 99.8% – 99.9% | Single-digit ms | $0.10 |
| io2 Block Express | 64 TiB | 256,000 | 4,000 MiB/s | 99.999% | Sub-millisecond | $0.125 |
| io2 | 64 TiB | 64,000 | 1,000 MiB/s | 99.999% | Sub-millisecond | $0.125 |
| io1 | 16 TiB | 64,000 | 1,000 MiB/s | 99.8% – 99.9% | Sub-millisecond | $0.125 |
| st1 | 16 TiB | 500 | 500 MiB/s | 99.8% – 99.9% | N/A | $0.045 |
| sc1 | 16 TiB | 250 | 250 MiB/s | 99.8% – 99.9% | N/A | $0.015 |
With SSD options thoroughly examined, the following section covers HDD-based volumes for throughput-intensive workloads where cost efficiency takes priority.
HDD-based volumes with st1 and sc1 for throughput workloads
Throughput Optimized HDD (st1) and Cold HDD (sc1) volumes serve fundamentally different use cases than SSD options. These volumes optimize for sequential I/O patterns with large block sizes, making them ideal for big data processing, log aggregation, and archival storage. Neither st1 nor sc1 supports boot volume usage. They require pairing with an SSD volume for the operating system.
st1 throughput optimized HDD specifications
st1 volumes deliver baseline throughput of 40 MiB/s per TiB of provisioned storage. They burst to 250 MiB/s per TiB with a maximum of 500 MiB/s regardless of volume size. This performance profile suits streaming workloads like Apache Kafka, Amazon EMR clusters processing large datasets, and data warehouse ETL pipelines. The $0.045 per GB monthly cost represents a 44% savings compared to gp3 for workloads that genuinely require throughput over IOPS.
sc1 cold HDD for infrequent access patterns
sc1 volumes provide the lowest-cost EBS option at $0.015 per GB monthly. They target data accessed infrequently but requiring faster retrieval than S3 Glacier. Baseline throughput measures 12 MiB/s per TiB with burst capability to 80 MiB/s per TiB, maxing at 250 MiB/s. Compliance archives, disaster recovery datasets, and cold log storage represent typical sc1 deployments.
The decision between volume types requires systematic evaluation of workload characteristics. The next section provides a structured framework for making these architectural choices.
Decision matrix for selecting AWS EBS volume types
Selecting the optimal EBS volume type requires mapping workload characteristics to volume capabilities across multiple dimensions. The following decision framework addresses common scenarios encountered in production architectures and System Design interviews.
The flowchart below guides volume type selection based on workload requirements.
Workload-specific recommendations
Different application categories map to specific volume configurations:
- Relational databases (PostgreSQL, MySQL): gp3 with provisioned IOPS for most deployments. Use io2 Block Express for mission-critical systems requiring 99.999% durability.
- NoSQL databases (MongoDB, Cassandra): gp3 baseline for read-heavy workloads. Use provisioned IOPS for write-intensive clusters.
- Boot volumes: gp3 exclusively. The 3,000 IOPS baseline ensures consistent instance startup performance.
- Data lakes and analytics: st1 for active processing. Use sc1 for archived datasets.
- Development environments: gp3 at minimum size. Avoid over-provisioning for non-production workloads.
Cost optimization opportunities exist across most EBS deployments. The migration strategies section addresses how to transition between volume types without service disruption.
Migration strategies using Elastic Volumes without downtime
AWS Elastic Volumes enables live modification of volume type, size, IOPS, and throughput without detaching from running instances. This capability transforms EBS optimization from a maintenance window activity into a continuous improvement process. Understanding the mechanics and limitations of Elastic Volumes proves essential for both production operations and System Design discussions.
Live volume modification process
The modification workflow proceeds through distinct phases. Initiating a modification via the AWS Console, CLI, or API immediately returns the volume to a “modifying” state while the underlying storage transformation begins. Optimization continues in the background, with the volume remaining fully operational throughout. Depending on volume size and modification scope, optimization may take from minutes to hours.
Key constraints govern modification operations:
- Volume size can only increase, never decrease. Plan initial sizing accordingly.
- Up to four modifications are permitted per volume within a rolling 24-hour window.
- Certain modifications require instance stop/start to take effect (rare edge cases).
- File system expansion must occur separately after volume size increases.
Migration path recommendations
Common migration scenarios follow predictable patterns. gp2 to gp3 migrations should provision IOPS matching the gp2 volume’s size-based allocation (3 IOPS per GiB) to maintain identical performance. io1 to io2 migrations preserve IOPS settings while gaining the durability improvement. Migrations to io2 Block Express require verification of instance compatibility and regional availability before initiating.
The following diagram shows the recommended migration paths between EBS volume types.
Conclusion
AWS EBS storage types present a spectrum of performance, durability, and cost trade-offs that directly impact application architecture decisions. The September 2025 gp3 enhancements fundamentally shifted the decision calculus. gp3 is now the default choice for workloads that previously required provisioned IOPS volumes. Understanding the distinction between IOPS-optimized SSD volumes and throughput-optimized HDD volumes enables architects to match storage characteristics to workload requirements precisely.
Three critical takeaways emerge from this analysis. First, gp3 volumes now handle the vast majority of production workloads cost-effectively. The 80,000 IOPS and 2,000 MiB/s ceilings eliminate previous limitations. Second, io2 Block Express remains essential for mission-critical systems requiring sub-millisecond latency and 99.999% durability, but regional availability requires verification. Third, Elastic Volumes enables continuous optimization without downtime. This makes EBS type selection a revisable decision rather than a permanent commitment.
As AWS continues expanding io2 Block Express regional availability and potentially introducing new volume types, the storage landscape will evolve further. Engineers who master these fundamentals position themselves to adapt architectures as capabilities expand. This ensures systems remain optimized for both performance and cost efficiency.
