Boosting Your Amazon RDS Performance: RDS Proxy, Multi-AZ, & Read Replicas Explained

There is a wealth of features that Amazon RDS has to offer but those who use the service fail to fully leverage all these features for various reasons, one of them being, they are not aware of the said features. My goal with this article is to bring you up to speed on the some of the amazing features of Amazon RDS. Features that if probably implemented can boost performance in your infrastructure and your business at large. The feature we will focus on are: RDS Proxy, RDS Multi AZ and RDS Read Replicas. So without further ado, let's go!!

RDS Proxy

Picture this: When you develop a serverless application using AWS Lambda for example, the application usually has many functions each with a different task to perform. Now imagine each instance (invocation) of these functions creating a connection to your RDS database i.e. one database connection per function invocation. This doesn't seem like a problem if you application has just a couple of functions creating and closing connections to the database. When you application has more functions creating even more connections within a short span of time, this can take a hit on the performance of your database as creating and closing connections uses the CPU and Memory of the database instance. When this happens, your application can take longer to process tasks as the database is burning up a lot of resources to manage connections. Thank Goodness there is a solution to this limitation.

To manage connections to your database and reduce load, you can put a proxy layer between your database and the application accessing it. The easiest way to implement this service within your AWS infrastructure is by using RDS Proxy, a managed service serving as a middleman between your application and your database. This service is built to manage, reuse as well as share database connections without needing you the developer to have to write code for that. In addition to this, it improves database security and application availability.

RDS Proxy improves security by enabling you to enforce the use of IAM credentials when connecting to the database instead of just relying on database credentials in your code. It also integrates nicely with AWS Secrets Manager if you want to manage database credentials in a central location and prevent having to hard code them. In terms of availability, if there is an issue with your current primary database, RDS proxy is able to automatically connect to a new database instance and then reroute new connections to this new instance. RDS Proxy is recommended for workloads that have unpredictable traffic, frequent connections or workloads that keep idle connections to ensure a quick response from the database.

RDS Multi-AZ

As you might have guessed already, Multi-AZ means Multi Availability Zone, a feature that is widely used to ensure resiliency and business continuity. Now let's look at what it actually means ( i.e. how it works) in the context Amazon RDS.

When you configure or enable this feature on your RDS database instance, a secondary replica of that database is created in another AZ within the same region as the primary database instance.

Before I continue, I want you to keep in mind that the RDS Multi AZ feature is not for creating replicas that you can offload read traffic to. The feature is exclusively for ensuring the availability of your database.

When you enable the Multi-AZ feature, replication from the primary to the secondary database instance happens synchronously. However, the RDS Multi-AZ configuration depends on the database engine being used. If the database engine is either, PostgreSQL, MariaDB, MySQL or Oracle, RDS uses a failover mechanism. Let's examine what this means in practice.

If a primary database instance running any of the database engines listed above is in any of the following scenarios namely: patching maintenance, database instance class modification, AZ failure, instance reboot failover, or host failure, RDS initiates an automatic failover to the secondary instance. It updates DNS records to point to the secondary instance (replica). This process takes between 60-120 seconds depending on the size of the database, its transactions and activity at the time of failover. An RDS failover will trigger an event that will be recorded when the failover completes.

When your database is running on the SQL Server engine, Multi-AZ is attained by using a mechanism called SQL Server mirroring. It is like the failover mechanism we just examined as mirroring still creates a secondary replica of the database in another AZ to ensure the resiliency and fault-tolerance of your database. With mirroring however, both the primary and secondary (mirror server) use the same endpoint. During a failover event, the physical network address of the primary database is transferred to the mirror database.

Aurora implements multi-AZ in a different way from the others as well. Aurora database clusters are already fault-tolerant by default as they are designed to maintain data consistency and withstand the complete failure of an AZ. This default fault-tolerance is achieved by copying and replicating data across different instances in different AZs within the same region. Aurora can then automatically failover to any of the replicas when need arises. The automatic failover process can sometimes take up to ten minutes. To avoid this potential ten minutes or more of downtime, you can proactively provision your RDS database cluster to be Multi-AZ. With Aurora, you can provision up to 15 replicas, assigning a different priority to each to determine which of them is promoted to be the primary in the event of a failure of your primary database.

Time to move on to Read Replicas.

Read Replicas

Before we go further, you have to keep in mind that read replicas are NOT used as used as secondary instances for your database in the event of a failure. Instead, they are for offloading read traffic from your primary database in an effort to boost performance. So in essence, they are read-only replicas and any attempt to write data on these replicas will fail.

To show you how important read replicas can be, let's examine an example scenario: Imagine a company whose analytics department has to perform frequent analysis on the data residing in their databases. When tasks like these are being performed, your database will probably take a hit on its performance. To solve this issue, you can offload the read traffic from the analytics application to a read replica thereby preserving the primary database's performance.

When you enable Read replicas, a snapshot is taken of your database and if you have multi-AZ configured, the snapshot is taken from the secondary database to further preserve the performance of the primary database. When you configure read replicas, data is copied from the primary database to the read replicas asynchronously. Read replicas are only available for MySQL, MariaDB and PostgreSQL database engines. For an updated list of the new database engines that support read replicas, check the appropriate AWS documentation.

Conclusion

It is often said that if you don't apply any knowledge you have gained, the knowledge quickly becomes worthless. In essence, knowledge is power only when you put some action to it. With that, I will like to implore to not hesitate to use any of these features when need for any of them arises. As we have seen, they have the potential to boost performance, ensure resiliency and availability and inherently ensure business continuity. If too many connections are continuously being opened and closed on your RDS database, consider RDS proxy. If you want to ensure resiliency in the event of a failure, consider enabling multi-AZ and last but not least, if you want to boost performance of your primary database, consider creating read replicas and then move your read traffic to these read replicas. Thank you for staying with me from start to finish. Good luck in all your endeavors.