High Availability and Scalability in Amazon RDS
Please use the menu below to navigate the article sections:
One of the key reasons why customers use AWS for their applications is because of the ability to maintain a high degree of availability across each key area of their architecture. Depending on the customer’s deployment, there are a number of different ways in which high availability and scalability can be enabled. In this AWS tutorial, you’ll learn how to enable highly available, scalable databases on RDS. You’ll find detailed instructions on how to follow along in your AWS account.
Quick refresher on RDS
RDS stands for Relational Database Service, and this is AWS’s managed collection of a number of different SQL databases, which have all the functionality of the database you choose, coupled with the agility and high availability you get from utilizing the cloud. The database engines supported currently stands at MySQL, Oracle, Microsoft SQL Server, Aurora, PostGreSQL and MariaDB.
Whilst RDS is highly available, and scalable in many ways by default, we can ensure this is maximized by taking some key steps.
High Availability on AWS means avoiding downtime – and is measured in downtime per month. There are multiple different ways of increasing availability, both by re-architecting your existing application, and also by adding additional features to your current solution. With those key definitions covered, let’s look into how to enable high availability in RDS by discussing Multi-AZ deployments.
It is as easy as a few clicks of a button to provision a Multi-AZ DB instance in the MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server Amazon iterations of RDS. RDS in fact will automatically create a standby DB instance, and then replicate any data from the primary DB to the standby database asynchronously.
If you have already created your database, you can still enable Multi-AZ easily in the console, by following the steps below.
In the photo below, there’s an example RDS MySQL Database instance provisioned in US-East 1b. 
If you scroll to the right of this instance, you can see that ‘Multi-AZ’ is not enabled. This is however easy to change.
When you see the instance’s status is ‘Available’, you can select the instance, and select the ‘Modify’ button to change its configuration.
Under Availability and Durability, select the second option. Doing this provisions a standby Multi-AZ instance which mirrors your current RDS database.
Then click continue and on the next page, choose to apply the changes immediately (for the benefits of this demonstration).
It will take up to 10 minutes for the change to propagate, and you will see that the instance status will change to Modifying.
You will now see that multi AZ is enabled!
We can now test a simulated failure of an entire AZ, directly in the console. You select the instance (even though it is Multi-AZ, we still see it as one DB instance in the console), and select under actions ‘Reboot’, then select the box that says ‘Reboot with failover’.
We can see a synopsis all of of these events under the Events tab on the left hand side of the page in the RDS console.
What happened in the background is the rebooting with failover simulated the failing of an Availability Zone. The Multi-AZ instance became the primary instance during this time, taking over for the offline master database. When the old master instance finished rebooting, it came back online but this time as the standby database – showing how behind the scenes AWS look after the Multi-AZ configuration to ensure you have as little downtime as possible built in.
Scaling in RDS
For starters, a Read Replica can be used to aid in the scaling of your database by taking Read load of the primary database, by acting as a Read only counterpart of the main database instance. Read Replicas allow you to elastically scale out when using read heavy workloads, and can provide a notable performance increase also.
You can scale both horizontally and vertically in RDS, with Read Replicas being an example of horizontal scaling.
Let’s talk about how to enable Read Replicas, and how to promote a Read Replica to a master standby instance.
Select the instance, and click ‘Create read replica’ under actions.
You can then choose to place your Read Replicas in any valid region of your choosing, which has its own benefits.
Scroll down to the end and click ‘Create Read Replica’ and you are done.
You can now see the Read Replica is getting created, with no downtime to the application, only a slight CPU increase on the main database.
Read Replicas can also be easily promoted to a master standby instance directly in the console.
However, when promoting a Read Replica you should stop transactions on the main database. Otherwise, there is a high likelihood that the Read Replica will not have all the transactions committed to the master DB Instance.
After a few minutes, you should see a second database instance, side-by-side in your management console ready to be used if your main DB instance fails.
How vertical scaling works in RDS
With vertical scaling in RDS, you can simply choose one of the many instance sizes with a push of a button – by using the modify button we saw earlier. You can also change the storage type, as well as allocated storage for the database instance in the same window.
It is worth noting that there is minimal downtime when you are scaling up when using a Multi-AZ configuration vs a single AZ database. This is because the standby database will get upgraded first, then a failover will occur in the background of the newly sized Database. In a single AZ configuration, the database will simply not be available during the scaling operation.
AWS Training Courses
Amazon RDS features in several of our AWS certification training courses including the following:
