Restore Amazon DynamoDB backups to different AWS Regions with custom table settings

Amazon DynamoDB backup and restore provides simple, fully automated features to create continuous and on-demand backups of your DynamoDB tables and then restore data from those backups. With point-in-time recovery (PITR), you can create continuous backups of your DynamoDB table data. DynamoDB can back up your data with per-second granularity and restore to any given second in the preceding 35 days. We built PITR to help protect you against accidental writes or deletes. You also can use on-demand backups to create full backups of your DynamoDB tables. On-demand backups are suitable for long-term retention and archiving, and they can help you to comply with regulatory requirements.

To enable you to configure different table settings when you restore data from a DynamoDB backup, we have introduced multiple new restore features. In this blog post, I explain the new features and show how to use them.

The new DynamoDB restore features explained

You now can perform the following tasks when you restore data from a DynamoDB backup:

• Restore backup to a new table in a different AWS Region from where the source backup resides. Being able to perform cross-region restores can help you to meet your multi-regional compliance and regulatory requirements, and to develop a disaster recovery and business continuity plan.
• Exclude some or all local and global secondary indexes from being created with a restored table. Restores can be faster and more cost efficient when you choose to exclude secondary indexes from being restored.
• Change the billing mode on your table (on-demand capacity mode or provisioned capacity mode).
• Modify provisioned capacity settings, if applicable.
• Update the encryption key on the restored table (AWS owned CMK, AWS managed CMK, or customer managed CMK).

You can modify the settings of a restored DynamoDB table with a few clicks in the AWS Management Console, a simple API call, or the AWS Command Line Interface (CLI). You can restore tables from a few megabytes to hundreds of terabytes of data, with no impact on the performance or availability of your production applications.

Let’s see how you can use some of these new restore features.

Start by enabling PITR

In order to test a restore, I first need a backup. Luckily, DynamoDB backs up tables instantly. I start by enabling PITR on a table. In this case, I am using the US East (Ohio) Region. However, this feature works in any of the AWS Regions. PITR continuously backs up your database and protects from application-driven corruption or user error.

To enable this feature by using the DynamoDB console, I navigate to the table and choose the Backups tab. Then for Status, I choose Enable to turn on PITR. Alternatively, you could turn on continuous backups via the UpdateContinuousBackups API call.

After I enable continuous backups, I can see the Earliest restore date and Latest restore date. I can restore my table to any point in this recovery window.

Restoring with custom table settings

Now let’s say some critical data is accidentally deleted from a table. Restoring the table to a specific point in time just before the data was deleted is easy. In the console, I navigate to the Backups tab for the table and then click Restore to point-in-time.

I can specify the time of the restore (say a few seconds before the accidental deletion occurred) and a name for the table I’m restoring. For the table name, I enter ProductCatalog-RestoredTable.

For this use case, let’s say you don’t need the restored table to include local and global secondary indexes. I can choose Restore without secondary indexes. Restores can be faster and more cost efficient when secondary indexes are excluded from restored tables.

Now in order to investigate the deleted data and any possible corruption, let’s assume that I need to collaborate with a team in Frankfurt. I can easily restore to a specific point in time and create a copy of the table in the Frankfurt team’s local AWS Region. In this case, I choose the EU (Frankfurt) Region.

All customer data stored in DynamoDB is fully encrypted at rest. DynamoDB encrypts all of your data transparently, and offers three modes of data encryption: AWS owned CMK, customer managed CMK, or AWS managed CMK. For this use case, I choose the DEFAULT (AWS owned CMK) encryption mode for the restored table.

I’m all set, so I click Restore table.

I have submitted my cross-region restore request and I can navigate to the restored table by clicking View table in the EU (Frankfurt) Region.

I also can use the RestoreTableToPointInTime API call to selectively exclude some or all secondary indexes, change the billing mode on the table (on-demand capacity mode or provisioned capacity mode), and modify the provisioned capacity settings on the restored table. For more information, see Restoring a DynamoDB Table to a Point in Time and Restoring a DynamoDB Table from a Backup.

Summary

In this blog post, I have described the new restore features for DynamoDB and how to use these features in the AWS Management Console. These new features are available in all AWS Regions where DynamoDB backup and restore is supported. When you restore table backups as new tables in other AWS Regions, you pay only for the data you transfer out of the source Region and for restoring backups as new tables in destination Regions. For backup and restore pricing and AWS Region availability, see Amazon DynamoDB pricing.

About the Author

Mazen Ali is a Senior Technical Product Manager on the Amazon DynamoDB team.