AWS EBS Pricing for High-IOPS Workloads in 2026

High-performance block storage can turn a modest EC2 bill into an expensive monthly commitment. Because the storage charge is only one part of the total AWS EBS pricing model, you must balance your database needs for high IOPS, sustained throughput, and stable low latency against your overall cost optimization goals.

For most workloads, gp3 offers the most efficient cost profile. However, io2 and io2 Block Express earn their premium when durability, strict latency consistency, or extreme per-volume performance requirements cannot be compromised.

The right architectural decision starts with the cost model, then checks whether the selected EC2 instance can actually utilize the performance levels you are paying for.

Key Takeaways

• In us-east-1, gp3 volumes cost $0.08 per GB-month and include 3,000 IOPS plus 125 MiB/s of throughput.
• gp3 can now reach 80,000 IOPS and 2,000 MiB/s per volume, which covers many demanding database workloads at a fraction of io2 cost.
• io2 costs $0.125 per GB-month, while Provisioned IOPS use tiered pricing that rises quickly for high-performance volumes that require greater throughput.
• io2 Block Express supports up to 256,000 IOPS and 4,000 MiB/s, but it fits only workloads that require its durability and sub-millisecond latency profile.
• EBS volume pricing is only useful when the EC2 instances, operating system, queue depth, and application I/O pattern can consume the provisioned performance while aligning with the necessary baseline performance and low latency profile.

What AWS EBS Pricing Includes in 2026

Amazon EBS pricing is structured around three primary components: provisioned storage, provisioned IOPS, and provisioned throughput. The total cost depends on your chosen volume type. For those just starting out, the AWS Free Tier provides an excellent entry point, offering 30 GB of total EBS storage for new accounts.

For high-IOPS workloads, General Purpose SSD (gp3), io2, and io2 Block Express are the most relevant options. While this guide focuses on performance-heavy volumes, AWS also offers Throughput Optimized HDD (st1) for frequently accessed, throughput-intensive workloads and Cold HDD (sc1) for less frequently accessed data. Older gp2 volumes remain available for existing workloads, but they tie performance directly to volume size. This legacy model makes capacity expansion an indirect way to purchase performance. In contrast, gp3 separates storage from performance settings, which simplifies cost planning.

The official Amazon EBS pricing page lists specific regional rates and billing rules. All dollar figures below use the AWS US East (N. Virginia), or us-east-1, region. Prices vary by AWS region, and Local Zones may apply separate rates.

AWS bills EBS volumes in per-second increments with a 60-second minimum. Monthly examples are useful for budgeting, so the calculations in this article assume that each volume runs for an entire 30-day month.

For gp3, the N. Virginia rates are:

• $0.08 per GB-month for storage
• 3,000 IOPS included with each volume
• 125 MiB/s throughput included with each volume
• $0.005 per provisioned IOPS-month above 3,000 IOPS
• $0.04 per provisioned MiB/s-month above 125 MiB/s

io2 storage costs $0.125 per GB-month. Its IOPS charges are tiered per volume: $0.065 per IOPS-month for the first 32,000 IOPS, $0.046 for IOPS 32,001 through 64,000, and $0.032 above 64,000 IOPS on io2 Block Express.

Provisioned performance is billable capacity, not a pay-per-I/O meter. A volume set to 40,000 IOPS costs the same whether the application uses 5,000 or 39,000 IOPS.

Snapshot storage is managed separately. EBS snapshots are stored in Amazon S3, which provides high durability. Standard EBS snapshots cost $0.05 per GB-month in us-east-1, while EBS Snapshots Archive costs $0.0125 per GB-month with a 90-day minimum retention period. Since snapshots store changed blocks incrementally, a large volume does not automatically result in a large monthly snapshot bill.

gp3 Pricing for Most High-Performance Workloads

gp3 volumes should be the default starting point for transactional applications that need high performance without the cost of io2 durability. As a versatile General Purpose SSD option, gp3 volumes are suitable for many PostgreSQL, MySQL, MongoDB, Elasticsearch, Kafka, and application-server workloads.

Each gp3 volume includes a baseline performance of 3,000 IOPS and 125 MiB/s regardless of its size. A 100 GB volume and a 10 TB volume start with the same included performance. Teams can then add Provisioned IOPS or throughput independently to meet specific application demands.

AWS increased the maximum size for these volumes to 64 TiB and raised the performance ceiling to 80,000 IOPS and 2,000 MiB/s in 2025. The gp3 capacity and performance update did not change the underlying pricing model.

A volume’s settings still have relationship limits. AWS allows up to 500 IOPS per GiB and up to 0.25 MiB/s of throughput per Provisioned IOPS. Therefore, an 80,000-IOPS volume needs at least 160 GiB of storage. A workload requesting 2,000 MiB/s needs enough configured IOPS to support that throughput level.

The AWS gp3 volume documentation is the source of truth for current limits and supported configurations. Check it before standardizing on a new volume template.

A 1,000 GB gp3 volume provisioned at 16,000 IOPS and 500 MiB/s costs about $160 per month in us-east-1:

• Storage: 1,000 GB x $0.08 = $80
• Extra IOPS: 13,000 x $0.005 = $65
• Extra throughput: 375 MiB/s x $0.04 = $15

That is a strong price point for a workload that needs sustained performance beyond the included baseline. However, gp3 targets general-purpose SSD performance. It does not offer the same durability target or low-latency consistency as io2.

When io2 and Block Express Justify Their Cost

The io2 volume type and io2 Block Express serve as the modern, high-performance successors to the older io1 volumes. While io1 volumes remain available for legacy support, they are generally less cost-effective than the current io2 generation. AWS designs io2 for 99.999% durability, offering an improvement over the 99.8% to 99.9% durability target of gp3 volumes.

This durability profile is critical for databases that maintain large write-ahead logs, high-value transactional systems, and clustered applications with strict recovery objectives. It also provides significant value when minimizing latency variation is necessary to maintain application revenue or meet service-level commitments. Because these volumes provide consistently low latency, they are often the preferred choice for mission-critical enterprise applications.

Standard io2 volumes scale to 64,000 IOPS per volume. io2 Block Express extends that performance ceiling to 256,000 IOPS and 4,000 MiB/s. AWS describes Block Express as the primary choice for workloads requiring sub-millisecond latency, including large Oracle, SAP HANA, and Microsoft SQL Server deployments. The AWS Block Express performance guidance provides workload-level context for those use cases.

The price difference is substantial, and users should carefully manage their Provisioned IOPS. An io2 volume configured for 40,000 IOPS incurs significant monthly costs. While the tiered pricing model reduces the per-unit rate after 32,000 IOPS, these costs remain higher than general-purpose tiers, making it clear that io2 is not a direct substitute for gp3.

Additionally, io2 offers Multi-Attach support for specific use cases on supported Nitro-based EC2 instances. Multiple instances can attach to the same io2 volume within a single Availability Zone, provided the operating system and clustered application are configured to coordinate access. Keep in mind that Multi-Attach is a specialized feature rather than a shortcut for ordinary shared storage.

Choose io2 or io2 Block Express only after documenting the specific requirements that gp3 cannot meet. That record should include p95 and p99 latency targets, durability requirements, total IOPS demand, specific write patterns, recovery objectives, and observed application behavior during peak load.

High-IOPS EBS Cost Examples in us-east-1

The following monthly estimates use 1,000 GB of provisioned storage in us-east-1. Each volume runs for a full 30-day month. These figures exclude EC2 instance charges, snapshots, data transfer charges, Fast Snapshot Restore, taxes, and backup tooling.

The comparison demonstrates why gp3 deserves a serious performance test before an io2 purchase. At 40,000 IOPS, the modeled gp3 volume costs about $300 monthly, while the io2 configuration costs about $2,573.

The io2 Block Express example uses 80,000 IOPS. Its total cost for Provisioned IOPS breaks down as $2,080 for the first 32,000 IOPS, $1,472 for the next 32,000, and $512 for the final 16,000. Throughput beyond the included 125 MiB/s adds $75 to account for 1,875 MiB/s of additional performance.

These are planning examples, not universal AWS prices. Use the EBS volume type comparison and the AWS Pricing Calculator before approving a production design. Region, volume lifetime, storage size, snapshot retention, and planned performance all affect the total monthly bill.

Match IOPS to the Real I/O Pattern

A database team might request 50,000 IOPS when the application actually only requires low write latency during short checkpoint periods. Buying 50,000 sustained Provisioned IOPS can solve the symptom while wasting money during the rest of the month. As part of your broader cost optimization strategy, you must align provisioned capacity with actual application behavior.

Start by analyzing application and database telemetry. Separate random reads, random writes, sequential scans, log flushes, backups, replication, and maintenance tasks. IOPS alone do not describe demand because a workload can consume high throughput with large I/O requests and modest IOPS.

For example, 4 KiB database I/O reaches 40,000 IOPS at roughly 156 MiB/s, while a 256 KiB sequential scan achieves 1,000 MiB/s of throughput with only 4,000 IOPS. Provisioning based on IOPS without checking I/O size can leave your throughput undersized and performance bottlenecked.

CloudWatch data helps validate these requirements. Review VolumeReadOps, VolumeWriteOps, VolumeReadBytes, VolumeWriteBytes, VolumeQueueLength, and latency data over normal traffic, batch windows, failover tests, and peak business periods. Use percentiles rather than averages when the application has a strict latency budget.

The AWS re:Post volume type comparison is a useful resource when validating performance characteristics before a migration. However, you should always benchmark the real engine and schema. Using a General Purpose SSD as a starting point for these tests is common, but remember that synthetic tests can overstate performance if they use a queue depth or I/O size that production never reaches.

EC2 Limits Can Waste Provisioned EBS Performance

EBS performance ends at the instance boundary. EC2 instances have specific bandwidth, IOPS, and attachment limits that dictate how they interact with block storage. If your chosen instance caps EBS throughput at 1,000 MiB/s, provisioning 2,000 MiB/s on a volume does not improve your application performance.

EBS-optimized EC2 instances dedicate network capacity to storage traffic. Most current Nitro-based instance families support EBS optimization by default, but their maximum performance varies significantly by size. Moving from an m7i.2xlarge to an m7i.8xlarge can change the available throughput ceiling as much as a storage configuration change.

The operating system also needs enough queue depth and parallelism to handle high volumes of data. A single-threaded process issuing synchronous requests cannot saturate high levels of Provisioned IOPS. Linux block device settings, database worker counts, filesystem settings, RAID configuration, and application connection pools can all become bottlenecks that mask your actual performance.

When using striped layouts for higher aggregate performance, calculate the total capacity and check each member volume’s limits. RAID 0 can spread I/O across several gp3 volumes to exceed single-volume caps, but this approach also expands the failure domain. It should only be implemented when supported by a sound backup and recovery design.

A Cost-Control Process for EBS Performance

High-IOPS optimization works best as a recurring cost optimization exercise instead of a one-time migration task. Volume settings can drift after incident fixes, database growth, or application releases, making consistent cost optimization essential for maintaining budget alignment.

Use this process for every material EBS workload:

1. Capture peak IOPS, throughput, average latency, p95 latency, p99 latency, and I/O size for at least one representative business cycle.
2. Check the EC2 instance’s EBS limits before increasing volume performance.
3. Test gp3 at a measured target, including load spikes, checkpoints, rebuilds, and failover conditions.
4. Move to io2 only when a tested requirement calls for its durability, latency profile, Multi-Attach capability, or higher per-volume ceiling.
5. Tag volumes by application, environment, owner, data class, and cost center so FinOps reports can identify idle capacity.

Volume right-sizing should also include storage capacity. A 4 TB gp3 volume that holds 900 GB of data costs $320 monthly before any added IOPS or throughput. Storage growth often happens faster than performance reviews.

FinOps teams should separate EBS charges into storage, performance, snapshots, and recovery features. That split reveals whether the bill comes from an oversized primary volume, an overprovisioned IOPS setting, or a snapshot retention policy that no longer matches the workload’s recovery target. When managing your data footprint, consider using EBS snapshots to back up volumes, and leverage the snapshot archive tier to reduce long-term storage costs for data that is rarely accessed. Additionally, utilizing EBS direct APIs can help you read data directly from snapshots without attaching them to an instance, which streamlines backup processes. Remember that enabling Fast Snapshot Restore can also impact the monthly bill, so keep that in mind when calculating your total expenditures.

For teams comparing legacy choices, this cost-performance EBS comparison offers useful background. Production decisions should still rely on AWS documentation, current regional prices, and tested workload data.

Frequently Asked Questions

Is it always cheaper to use gp3 instead of io2?

Yes, gp3 is almost always the more cost-effective option for high-performance workloads. Because gp3 separates storage capacity from performance settings, you can provision the exact IOPS and throughput needed without paying the premium for io2’s higher durability and latency consistency.

Can I change my EBS volume type if my performance needs change?

Yes, you can modify volume types, sizes, and performance settings on the fly without detaching the volume or shutting down the instance. This elasticity allows you to scale your performance up during peak periods and reduce it afterward to maintain optimal cost efficiency.

Does provisioning 10,000 IOPS mean I will always get 10,000 IOPS?

Provisioning 10,000 IOPS grants your volume the capacity to handle that load, but actual performance depends on your EC2 instance limits and application configuration. If your EC2 instance has a lower bandwidth ceiling or your application lacks the necessary I/O parallelism, you may not be able to fully utilize the IOPS you are paying for.

How does snapshot pricing work compared to volume pricing?

EBS snapshots are priced based on the amount of data stored in S3, rather than the size of the original provisioned volume. Since snapshots store only the changed blocks incrementally, you only pay for the unique data stored, which is significantly cheaper than the standard monthly rate for provisioned volume storage.

Conclusion

Mastering AWS EBS pricing requires a granular approach to performance management. Because gp3 volumes can deliver up to 80,000 IOPS at a significantly lower cost than premium tiers, they remain the baseline option for most performance-sensitive workloads.

However, your architecture decisions should remain flexible. While io2 Block Express justifies its higher rates when you need sub-millisecond latency or 99.999% durability, you should also consider Throughput Optimized HDD (st1) or Cold HDD (sc1) for data-heavy workloads where extreme IOPS are not required. Remember that Amazon S3 serves as the cost-effective long-term destination for your EBS snapshots, allowing you to clean up unused storage. Ultimately, effective cost optimization for your block storage strategy comes down to buying only the specific performance your application requires.