So far in this series, we have been looking at RDS and some of its features, focusing on security and monitoring. We’ve talked about how to secure both access to your database and the data within it, but also how metrics and alarms can help you monitor databases and automate reactions to various events. Here, in the final installment of the series, we’ll be moving on to Multi-Availability Zone configuration, a crucial option for any production database, and showing how it can be used to increase the availability and durability of your RDS instances making them more tolerant to failures.
When deploying your RDS instances, one of the options you may enable is “Multi-Availability Zone.” If you choose to not enable this option, your RDS will be deployed in only one availability zone. Having your database contained in a single location is the equivalent of a no-fault tolerance or high availability, leaving your business susceptible to loss if failure occurs.
This approach is acceptable for proof-of-concept testing or development environments, especially if trying to minimize the cost but should be avoided when it comes to your production workloads for which Multi-AZ deployment is a must. So how does it work?
Multi-AZ RDS Deployments
Multi-AZ RDS deployments work by automatically provisioning a standby replica of your database in another availability zone within a region of your choice. Replicas are never created in any region other than the one you’ve chosen in order to keep the latency at a minimum and also due to compliance issues.
RDS synchronously replicates the data to a standby replica, but keep in mind that a standby replica can’t serve read requests. Instea, they are used to provide data redundancy and minimize latency spikes during backups. If you need to offload heavy read traffic, consider RDS Read Replicas. This failover process for Multi-AZ deployments is used for most database engines running on RDS, including MySQL, PostgreSQL, MariaDB, and Oracle.
Fortify your data backup strategy across every critical dimension—from security to disaster recovery to cost savings.
- Efficiency + Optimization
- Security + Control
- Orchestration + Visibility
SQL Server, on the other hand, relies on Server Mirroring, while Amazon Aurora works a bit differently, something we’ll focus on later in the article. With Multi-AZ enabled, if the primary database becomes inaccessible (let’s say there was a hardware failure or some network problems), RDS performs a failover to a standby replica by retargeting the database endpoint. This process takes only a minute or two and requires no work on your end, allowing traffic to continue to flow automatically. One thing to consider when using Multi-AZ deployment is the performance implication on your database.
Compared to Single-AZ, it may increase latency for writing and committing due to the synchronous data replication occurring between the primary database and the standby replica. Also, if the failover does occur, you may have a slight change in latency as your traffic will move to and from a different AZ.
You can enable Multi-AZ configuration both during the provisioning of the database, but also later by modifying it, in which case RDS takes a snapshot of the primary database and restores it into another availability zone. Keep in mind, though, that this can cause a significant performance impact, especially for larger databases, so plan ahead and make sure you enable this option during the provisioning of the database instance, if possible.
Amazon Aurora Failover Strategy
Amazon Aurora works a bit differently compared to other database engines used within RDS. When you create an Aurora instance (you can choose MySQL or the PostgreSQL edition), you are actually provisioning an entire database cluster behind the scenes, spanning multiple availability zones.
An Aurora cluster consists of a primary instance and two secondary nodes (though it can have up to 15) which are actually read replicas containing up-to-date copies of all the data. If your primary instance becomes inaccessible for any reason, these read replicas will be your failover targets, and this failover process is very fast, reducing the impact on your production to a minimum.
Final Note
With one click to enable it, Multi-AZ configuration for RDS allows you to maintain a highly available and fault-tolerant database infrastructure, making sure your business’ critical data does not rely on a single point of failure and is always accessible. If something should happen to or affect your primary database, the failover process only takes a few minutes, but if that is not enough for your production requirements Amazon Aurora offers even lower downtime by providing multiple read replicas that are ready to take over at any time.
With encryption to secure both in transit and at rest data, monitoring to make sure you can always keep an eye on the performance of your database instances, and Multi-AZ configuration to keep your environment up and running at all times, RDS is certainly well-protected. If you are planning to run a database in the cloud, be sure to check out this AWS service.
Introducing N2WS Backup & Recovery
Whether you are a small business just starting out on Amazon Web Services or an enterprise with a significant workload on the cloud, N2WS Backup & Recovery will give you the backup and recovery features that fit the needs of your environment.
With N2WS, you will be able to backup your RDS databases, EC2 instances, independent EBS volumes, RDS Aurora clusters and Redshift clusters as often as needed and recover them far more quickly than with traditional backup solutions.
Using N2WS you can create backup policies and schedules as often as you like, and generate useful reports and notifications so you can sleep at night. Best of all, you can even try out N2WS Backup & Recovery for free for 30 days! N2WS takes just a few minutes to install which means you can start backing up your workload in no time.
