Cost-effective disaster recovery for Amazon Aurora databases using AWS Backup

You may have stringent regulatory compliance obligations that require an effective multi-Region disaster recovery (DR) plan to mitigate a Region-wide disaster. AWS offers multiple methods to meet these needs, taking into consideration different factors such as recovery time objective (RTO), recovery point objective (RPO), and costs. In this post, I focus on how to keep costs low while meeting the regulatory compliance obligations of a cross-Region DR strategy for Amazon Aurora databases.

AWS offers an array of purpose-built database engines, including relational, key-value, document, in-memory, graph, time series, and ledger databases. When it comes to traditional applications with relational databases on the backend, customers choose Amazon Aurora and Amazon Relational Database Service (Amazon RDS). Aurora is a MySQL and PostgreSQL-compatible relational database built for the cloud, which combines the performance and availability of traditional enterprise databases with the simplicity and cost-effectiveness of open-source databases. Amazon RDS is a managed service that supports the MySQL, SQL Server, PostgreSQL, MariaDB, and Oracle database engines.

Planning your DR strategy

RTO and RPO metrics are important when designing a DR strategy. RTO represents how long it takes to return to a working state after a disaster, and RPO represents the amount of data (in time units) you could lose when a disaster happens.

Using AWS Backup for a cross-Region snapshot copy

If RTO and RPO requirements are less stringent, using a cross-Region snapshot and restore is a cost-effective cross-Region DR strategy to comply with regulatory compliance obligations. You can create snapshots of your source Aurora databases and copy them to a supported AWS Region based on a schedule of your choice using AWS Backup.

AWS Backup offers a cost-effective, fully-managed, and policy-based service that enables you to copy snapshots to a different Region without having to worry about writing custom scripts and maintaining them. In addition, AWS Backup can also leverage AWS Organizations to implement and maintain a central view of backup policy across resources in a multi-account AWS environment.

To start using AWS Backup for managing a cross-Region snapshot copy, create a scheduled backup plan. You can choose pre-existing templates for the backup plans or build your own plan. Building a new plan from the scratch gives you the flexibility to choose backup windows closely aligning with your RTO and RPO requirements, making use of cron expressions. Make sure you choose a schedule that also aligns with the size of your database. The larger the database, the larger the time it takes to create the snapshot and copy it to a different Region.

To enable a cross-Region backup copy, you need to make sure you choose the destination Region in the Generate Copy section of the backup plan. You can also choose a backup vault of your choice in the destination Region. If your DR strategy requires copying the snapshots to a different backup vault in a different AWS account in a different Region, AWS Backup gives you that flexibility as well. However, AWS Backup needs permissions to access the external account to copy to your backup.

After you create the plan, assign the database resources to the backup plan. You can use tags to assign the resources to the backup plans for simplicity.

Snapshots are charged for their storage along with the cross-Region data transfer costs. To estimate your costs, see AWS Backup pricing.

Amazon Aurora backs up your cluster volume automatically and retains restore data for the length of the backup retention period. Aurora backups are continuous and incremental so you can quickly restore to any point within the backup retention period. The copies of Amazon Aurora snapshots are always full. Depending on the Regions involved and the amount of data to be copied, a cross-Region snapshot copy can take hours to complete and will be a factor to consider for the RPO requirements. You need to take this into account when you estimate the RPO of this DR strategy.

If you have strict RTO and RPO requirements, you should consider a different DR strategy, such as Amazon Aurora Global Database .

Using Aurora Global Database

Aurora Global Database is designed for globally distributed applications, allowing a single Aurora database to span multiple AWS Regions. It provides disaster recovery from Region-wide outages and enables low-latency global reads by allowing reads from the nearest Aurora cluster.

Aurora Global Database uses the dedicated infrastructure in Aurora’s purpose-built storage layer to handle replication across Regions. Dedicated replication servers in the storage layer handle the replication, which allows you to meet enhanced recovery and availability objectives without compromising database performance.

Aurora Global Database provides the following benefits:

• Fast global failover to secondary Regions, typically up to a few minutes, which helps achieve a low RTO
• Low replication lag across Regions, typically less than 1 second, which helps achieve a low RPO
• Replication performed by Aurora Global Database has no performance impact on the primary DB cluster

Aurora Global Database allows you to achieve good RTO and RPO because of its design, which employs physical storage-level replication. The secondary Region instance of the global database doesn’t replay data-modifying statements. Instead, it performs continuous parallel recovery at the storage level in the secondary Region, enabling it to achieve sub-second latency. This also reduces replication overhead on the primary. With Aurora Global Database, you pay for compute, storage, and replicated write I/O in primary and secondary Regions, along with the data transfer charges from the primary to secondary Region. To Summarize, Aurora Global database can be configured to run nodes in the destination region which would help achieve a better RTO and a faster DR. You can also run the Aurora Global database without a node in the destination region, but that would result in a longer RTO as you would have to spin up a new instance during a Disaster. Carefully estimate the strategy based on your DR goals and pricing. To estimate your pricing, see Amazon Aurora Pricing.

Testing your cross-Region DR strategy

A good DR strategy needs to be tested to make sure it meets the RTO, RPO, and cost requirements, and any regulatory compliance obligations. Regular testing of your DR strategy helps you identify potential issues or gaps and take corrective action to stay prepared for unforeseen events. For Amazon Aurora Global Database we have recently launched managed planned failover which can be utilized for testing.

Conclusion

In this post, I explained how to use AWS Backup to create a cross-Region DR strategy for your Amazon Aurora database. The AWS backup based approach is highly cost-effective, employs a backup and restore strategy, and can be designed to comply with cross region backup regulatory requirements. I also explained Aurora Global Database, an Aurora feature which can be utilized when you have strict RTO and RPO requirements.
We welcome your feedback and comments.

About the author

Harish Shenoy is a Senior Technical Account Manager for AWS Enterprise Support. He has been working with various Database technologies for more than a decade . He is a great advocate of automation and has designed and Implemented multiple Database automation tools in his career. He works with Enterprise customers to design, implement and support complex cloud infrastructures. He is a sports enthusiast who enjoys playing Cricket, Ping Pong, Badminton and Tennis . He spends his free time with his wife and a daughter traveling and exploring different places.