Boost Your AWS RDS Performance by Crossing the 400GB Hidden Threshold

This post uncovers a hidden AWS RDS performance feature that can significantly enhance your database's speed and efficiency. Learn how AWS provisions multiple EBS volumes for databases larger than 400GB, and how to leverage this to optimize your database performance.

Cover for Boost Your AWS RDS Performance by Crossing the 400GB Hidden Threshold

9 min read


There’s a little-known feature in AWS RDS that significantly impacts your database’s performance. Did you know that once you cross the 400GB threshold, AWS provisions four EBS volumes instead of one? This gives you higher IOPS and throughput without any additional cost. In this post, we’ll dive into the reasons behind this decision, and I will share a real-world customer example to show you how you can leverage it to supercharge your AWS RDS performance.

Overview of Elastic Block Store (EBS) in RDS

Amazon RDS simplifies the setup, operation, and scaling of relational databases. Like the other services, AWS reuses other services like Amazon EC2 for database compute and EBS for block storage. Amazon EBS is the underlying storage used by RDS to ensure data durability and high availability. While RDS supports several database engines, and all of them rely on EBS for storage, this post covers the details for MariaDB, MySQL, and PostgreSQL only.

Types of EBS Volumes Used in RDS

AWS RDS primarily uses two types of EBS volumes:

  • General Purpose SSD (gp3 and gp2): These volumes are suitable for most workloads, offering a balance between cost and performance.
  • Provisioned IOPS SSD (io1 and io2): These volumes are designed for applications that are I/O intensive, and that benefit from a low latency and consistent throughput.

There is also an option for magnetic storage for backward compatiblity, but AWS discourages using it for new databases.

You also want in 95% of the cases default to use gp3 volumes, as they offer a good balance between cost and performance. Only in I/O intensive workloads (such as OLTP workloads), you should consider using io2 volumes. Keep in mind that the older generation. io1, is not recommended for new databases.

Why Exceeding 400GB Matters

When you exceed 400GB of storage for your RDS instance (in the case of MariaDB, MySQL, and PostgreSQL), AWS provisions four EBS volumes instead of one. This gives you higher IOPS and throughput, which translates to faster read/write operations and reduced latency, all without any additional cost.

In the next section, we will dive deeper into the technical ins and outs of how is this achieved.

Technical Deep Dive

If you’re wondering how AWS can provision multiple volumes for a single database instance, the answer is that it uses a feature called “volume striping”. This is a technique that distributes data across multiple volumes to improve performance and scalability.

Using a RAID 0 Array for Enhanced Performance

When AWS provisions four volumes once you cross the 400GB threshold, it configures RAID 0 across the volumes. RAID 0, also called volume stripping, will spread the data evenly across multiple volumes. This configuration allows the system to read and write data at the same time to all volumes, significantly improving performance. Since it splits all operations, the total performance is the sum of the individual volumes, and this applies to both IOPS and throughput.

One of the common misconceptions is that RAID 0 on EBS volumes is the same as a hardware RAID, but in the case of EBS volumes, the data durability does not decrease as it is also stored redundantly by Amazon. So you can get the advantages of better performance without sacrificing any potential data loss. RAID 0 performance also depends on the worst-performing volume in the array, but RDS already takes this into account and splits the volumes evenly.

In the next section, we will dive deeper into how this works and how you can leverage it to improve your RDS performance.

Boosting Baseline IOPS with gp3 Volumes

One of the benfits of the General Purpose gp3 volumes is that they allow you to configure the IOPS and throughput independent of the storage size, unlike the gp2 volumes. This means you have the flexibility to configure the storage performance depending on your need, and keep configuring it as your database usage increases.

gp3 Volumes and Their Baseline IOPS

General Purpose gp3 volumes have a baseline performance of 3000 IOPS and 125 MiB/s. But as we discussed in the previous section, you have to keep in mind that once you pass the 400GB threshold AWS will provision four volumes instead of one. This means that if your storage is more than 400GB, you will get 4 volumes with a baseline performance of 3000 IOPS and 125 MiB/s each, for a total storage perforamce of 12000 IOPS and 500 MiB/s.

If you need it, you can then provision additional IOPS up to 64000 IOPs, and throughput up to 4000 MiB/s. AWS will not let you provision performance if you are under 400GB on a single volume, so if you have a small database and need better performance, the first step is to increase the storage size to 400GB and then if you need more performance, you can provision more.

Benefits of Increased IOPS and Throughput for your Database

With increase IOPS, your database can handle more read and write operations every second; this means processing a query will take less time and the application will get a response faster. With the higher IOPS you also get reduced I/O latency, which also reflects on the speed of processing queries.

The increase throughput means you can read and write more data in a given time frame. This is especially important for data-heavy operations, such as analytic queries or large data imports/exports.

Constraints and Key Considerations

While gp3 volumes offer a lot of flexibility, it’s important to understand the constraints:

  • The maximum ratio of storage throughput to IOPS is 0.25 for all supported DB engines. This ratio of 0.25 means that for every 1 IOPS, you can have a maximum of 0.25 MB/s in throughput.
  • The maximum ratio of IOPS to allocated storage is 500 for all supported DB engines. This means that for every 1 GB of storage, you can have a maximum of 500 IOPS.
  • Storage autoscaling also adheres to these ratios.

CAUTION

Keep in mind that if you’re using a Multi-AZ DB cluster, you can’t configure the throughput value. AWS will automatically set the throughput value based on the IOPS that you provision.

For more details on managing capacity and performance, refer to the Amazon RDS documentation.

Real-World Case Study: Quadrupling Performance for a Fraction of the Cost

To illustrate the real-world impact of this hidden threshold, let me share a recent case study involving one of the clients I worked with at StratusGrid. This client is a big media and entertainment company that provides streaming services to its customers. They have millions of users and generate a lot of traffic and requests per second to their databases, and they use RDS.

The Challenge

The client was running multiple RDS instances, each with around 330-380GB gp2 volumes. During load testing, they were experiencing performance bottlenecks in some of the databases, with slow query responses and occasional timeouts. We have a goal to continously load test the platform and be able to handle more and more users, as the customer platform grows in users every single day. Their initial idea was to switch to more expensive instance types or change the storage to Provisioned IOPS (io1) volumes, both of which would have significantly increased their costs.

The Solution

After analyzing their needs, I recommended the switch to gp3, and increase their storage to 400GB for each instance. This minor change would trigger AWS to provision four EBS volumes instead of one, therefore quadrupling their I/O performance (both in IOPS and throughput).

We implemented the change during a low-traffic window, but the process was really straightforward and required no downtime at all. It might take a bit of time to complete performance optimization during which you have a little bit less performance, but it is really not that noticeable.

The Results

The results were immediate. When we ran load testing after the change, query response times improved by an average of 2-3x in some instances. Some read-heavy queries saw improvements of up to 4x. As expected, the baseline IOPS for each instance jumped from 3,000 to 12,000, providing much-needed headroom for peak traffic periods. The total throughput increased from 125 MiB/s to 500 MiB/s, significantly improving the speed of data-intensive operations. The storage cost increase was minimal—less than 15% per instance—while delivering a 300-350% performance improvement. This was far more cost-effective than upgrading instance types or switching to Provisioned IOPS volumes.

The Business Impact

This simple change allowed the client to postpone more expensive infrastructure upgrades by several months, allowing us to scale the whole platform without a significat cost impact. It also provided them with a more stable and responsive platform, improving customer satisfaction and reducing churn.

The success of this optimization strategy has led the client to adopt a policy of defaulting to 400GB+ volumes for all new RDS instances, ensuring they always benefit from the multi-volume performance boost.

Conclusion

After reading this post, now you know a hidden feature of RDS that can help you improve the performance of your databaes without any additional cost just by increasing the storage size to 400GB. Understanding the different EBS volumes and how they work will help you make better decisions moving forward in order to optimize your database performance. Using a RAID 0 array of EBS volumes under the hood to improve performance allows RDS to handle more I/O operations per second and read and write data faster, while keeping the data durability. I encourage you to leverage the flexibility of gp3 volumes to help you with your growing database needs.

If you have any questions or comments, please feel free to reach out to me on the contact form or schedule a call with me.


Share this post!