Amazon Relational Database Service
User Guide (API Version 2013-09-09)
« PreviousNext »
View the PDF for this guide.Go to the AWS Discussion Forum for this product.Go to the Kindle Store to download this guide in Kindle format.Did this page help you?  Yes | No |  Tell us about it...

Provisioned IOPS Storage

For any production application that requires fast and consistent I/O performance, we recommend Provisioned IOPS (input/output operations per second) storage. Provisioned IOPS storage is a storage type that delivers fast, predictable, and consistent throughput performance. When you create a DB instance, you specify an IOPS rate and storage space allocation. Amazon RDS provisions that IOPS rate and storage for the lifetime of the DB instance or until you change it. Provisioned IOPS storage is optimized for I/O intensive, online transaction processing (OLTP) workloads that have consistent performance requirements.


You cannot decrease storage allocated for a DB instance.

You can create a DB instance that uses Provisioned IOPS storage by using the AWS Management Console, the Amazon RDS API, or the Command Line Interface (CLI). You specify the IOPS rate and the amount of storage that you require. You can provision a MySQL, PostgreSQL, or Oracle DB instance with up to 30,000 IOPS and 3 TB of allocated storage. You can provision a SQL Server DB instance with up to 10,000 IOPS and 1 TB of allocated storage.


Your actual realized IOPS may vary from the value that you specify depending on your database workload, DB instance size, and the page size and channel bandwidth that are available for your DB engine. For more information, see Factors That Affect Realized IOPS Rates.

The ratio of the requested IOPS rate to the amount of storage allocated is important. The ratio of IOPS to storage, in GB, for your DB instances should be between 3:1 and 10:1 for MySQL, PostgreSQL, and Oracle DB instances. For SQL Server DB instances, the ratio should be 10:1. For example, you could start by provisioning an Oracle DB instance with 1000 IOPS and 200 GB storage (a ratio of 5:1). You could then scale up to 2000 IOPS with 200 GB of storage (a ratio of 10:1), 3000 IOPS with 300 GB of storage, and up to the maximum for an Oracle DB instance of 30,000 IOPS with 3 TB (3000 GB) of storage.

The following table shows the IOPS and storage range for each database engine.

 Range of Provisioned IOPS Range of Storage Range of IOPS to Storage (GB) Ratio
MySQL1000 - 30,000 IOPS100 GB - 3 TB3:1 - 10:1
PostgreSQL1000 - 30,000 IOPS100 GB - 3 TB3:1 - 10:1
Oracle1000 - 30,000 IOPS100 GB - 3 TB3:1 - 10:1
SQL Server Express and Web1000 - 10,000 IOPS100 GB - 1 TB10:1
SQL Server Standard and Enterprise2000 - 10,000 IOPS200 GB - 1 TB10:1

You can modify an existing Oracle or MySQL DB instance to use Provisioned IOPS storage, and you can modify Provisioned IOPS storage settings.

Factors That Affect Realized IOPS Rates

Your actual realized IOPS rate may vary from the amount that you provision depending on page size and network bandwidth, which are determined in part by your DB engine. It is also affected by DB instance size and database workload.

Page Size and Channel Bandwidth

The theoretical maximum IOPS rate is also a function of database I/O page size and available channel bandwidth. MySQL uses a page size of 16 KB, while Oracle, PostgreSQL (default), and SQL Server use 8 KB. On a DB instance with a full duplex I/O channel bandwidth of 1000 megabits per second (Mbps), the maximum IOPS for page I/O is about 6,250 IOPS in each direction (input/output channel) for 16 KB I/O and 12,500 IOPS in each direction for 8 KB I/O. A workload consisting of 50% reads and 50% writes could reach 12,500 IOPS with 16 KB I/O or 25,000 IOPS with 8 KB I/O.

If traffic on one of the channels reaches capacity, available IOPS on the other channel cannot be reallocated. As a result, the attainable IOPS rate will be less than the provisioned IOPS rate.

Each page read or write constitutes one I/O operation. Database operations that read or write more than a single page will use multiple I/O operations for each database operation. IO requests larger than 16 KB are treated as more than one IO for the purposes of PIOPS capacity consumption. A 20 KB IO request will consume 1.25 IOs, a 24 KB request will consume 1.5 IOs, a 32 KB request will consume 2 IOs, and so on. The IO request is not split into separate IOs; all IO requests are presented to the storage device unchanged. For example, if the database submits a 128 KB IO request, it goes to the storage device as a single 128 KB IO request, but it will consume the same amount of PIOPS capacity as eight 16 KB IO requests.

The following table shows the page size and the theoretical maximum IOPS rate for each DB engine. IOPS rates are based on the m2.4xlarge instance class (for Oracle and SQL Server) or the cr1.8xlarge instance class (for MySQL and PostgreSQL) with full duplex and a workload that is perfectly balanced between reads and writes. The SQL Server limit of 10,000 is due to the current storage limit of 1 TB and the current maximum IOPS to storage ratio of 10:1.

DB EnginePage SizeMaximum IOPS Rate
MySQL16 KB20,000
PostgreSQL8 KB25,000
Oracle8 KB25,000
SQL Server8 KB10,000


If you provision an IOPS rate that is higher than the maximum or that is higher than your realized IOPS rate, you may still benefit from reduced latency and improvements in overall throughput.

DB Instance Class

If you are using Provisioned IOPS storage, we recommend that you use the db.m3.xlarge, db.m3.2xlarge, db.m1.large, db.m1.xlarge, db.m2.2xlarge, db.m2.4xlarge, db.r3.xlarge, db.r3.2xlarge, or db.r3.4xlarge DB instance classes. These instance classes are optimized for Provisioned IOPS storage; other instance classes are not. You can also effectively use the high-memory-cluster instance class db.cr1.8xlarge.

DB Instance Classes Optimized for Provisioned IOPSDedicated EBS Throughput (Mbps)Maximum 16k IOPS Rate
db.m3.xlarge500 Mbps4000
db.m1.large500 Mbps4000
db.m2.2xlarge500 Mbps4000
db.m3.2xlarge1000 Mbps8000
db.m1.xlarge1000 Mbps8000
db.m2.4xlarge1000 Mbps8000
db.r3.xlarge500 Mbps4000
db.r3.2xlarge1000 Mbps8000
db.r3.4xlarge2000 Mbps16000

Database Workload

System activities such as automated backups, DB snapshots, and scale storage operations may consume some I/O, which will reduce the overall capacity available for normal database operations. If your database design results in concurrency issues, locking, or other forms of database contention, you may not be able to directly use all the bandwidth that you provision.

If you provision IOPS capacity to meet your peak workload demand, during the non-peak periods, your application will probably consume fewer IOPS on average than provisioned.

To help you verify that you are making the best use of your Provisioned IOPS storage, we have added a new CloudWatch Metric called Disk Queue Depth. If your application is maintaining an average queue depth of approximately 5 outstanding I/O operations per 1000 IOPS that you provision, you can assume that you are consuming the capacity that you provisioned. For example, if you provisioned 10,000 IOPS, you should have a minimum of 50 outstanding I/O operations in order to use the capacity you provisioned.

Using Provisioned IOPS Storage with Multi-AZ, Read Replicas, Snapshots, VPC, and DB Instance Classes

For production OLTP use cases, we recommend that you use Multi-AZ deployments for enhanced fault tolerance and Provisioned IOPS storage for fast and predictable performance. In addition to Multi-AZ deployments, Provisioned IOPS storage complements the following features:

  • Amazon VPC for network isolation and enhanced security.

  • Read Replicas – The type of storage on a read replica is independent of that on the master DB instance. For example, if the master DB instance uses standard storage, you can add read replicas that use Provisioned IOPS storage and vice versa. If you use standard storage–based read replicas with a master DB instance that uses Provisioned IOPS storage, the performance of your read replicas may differ considerably from that of a configuration in which both the master DB instance and the read replicas are using Provisioned IOPS storage.

  • DB Snapshots – If you are using a DB instance that uses Provisioned IOPS storage, you can use a DB snapshot to restore an identically configured DB instance, regardless of whether the target DB instance uses standard storage or Provisioned IOPS storage. If your DB instance uses standard storage, you can use a DB snapshot to restore only a DB instance that uses standard storage.

  • You can use Provisioned IOPS storage with any DB instance class. However, smaller DB instance classes will not consistently make the best use of Provisioned IOPS storage. For the best performance, we recommend that you use one of the DB instance types that are optimized for Provisioned IOPS storage.

Provisioned IOPS Storage Costs

Because Provisioned IOPS storage reserves resources for your use, you are charged for the resources whether or not you use them in a given month. When you use Provisioned IOPS storage, you are not charged the monthly Amazon RDS I/O charge. If you prefer to pay only for I/O that you consume, a DB instance that uses standard storage may be a better choice. For Amazon RDS pricing information, see the Amazon RDS product page.

Getting the Most out of Amazon RDS Provisioned IOPS

Using Provisioned IOPS storage increases the number of IO requests the system is capable of processing concurrently. Increased concurrency allows for decreased latency since IO requests spend less time in a queue. Decreased latency allows for faster database commits, which improves response time and allows for higher database throughput.

For example, consider a heavily loaded OLTP database provisioned for 10,000 Provisioned IOPS that runs consistently at the channel limit of 105 Mbps throughput for reads. The workload isn’t perfectly balanced, so there is some unused write channel bandwidth. The instance would consume less than 10,000 IOPS and but would still benefit from increasing capacity to 20,000 Provisioned IOPS.

Increasing Provisioned IOPS capacity from 10,000 to 20,000 doubles the system’s capacity for concurrent IO.  Increased concurrency means decreased latency, which allows transactions to complete faster, so the database transaction rate increases. Read and write latency would improve by different amounts and the system would settle into a new equilibrium based on whichever resource becomes constrained first.

It is possible for Provisioned IOPS consumption to actually decrease under these conditions even though the database transaction rate can be much higher. For example, you could see write requests decline accompanied by an increase in write throughput. That’s a good indicator that your database is making better use of group commit.  More write throughput and the same write IOPS means log writes have become larger but are still less than 16 KB. More write throughput and fewer write IO means log writes have become larger and are averaging larger than 16 KB since those IO requests consume more than one IO of Provisioned IOPS capacity.

Provisioned IOPS Storage Support in the CLI and Amazon RDS API

The Amazon RDS CLI supports Provisioned IOPS storage in the following commands:

The Amazon RDS API supports Provisioned IOPS storage in the following actions: