Amazon DynamoDB is a fully managed, Cloud-Native, NoSQL database service. It supports high availability, predictable performance with millisecond range latency, and multiple back-ups and recovery options for disaster recovery at scale.
This article focuses on Disaster Recovery in AWS and how DynamoDB supports it. It will also compare different approaches to give you a better understanding.
What is Disaster Recovery
In simple terms, Disaster Recovery is the ability to recover from an event that negatively impacts your operations. In software systems, these disasters can come from server failures, connection issues, database failures, etc. As developers, we should be well aware of the techniques to quickly recover from them and continuously maintain services to the users.
Disaster Recovery in AWS
AWS provides multiple options to handle disasters. We can group them into four categories based on cost and complexity.
- Backup & Restore - Create a backup and restore from it in a disaster.
- Pilot Light - Core pieces of the system will always run.
- Warm Standby - Always running a scaled-down version of a fully functional environment.
- Multi-site - Keeping multiple active copies of the infrastructure in different regions and availability zones.
Out of these four options, backup and restore pilot light and warm standby are active-passive approaches. Only one region will serve the traffic while the other is kept idle. Finally, multi-site is an active-active approach where all regions serve the traffic.
You can find a detailed comparison of the above four methods in the below chart:
How DynamoDB Disaster Recovery Works
Like all other services, AWS DynamoDB provides multiple Disaster Recovery options at your disposal. It uses the AWS multi-regional architecture to provide reliable and highly available services. In this article, I will discuss three strategies that can be used with AWS DynamoDB as Disaster Recovery options:
- Using global tables
- Point in time recovery
- On-demand backups
DynamoDB Global Tables
AWS DynamoDb global tables allow developers to create fully managed, multi-region, and multi-active databases for their applications. Global tables replicate your DynamoDB tables across multiple regions of your choice to ensure high availability and Disaster Recovery.
With AWS DynamoDB, you don't have to replicate database instances or spin up a new resource in case of a disaster. You can ensure that your application has a highly available database even if a complete AWS region fails.
You can easily create DynamoDB global tables using AWS Management Console or AWS CLI. First, you need to create a typical DynamoDB table with a primary key. This table will act as the first replica table.
After creating the table, select it from the DynamoDB table list and go to the Global Tables tab.
There, click the Create replica button. It will take you to a new screen where you can select regions to create table replicas.
It will take a few seconds to create the replica, and you can follow the same steps again to create more replicas of the table.
As you can see, DynamoDB global tables create multiple replicas of the same table in multiple regions. AWS considers all the replicas as a single unit. Therefore, when an application writes data to a particular table replica, DynamoDB will communicate that write command to all the replicas.
Point in Time Recovery
Point in time recovery is one of the backup methods provided by AWS DynamoDB.You don't need to worry about manually scheduling backups if you enable point-in-time recovery since it creates automatic backups continuously. In addition, you can restore data for up to 35 days using pointing time recovery by selecting the specific time in hours, minutes, or even seconds to restore.
Enabling DynamoDB point-in-time recovery through the AWS management console is pretty straightforward. You need to select the DynamoDB table from the tables list and navigate to the Backups tab.
You will see the current status point-in-time recovery and edit it by clicking the Edit button.
However, that's not the only way to enable DynamoDB point-in-time recovery. You can use the AWS CLI, DynamoDB REST API, or CloudFormation to enable it.
The example below shows how to enable DynamoDB point-in-time using AWS CLI.
AWS DynamoDB on-demand backups allow developers to create full backups of DynamoDB tables. This approach is mainly used for long-term retentions and archiving purposes. DynamoDB ondemand-backups can be created using the AWS backup service or DynamoDB itself.
Most importantly, the on-demand backup and restore process won't affect the application performance or API latencies. It scales as necessary and completes the backups in a short time regardless of the table size. In addition, all on-demand backups are cataloged, made discoverable, and retained until they are explicitly deleted.
To create or schedule an on-demand back, you need to go to the Backups tab from the DynamoDB service.
Then, click on the Create backup button. You will see two options: Create an on-demand backup and Schedule backups.
If you select the Create on-demand backup option, you need to select a table and configure some basic details.
If you select the Schedule backups option, you can either use a template or create one from scratch with your configurations.
I think now you understand the options provided by AWS DynamoDB for Disaster Recovery. However, before concluding, let's look at the cost of using each of the discussed options.
Amazon DynamoDB core features are billed based on usage. However, this does not include the cost for optional features like point-in-time recovery and on-demand backups. Also, creating multiple replicas of global tables doesn't have any upfront cost. You only have to pay for the resource usage.
So, the cost comparison is mainly between point-in-time recovery and on-demand backups. For both approaches, DynamoDB charges based on the size of each table.
For example, when you enable point-in-time recovery, DynamoDB monitors the size of tables throughout the month and decides the backup charges. Usually, it will cost you 0.20 USD per GB-month.
A similar approach is followed to measure the on-demand backup sizes as well. The final cost is decided monthly by continuously monitoring the size of on-demand backups throughout the month. Usually, warm backup storage will cost around 0.10 USD per GB-month, while cold backup storage costs 0.03 USD per GB-month.
Please note that the cost of the backups can be changed based on the region you choose.
Backup Using Dynobase
In addition to the above-discussed methods, you can create DynamoDB table backups using Dynobase. This approach is not directly connected to AWS. But, it is very cost-effective compared to AWS solutions.
There are 2 methods to backup DynamoDB tables using Dynobase:
- Back up directly to AWS S3 buckets.
- Export to JSON files - This approach allows developers to move their backups outside of AWS.
To create backups using Dynobase, first, you need to select your table. Then click the Export button in the bottom right corner. It will show you 3 options: Selection, Current Results, and Whole Table. This is another highlighted feature of Dynobase, and you can backup a subset of your table or the whole table based on the requirement.
Then, you need to select the backup's destination: an S3 bucket or a local file.
Finally, click the Export Table button to create the backup.
This article discussed what Disaster Recovery is and the Disaster Recovery options available in Amazon DynamoDB. Overall, point-in-time recovery and on-demand backup options act as active-passive approaches, and using them can lead to downtimes as we have to restore them manually. But, they are low-cost options and suitable for long-term data retentions.
On the other hand, using DynamoDB global tables can help developers build highly available applications and recover instantly from disasters without the users noticing its effect.
If you need to move your backups away from AWS or you're looking for a more cost-effective method, you can use Dynobase to create backups.
I hope you found this article interesting. Thank you for reading.
© 2022 Dynobase