Menu
Amazon Relational Database Service
User Guide (API Version 2014-10-31)

Storage for Amazon RDS

Amazon RDS uses Amazon Elastic Block Store (Amazon EBS) volumes for database and log storage. Depending on the amount of storage requested, Amazon RDS automatically stripes across multiple Amazon EBS volumes to enhance IOPS performance. Amazon RDS provides three types of storage with a range of storage and performance options. For Amazon RDS pricing information, see the Amazon RDS product page.

Amazon RDS Storage Types

Amazon RDS provides three storage types: magnetic, General Purpose (SSD), and Provisioned IOPS (input/output operations per second). They differ in performance characteristics and price, allowing you to tailor your storage performance and cost to the needs of your database. You can create MySQL, MariaDB, PostgreSQL, and Oracle RDS DB instances with up to 6TB of storage and SQL Server RDS DB instances with up to 4TB of storage when using the Provisioned IOPS and General Purpose (SSD) storage types. Existing MySQL, PostgreSQL, and Oracle RDS database instances can be scaled to these new database storage limits without any downtime. For a complete discussion of the different volume types, see the topic Amazon EBS Volume Types.

  • Magnetic (Standard) – Magnetic storage, also called standard storage, offers cost-effective storage that is ideal for applications with light or burst I/O requirements. These volumes deliver approximately 100 IOPS on average, with burst capability of up to hundreds of IOPS, and they can range in size from 5 GB to 3 TB, depending on the DB instance engine that you chose. Magnetic storage is not reserved for a single DB instance, so performance can vary greatly depending on the demands placed on shared resources by other customers.

  • General Purpose (SSD) – General purpose, SSD-backed storage, also called gp2, can provide faster access than disk-based storage. This storage type can deliver single-digit millisecond latencies, with a base performance of 3 IOPS per Gigabyte (GB) and the ability to burst to 3,000 IOPS for extended periods of time up to a maximum of 10,000 PIOPS. General purpose (SSD) volumes can range in size from 5 GB to 6 TB for MySQL, MariaDB, PostgreSQL, and Oracle DB instances, and from 20 GB to 4 TB for SQL Server DB instances. This storage type is excellent for small to medium-sized databases.

  • Provisioned IOPS – Provisioned IOPS storage is designed to meet the needs of I/O-intensive workloads, particularly database workloads, that are sensitive to storage performance and consistency in random access I/O throughput. Provisioned IOPS volumes can range in size from 100 GB to 6 TB for MySQL, MariaDB, PostgreSQL, and Oracle DB engines. SQL Server Express and Web editions can range in size from 100 GB to 4 TB, while SQL Server Standard and Enterprise editions can range in size from 200 GB to 4 TB. You specify the amount of storage you want allocated, and then specify the amount of dedicated IOPS you want. These two values form a ratio, and this value maintains the ratio specified for the DB engine you chose. Amazon RDS delivers within 10 percent of the provisioned IOPS performance 99.9 percent of the time over a given year.

Several factors can affect the performance of Amazon EBS volumes, such as instance configuration, I/O characteristics, and workload demand. For more information about getting the most out of your Provisioned IOPS volumes, see Amazon EBS Volume Performance.

For existing MySQL, MariaDB, PostgreSQL, and Oracle DB instances, you might observe some I/O capacity improvement if you scale up your storage. Note that you cannot change the storage capacity nor the type of storage for a SQL Server DB instance due to extensibility limitations of striped storage attached to a Windows Server environment.

Performance Metrics

Amazon RDS provides several metrics that you can use to determine how your DB instance is performing. You can view the metrics in the RDS console by selecting your DB instance and clicking Show Monitoring. You can also use Amazon CloudWatch to monitor these metrics. For more information, go to the Viewing DB Instance Metrics.

  • IOPS – the number of I/O operations completed per second. This metric is reported as the average IOPS for a given time interval. Amazon RDS reports read and write IOPS separately on one minute intervals. Total IOPS is the sum of the read and write IOPS. Typical values for IOPS range from zero to tens of thousands per second.

  • Latency – the elapsed time between the submission of an I/O request and its completion. This metric is reported as the average latency for a given time interval. Amazon RDS reports read and write latency separately on one minute intervals in units of seconds. Typical values for latency are in the millisecond (ms); for example, Amazon RDS reports 2 ms as 0.002 seconds.

  • Throughput – the number of bytes per second transferred to or from disk. This metric is reported as the average throughput for a given time interval. Amazon RDS reports read and write throughput separately on one minute intervals using units of megabytes per second (MB/s). Typical values for throughput range from zero to the I/O channel’s maximum bandwidth.

  • Queue Depth – the number of I/O requests in the queue waiting to be serviced. These are I/O requests that have been submitted by the application but have not been sent to the device because the device is busy servicing other I/O requests. Time spent waiting in the queue is a component of Latency and Service Time (not available as a metric). This metric is reported as the average queue depth for a given time interval.  Amazon RDS reports queue depth in one minute intervals. Typical values for queue depth range from zero to several hundred.

Facts About Amazon RDS Storage

The following points are important facts you should know about Amazon RDS storage:

  • The current maximum channel bandwidth available is 4000 megabits per second (Mbps) full duplex.  In terms of the read and write throughput metrics, this equates to about 210 megabytes per second (MB/s) in each direction.  A perfectly balanced workload of 50% reads and 50% writes may attain a maximum combined throughput of 420 MB/s.  Note that this is channel throughput, which includes protocol overhead, so the actual data throughput may be less.

  • Provisioned IOPS works with an I/O request size of 32 KB. An I/O request smaller than 32 KB is handled as one I/O; for example, 1000 16 KB I/O requests are treated the same as 1000 32 KB requests. I/O requests larger than 32 KB consume more than one I/O request; Provisioned IOPS consumption is a linear function of I/O request size above 32 KB.  For example, a 48 KB I/O request consumes 1.5 I/O requests of storage capacity; a 64 KB I/O request consumes 2 I/O requests, etc. For more information about Provisioned IOPS, see Amazon RDS Provisioned IOPS Storage to Improve Performance.

    Note that I/O size does not affect the IOPS values reported by the metrics, which are based solely on the number of I/Os over time.  This means that it is possible to consume all of the IOPS provisioned with fewer I/Os than specified if the I/O sizes are larger than 32 KB.  For example, a system provisioned for 5,000 IOPS can attain a maximum of 2,500 IOPS with 64 KB I/O or 1,250 IOPS with 128 KB IO.

    Note that magnetic storage does not provision I/O capacity, so all I/O sizes are counted as a single I/O. General purpose storage provisions I/O capacity based on the size of the volume. For more information on general purpose storage throughput, go to General Purpose (SSD) Volumes.

  • The first time a DB instance is started and accesses an area of disk for the first time, the process can take longer than all subsequent accesses to the same disk area.  This is known as the “first touch penalty.” Once an area of disk has incurred the first touch penalty, that area of disk does not incur the penalty again for the life of the instance, even if the DB instance is rebooted, restarted, or the DB instance class changes. Note that a DB instance created from a snapshot, a point-in-time restore, or a read replica is a new instance and does incur this first touch penalty.

  • Because Amazon RDS manages your DB instance, we reserve overhead space on the instance. While the amount of reserved storage varies by DB instance class and other factors, this reserved space can be as much as one or two percent of the total storage.

  • Provisioned IOPS provides a way to reserve I/O capacity by specifying IOPS. Like any other system capacity attribute, maximum throughput under load will be constrained by the resource that is consumed first. That resource could be IOPS, channel bandwidth, CPU, memory, or database internal resources.

Other Factors That Impact Storage Performance

All of the following system related activities consume I/O capacity and may reduce database instance performance while in progress:

  • DB snapshot creation

  • Nightly backups

  • Multi-AZ peer creation

  • Read replica creation

  • Scaling storage

System resources can constrain the throughput of a DB instance, but there can be other reasons for a bottleneck. If you find the following situation, your database could be the issue:

  • The channel throughput limit is not reached

  • Queue depths are consistently low

  • CPU utilization is under 80%

  • There is free memory available

  • There is no swap activity

  • There is plenty of free disk space

  • Your application has dozens of threads all submitting transactions as fast as the database will take them, but there is clearly unused I/O capacity

If there isn’t at least one system resource that is at or near a limit, and adding threads doesn’t increase the database transaction rate, the bottleneck is most likely contention in the database. The most common forms are row lock and index page lock contention, but there are many other possibilities. If this is your situation, you should seek the advice of a database performance tuning expert.

Adding Storage and Changing Storage Type

For existing MySQL, MariaDB, PostgreSQL, and Oracle DB instances, you might observe some I/O capacity improvement if you scale up your storage. Note that you cannot change the storage capacity nor the type of storage for a SQL Server DB instance due to extensibility limitations of striped storage attached to a Windows Server environment.

You can modify a DB instance to use additional storage and you can convert to a different storage type. Adding storage or converting to a different storage type can take time and reduces the performance of your DB instance, so you should plan when to make these changes.

Although your DB instance is available for reads and writes when adding storage, you may experience degraded performance until the process is complete. Adding storage may take several hours; the duration of the process depends on several factors such as database load, storage size, storage type, amount of IOPS provisioned (if any), and number of prior scale storage operations. Typical scale storage times will be under 24 hours, but can take up to several days in some cases. During the scaling process, the DB instance will be available for use, but may experience performance degradation. While storage is being added, nightly backups are suspended and no other Amazon RDS operations can take place, including modify, reboot, delete, create Read Replica, and create DB Snapshot.

Storage conversions between magnetic storage and general purpose (SSD) storage can potentially deplete the initial 5.4 million I/O credits (3,000 IOPS X 30 Minutes) allocated for general purpose (SSD) storage. When performing these storage conversions, the first 82 GB of data will be converted at approximately 3,000 IOPS, while the remaining data will be converted at the base performance rate of 3 IOPS per GB of allocated general purpose (SSD) storage. This can result in longer conversion times. You can provision more general purpose (SSD) storage to increase your base I/O performance rate, thus improving the conversion time, but note that you cannot reduce storage size once it has been allocated.

General Purpose (SSD) Storage

General purpose (SSD) storage offers cost-effective storage that is ideal for small or medium-sized database workloads. This storage type can deliver single-digit millisecond latencies, with a base performance of 3 IOPS per Gigabyte (GB) and the ability to burst to 3,000 IOPS for extended periods of time up to a maximum of 10,000 IOPS. General purpose (SSD) storage volumes can range in size from 5 GB to 6 TB for MySQL, MariaDB, PostgreSQL, and Oracle DB instances and from 20 GB to 4 TB for SQL Server DB instances. Note that provisioning less than 100 GB of general purpose (SSD) storage for high-throughput workloads can result in higher latencies if the initial general purpose (SSD) I/O credit balance is depleted.

I/O Credits and Burst Performance

General Purpose (SSD) storage performance is governed by volume size, which dictates the base performance level of the volume and how quickly it accumulates I/O credits. Larger volumes have higher base performance levels and accumulate I/O credits faster. I/O credits represent the available bandwidth that your General Purpose (SSD) storage can use to burst large amounts of I/O when more than the base level of performance is needed. The more credits your storage has for I/O, the more time it can burst beyond its base performance level and the better it performs when more performance is needed.

When using General Purpose (SSD) storage, your DB instance receives an initial I/O credit balance of 5.4 million I/O credits, which is enough to sustain a burst performance of 3,000 IOPS for 30 minutes. This initial credit balance is designed to provide a fast initial boot cycle for boot volumes and to provide a good bootstrapping experience for other applications. Your storage earns I/O credits every second at a base performance rate of 3 IOPS per GB of volume size. For example, a 100 GB General Purpose (SSD) storage has a base performance of 300 IOPS.

When your storage requires more than the base performance I/O level, it uses I/O credits in the credit balance to burst to the required performance level, up to a maximum of 3,000 IOPS. Storage larger than 1,000 GB has a base performance that is equal or greater than the maximum burst performance (up to 10,000 IOPS), so its I/O credit balance never depletes and it can burst indefinitely. When your storage uses fewer I/O credits than it earns in a second, unused I/O credits are added to the I/O credit balance. The maximum I/O credit balance for a DB instance using General Purpose (SSD) storage is equal to the initial credit balance (5.4 million I/O credits).

If your storage uses all of its I/O credit balance, its maximum performance will remain at the base performance level (the rate at which your storage earns credits) until I/O demand drops below the base level and unused credits are added to the I/O credit balance. The more storage, the greater the base performance is and the faster it replenishes the credit balance.

Note

Storage conversions between Magnetic storage and General Purpose (SSD) storage can potentially deplete the initial 5.4 million I/O credits (3,000 IOPS X 30 Minutes) allocated for General Purpose (SSD) storage. When performing these storage conversions, the first 82 GB of data will be converted at approx. 3,000 IOPS, while the remaining data will be converted at the base performance rate of 3 IOPS per GB of allocated General Purpose (SSD) storage. This can result in longer conversion times. You can provision more General Purpose (SSD) storage to increase your base I/O performance rate, thus improving the conversion time, but note that you cannot reduce storage size once it has been allocated.

The following table lists several storage sizes and the associated base performance of the storage (which is also the rate at which it accumulates I/O credits), the burst duration at the 3,000 IOPS maximum (when starting with a full credit balance), and the time in seconds that the storage takes to refill an empty credit balance.

Storage size (GB) Base performance (IOPS) Maximum burst duration @ 3,000 IOPS (seconds) Seconds to fill empty credit balance
1 3 1,802 1,800,000
100 300 2,000 18,000
250 750 2,400 7,200
500 1,500 3,600 3,600
750 2,250 7,200 2,400
1,000 3,000 Infinite N/A

The burst duration of your storage depends on the size of the storage, the burst IOPS required, and the credit balance when the burst begins. This relationship is shown in the equation below:

                              (Credit balance)
   Burst duration =  ------------------------------------
                     (Burst IOPS) - 3(Storage size in GB) 

If you notice that your storage performance is frequently limited to the base level due to an empty I/O credit balance, you should consider allocating more General Purpose (SSD) storage with a higher base performance level. Alternatively, you can switch to Provisioned IOPS storage for workloads that require sustained IOPS performance.

For workloads with steady state I/O requirements, provisioning less than 100 GB of General Purpose (SSD) storage may result in higher latencies if you exhaust your I/O burst credit balance.

Amazon RDS Provisioned IOPS Storage to Improve Performance

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. Provisioned IOPS helps performance tuning.

Note

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 AWS Command Line Interface (CLI). You specify the IOPS rate and the amount of storage that you require. You can provision a MySQL, MariaDB, PostgreSQL, or Oracle DB instance with up to 30,000 IOPS and 6 TB of allocated storage. You can provision a SQL Server DB instance with up to 20,000 IOPS and 4 TB of allocated storage.

Note

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, MariaDB, PostgreSQL, SQL Server (excluding SQL Server Express), and Oracle DB instances. 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 6 TB (6000 GB) of storage (a ratio of 5:1).

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 - 6 TB3:1 - 10:1
MariaDB1000 - 30,000 IOPS100 GB - 6 TB3:1 - 10:1
PostgreSQL1000 - 30,000 IOPS100 GB - 6 TB3:1 - 10:1
Oracle1000 - 30,000 IOPS100 GB - 6 TB3:1 - 10:1
SQL Server Express and Web1000 - 20,000 IOPS100 GB - 4 TB3:1 - 10:1
SQL Server Standard and Enterprise1000 - 20,000 IOPS200 GB - 4 TB3:1 - 10:1

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

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 magnetic storage, you can add read replicas that use Provisioned IOPS storage and vice versa. If you use magnetic 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 magnetic storage or Provisioned IOPS storage. If your DB instance uses magnetic storage, you can use a DB snapshot to restore only a DB instance that uses magnetic 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 magnetic 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 I/O requests the system is capable of processing concurrently. Increased concurrency allows for decreased latency since I/O 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 I/O.  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 256 KB. More write throughput and fewer write I/O means log writes have become larger and are averaging larger than 32 KB since those I/O requests consume more than one I/O of Provisioned IOPS capacity.

Provisioned IOPS Storage Support in the AWS CLI and Amazon RDS API

The AWS CLI supports Provisioned IOPS storage in the following commands:

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

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 and MariaDB use 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 8,000 IOPS total for both directions (input/output channel) for 16 KB I/O and 16,000 IOPS total for both directions for 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. I/O requests larger than 32 KB are treated as more than one I/O for the purposes of PIOPS capacity consumption. A 40 KB I/O request will consume 1.25 I/Os, a 48 KB request will consume 1.5 I/Os, a 64 KB request will consume 2 I/Os, and so on. The I/O request is not split into separate I/Os; all I/O requests are presented to the storage device unchanged. For example, if the database submits a 128 KB I/O request, it goes to the storage device as a single 128 KB I/O request, but it will consume the same amount of PIOPS capacity as four 32 KB I/O 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, MariaDB, and PostgreSQL) with full duplex and a workload that is perfectly balanced between reads and writes.

DB EnginePage SizeTheoretical Maximum IOPS Rate
MySQL16 KB30,000
MariaDB16 KB30,000
PostgreSQL8 KB30,000
Oracle8 KB25,000
SQL Server8 KB20,000

Note

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 Classes for Provisioned IOPS

If you are using Provisioned IOPS storage, we recommend that you use the M4, M3, R3, and M2 DB instance classes. These instance classes are optimized for Provisioned IOPS storage; other instance classes are not.

DB Instance Classes Optimized for Provisioned IOPSDedicated EBS Throughput (Mbps)Maximum 16k IOPS Rate**Max Bandwidth (MB/s)**
db.m1.large500 Mbps400062.5
db.m1.xlarge1000 Mbps8000125
db.m2.2xlarge500 Mbps400062.5
db.m2.4xlarge1000 Mbps8000125
db.m3.xlarge500 Mbps400062.5
db.m3.2xlarge1000 Mbps8000125
db.r3.xlarge500 Mbps400062.5
db.r3.2xlarge1000 Mbps8000125
db.r3.4xlarge2000 Mbps16000250
db.r3.8xlarge***
db.m4.large450 Mbps360056.25
db.m4.xlarge750 Mbps600093.75
db.m4.2xlarge1000 Mbps8000125
db.m4.4xlarge2000 Mbps16000250
db.m4.10xlarge4000 Mbps32000500

* The r3.8xlarge DB instance class has a 10-gigabit network interface that does not offer Amazon EBS optimization. Therefore, dedicated EBS bandwidth is not available in the r3.8xlarge DB instance class. However, you can use all of that bandwidth for traffic to EBS if your application isn’t pushing other network traffic that contends with EBS.

** This value is a rounded approximation based on a 100% read-only workload and it is provided as a baseline configuration aid. EBS-optimized connections are full-duplex, and can drive more throughput and IOPS in a 50/50 read/write workload where both communication lanes are used. In some cases, network, file system, and EBS encryption overhead can reduce the maximum throughput and IOPS available.

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.