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

Storage for Amazon RDS

Most of Amazon RDS uses Amazon Elastic Block Store (Amazon EBS) volumes for database and log storage. The exception is Amazon Aurora, which uses our proprietary storage system. 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 more information about pricing, see Amazon RDS Pricing.

Amazon RDS Storage Types

Amazon RDS provides three storage types: General Purpose (SSD), Provisioned IOPS (input/output operations per second), and magnetic. They differ in performance characteristics and price, allowing you to tailor your storage performance and cost to the needs of your database workload. You can create MySQL, MariaDB, PostgreSQL, and Oracle RDS DB instances with up to 6 TB of storage and Microsoft SQL Server RDS DB instances with up to 16 TB of storage when using the Provisioned IOPS and General Purpose (SSD) storage types.

  • General Purpose (SSD) – General Purpose (SSD), also called gp2, volumes offer cost-effective storage that is ideal for a broad range of workloads. These volumes deliver single-digit millisecond latencies and the ability to burst to 3,000 IOPS for extended periods of time. Between a minimum of 100 IOPS (at 33.33 GiB and below) and a maximum of 10,000 IOPS (at 3,334 GiB and above), baseline performance scales linearly at 3 IOPS per GiB of volume size. This storage type is excellent for small to medium-sized databases.

    For more information about general purpose (SSD) storage, including the storage size ranges, see General Purpose (SSD) Storage.

  • 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. You specify the amount of storage you want allocated, and then specify the amount of dedicated IOPS you want. Amazon RDS delivers within 10 percent of the provisioned IOPS performance 99.9 percent of the time over a given year.

    For more information about provisioned IOPS storage, including the storage size ranges, see Amazon RDS Provisioned IOPS Storage to Improve Performance.

  • Magnetic – Amazon RDS also supports magnetic storage for backward compatibility. We recommend that you use General Purpose (SSD) or Provisioned IOPS for any new storage needs. The maximum amount of storage allowed for DB instances on magnetic storage is less than that of the other storage types.

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. You can't change the storage capacity or storage type of a SQL Server DB instance.

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, see Viewing DB Instance Metrics. Enhanced monitoring provides more detailed I/O metrics; for more information, see Enhanced Monitoring.

  • 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:

  • Maximum channel bandwidth is DB instance class dependent.

  • You can't decrease storage allocated for a DB instance.

  • While Provisioned IOPS can work with I/O sizes up to 256 KB, most databases do not typically use such large I/O. 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.

  • 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 is constrained by the resource that is consumed first. That resource might 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 might 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, and amount of IOPS provisioned (if any). Typical scale storage time is under 24 hours, but can take up to several days in some cases. During the scaling process, the DB instance is 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 is converted at approximately 3,000 IOPS, while the remaining data is converted at the base performance rate of 100 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. The following are the storage size ranges for General purpose (SSD) DB Instances:

  • MySQL, MariaDB, and PostgreSQL DB instances: 20 GB–6 TB

  • SQL Server Enterprise and Standard editions: 200 GB–16 TB

  • SQL Server Web and Express editions: 20 GB–16 TB

  • Oracle DB instances: 20 GB–6 TB

General purpose (SSD) storage can deliver single-digit millisecond latencies and the ability to burst to 3,000 IOPS for extended periods of time. Between a minimum of 100 IOPS (at 33.33 GiB and below) and a maximum of 10,000 IOPS (at 3,334 GiB and above), baseline performance scales linearly at 3 IOPS per GiB of volume size.

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. Volumes earn I/O credits at the baseline performance rate of 3 IOPS per GB of volume size. For example, a 100 GB SSD volume has a baseline 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, 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 is converted at approx. 3,000 IOPS, while the remaining data is converted at the base performance rate of 100 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 100 1,862 54,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:

Copy
(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. Provisioned IOPS storage is optimized for online transaction processing (OLTP) workloads that have consistent performance requirements. Provisioned IOPS helps performance tuning.

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.

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 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
MariaDB 1000–30,000 IOPS 100 GB–6 TB 3:1–10:1
Microsoft SQL Server, Enterprise and Standard editions 1000–20,000 IOPS 200 GB–16 TB 1:1–50:1
Microsoft SQL Server, Web and Express editions 1000–20,000 IOPS 100 GB–16 TB 1:1–50:1
MySQL 1000–30,000 IOPS 100 GB–6 TB 3:1–10:1
Oracle 1000–30,000 IOPS 100 GB–6 TB 3:1–10:1
PostgreSQL 1000–30,000 IOPS 100 GB–6 TB 3:1–10:1

The ratio of the requested IOPS rate to the amount of storage allocated is important, and depends on your database engine. For example, for Oracle, the ratio should be between 3:1 and 10:1. You can start by provisioning an Oracle DB instance with 1,000 IOPS and 200 GB storage (a ratio of 5:1). You can then scale up to 2,000 IOPS with 200 GB of storage (a ratio of 10:1). You can scale up to 30,000 IOPS with 6 TB (6000 GB) of storage (a ratio of 5:1), the maximum for an Oracle DB instance.

You can modify an existing Oracle, MySQL, or MariaDB DB instance to use Provisioned IOPS storage. You can also 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 more information about pricing, see Amazon RDS Pricing.

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 can 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 is less than the provisioned IOPS rate.

Each page read or write action 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.

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 IOPS Dedicated EBS Throughput (Mbps) Maximum 16k IOPS Rate** Max Bandwidth (MB/s)**
db.m1.large 500 Mbps 4000 62.5
db.m1.xlarge 1000 Mbps 8000 125
db.m2.2xlarge 500 Mbps 4000 62.5
db.m2.4xlarge 1000 Mbps 8000 125
db.m3.xlarge 500 Mbps 4000 62.5
db.m3.2xlarge 1000 Mbps 8000 125
db.r3.xlarge 500 Mbps 4000 62.5
db.r3.2xlarge 1000 Mbps 8000 125
db.r3.4xlarge 2000 Mbps 16000 250
db.r3.8xlarge * * *
db.m4.large 450 Mbps 3600 56.25
db.m4.xlarge 750 Mbps 6000 93.75
db.m4.2xlarge 1000 Mbps 8000 125
db.m4.4xlarge 2000 Mbps 16000 250
db.m4.10xlarge 4000 Mbps 32000 500

* 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.