Amazon EBS Volume Design and Operations - Selection Criteria for gp3 and io2 with Snapshot Strategies
Clarify the selection criteria for gp3 and io2 volume types, and learn practical IOPS/throughput design guidelines along with snapshot-based backup strategies.
EBS Volume Type Selection Criteria
EBS offers four categories: General Purpose SSD (gp3 / gp2), Provisioned IOPS SSD (io2 / io2 Block Express and the previous-generation io1), Throughput Optimized HDD (st1), and Cold HDD (sc1). The starting point for selection is gp3. gp3 provides a baseline of 3,000 IOPS and 125 MiB/s at no additional charge, and can scale independently up to a maximum of 80,000 IOPS and 2,000 MiB/s as needed (as of August 2026). However, there are conditions for raising it all the way to the maximum. Additional IOPS can be provisioned at a ratio of 500 IOPS per 1 GiB of volume size, and the maximum of 80,000 IOPS requires a volume size of at least 160 GiB. Additional throughput can be provisioned at a ratio of 0.25 MiB/s per 1 IOPS of provisioned IOPS, and the maximum of 2,000 MiB/s requires at least 8,000 IOPS (a volume size of at least 16 GiB). If you still have design guidelines that list 16,000 IOPS and 1,000 MiB/s as the gp3 limits, there is room to revisit them against the current limits. With gp2, IOPS scales in proportion to volume size, so increasing IOPS meant making the volume larger, but gp3 has removed this constraint. io2 Block Express is intended for database workloads and delivers up to 256,000 IOPS per volume. io2 / io2 Block Express offers a design durability of 99.999% (an annual failure rate of 0.001% or less), one order of magnitude higher than the 99.8% to 99.9% of General Purpose SSD, which makes it suitable for mission-critical workloads such as Oracle and SAP HANA. Consider this a design value for durability, not a figure guaranteed by a service level agreement (SLA). st1 suits workloads centered on sequential reads, such as big data and log processing, and provides up to 500 MiB/s of throughput at low cost.
IOPS and Throughput Design
Estimating IOPS requirements requires understanding the I/O patterns of the application. Workloads with a lot of random I/O, such as databases, are limited by IOPS, while sequential I/O such as ETL and log analysis is limited by throughput. Measure actual IOPS with the CloudWatch VolumeReadOps and VolumeWriteOps metrics; if VolumeQueueLength stays at a high level continuously, I/O waits could be occurring, so the volume becomes a target for investigation. (The appropriate value varies by volume type and I/O size, so it cannot be judged mechanically with a single threshold.) Adding IOPS to gp3 beyond the baseline of 3,000 IOPS costs about 0.006 USD per 1 IOPS per month (as of August 2026, Tokyo Region). As long as the required IOPS fits within the gp3 limit, the basic policy is to start by raising it on the gp3 side. The cases for moving to io2 are when you need IOPS beyond the gp3 limit, when 99.999% durability is a requirement, or when stable sub-millisecond latency is required. io2 provisioned IOPS pricing is tiered by usage: in the Tokyo Region, it is about 0.074 USD per 1 IOPS per month up to 32,000 IOPS, about 0.0518 USD per month from 32,001 IOPS to 64,000 IOPS, and about 0.0363 USD per month for the portion above 64,000 IOPS (as of August 2026). In the first tier, the unit price is at least 10 times that of gp3, so accurately estimating the IOPS you truly need is the key to cost optimization.
Snapshot Strategy and Backup Design
EBS snapshots are incremental and store in S3 only the blocks that have changed since the previous snapshot. The initial snapshot copies all data, but from the second snapshot onward only the differences are saved, so storage costs and creation time drop significantly. Snapshot automation uses Amazon Data Lifecycle Manager (DLM). DLM policies define tag-based schedules, which can automate daily and weekly snapshot creation and generation management. An example of a production configuration is a combination that keeps 7 generations of daily snapshots and 4 generations of weekly snapshots with DLM. The number of generations to retain is decided from the recovery objectives (RPO / RTO) and compliance requirements, so consider these numbers a starting point. With cross-region copy enabled, you can also handle DR for regional failures. Fast Snapshot Restore (FSR) is a feature that eliminates the latency penalty that occurs on the initial access to a volume restored from a snapshot. For workloads that cannot tolerate latency on initial access, such as databases, enabling FSR is recommended.
EBS Pricing
(As of August 2026, on-demand pricing in the Tokyo Region (ap-northeast-1)) gp3 costs 0.096 USD per GB per month and includes 3,000 IOPS and 125 MiB/s of throughput at no additional charge. Anything beyond that is added at 0.006 USD per 1 IOPS per month and 0.048 USD per 1 MiB/s per month. gp2 costs 0.12 USD per GB per month, so for the same capacity gp3 is 20% cheaper, and it also has the advantage that IOPS and throughput can be configured separately from capacity. io2 costs 0.142 USD per GB per month plus a charge for provisioned IOPS, whose unit price is tiered by usage (0.074 USD per 1 IOPS per month up to 32,000 IOPS, 0.0518 USD from 32,001 IOPS to 64,000 IOPS, and 0.0363 USD for the portion above 64,000 IOPS). HDD types have no IOPS charge: st1 (Throughput Optimized HDD) costs 0.054 USD per GB per month and sc1 (Cold HDD) costs 0.018 USD. Unit prices differ by Region, so check actual estimates against the official price list for the Region you use; the figures above are only a comparison within the Tokyo Region. As a policy, gp3 is the default choice, and io2 is chosen only when IOPS beyond the gp3 limit or 99.999% durability is required. In addition, taking inventory of unattached volumes and snapshots that are no longer needed also helps (volumes that are not in use keep incurring charges for their capacity).
Choosing Volumes by Workload
EBS volume types are chosen according to the characteristics of the workload. For many common uses, the general purpose type, with a good balance of cost and performance, is suitable, and because its performance can be adjusted independently, it can be used flexibly. For uses that require high IOPS and stable low latency, such as databases, a high-performance type that guarantees performance is a good fit. For throughput-oriented processing, such as reading and writing large files sequentially, a type optimized for that purpose is chosen. Choosing high-performance volumes across the board wastes cost, while insufficient performance slows processing down. What matters is to identify the performance characteristics that the workload requires and select volumes accordingly.
Performance Monitoring and Volume Modification
In EBS operations, you monitor whether volume performance matches the actual workload. Measure IOPS, throughput, latency, and queue status to see whether performance has hit a ceiling. If performance is insufficient, or conversely excessive, adjust the volume settings. Because EBS lets you change size, performance, and type without stopping operation, you can respond flexibly to changes in demand. Rather than over-provisioning from the start, adjust to an appropriate size and performance while watching actual usage, and you can operate with performance maintained and wasted cost kept down.
Summary - EBS Design Best Practices
The basic policy for EBS volume design is to start with gp3, measure with CloudWatch metrics, and scale up as needed. Make use of the flexibility of gp3, which can adjust IOPS and throughput independently, and avoid over-provisioning. Automate snapshots with DLM and prepare for DR with cross-region copies. Because volume type changes can be made online, there is no need to aim for the optimal solution from the start; an approach that optimizes step by step based on measured data works well.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.