Why does my Amazon DynamoDB table restoration take a long time?

Resolution

When you restore your DynamoDB table from a backup, the restore process usually takes less than an hour to complete. The restore time is related to the configuration of your table, such as the table size, the number of underlying partitions, and other related variables. When you plan for disaster recovery, it's a best practice to regularly document the average restore completion time. Then, determine how these completion times affect your overall Recovery Time Objective.

The time taken for DynamoDB to restore a table differs based on several factors and isn't necessarily linked to the size of the table. If your table contains data with significant skew and secondary indexes, then the restoration time might increase. When the restoration process is in progress, the table status is Restoring. When the restoration process is completed, the table shows the status as Active. All backups in DynamoDB work without consuming any provisioned throughput on the table.

Note, however, that it isn't possible to calculate the table restoration time. When you restore a DynamoDB table from its backup, review the following information:

• The time it takes to restore the table isn't always directly correlated to the size of the table.
• When you perform a point-in-time recovery of a DynamoDB table, the restoration takes at least 20 minutes no matter the size of the table. After you restore the table, DynamoDB needs time to provision all the resources to create the new table and initiate the restore process. Then, DynamoDB can copy the actual data.
• If the data in the table is evenly distributed, then the restoration time is proportional to the largest single partition by item count.
• Data skewness can occur when one partition key has significantly more data than the other partition key. If the data is skewed, then the restoration time might increase because of potential hot keys and throttling. For example, if your table's primary key uses the month of the year to partition, then review how the data is distributed. If the majority of your data is from December, then you have skewed data.
• To increase the efficiency and speed of a table restoration, exclude the creation of secondary indexes.
• You can't compare restoration times for two different tables with different schemas and data. The restoration time for a table depends upon the data skewness on the partition level.

Note: When the restoration is in progress, don't modify or delete the AWS Identity and Access Management (IAM) policies that grant the entity permission to restore. If you do modify or delete the policies for the IAM entity, then unexpected behavior can result. For example, suppose that you remove write permissions for a table while that table is being restored. In this case, the underlying RestoreTableToPointInTime or RestoreTableFromBackup operation can't write any restored data to the table. IAM policies that involve source IP restrictions to access the target restore table can cause similar issues.

For backups that are encrypted with an AWS Key Management Service (AWS KMS) managed key or a customer managed key, monitor your key. If you turn off or delete the key when a restore is in progress, then the restore fails. After the restoration is complete, you can change the encryption key for the restored table and turn off or delete the old key.

Related information

Using On-Demand backup and restore for DynamoDB

Using DynamoDB backup and restore