Why does my DynamoDB table restoration take a long time?

Short description

DynamoDB table restoration time depends on data distribution, partition count, and secondary indexes rather than table size alone. To improve restoration speed, exclude secondary indexes and address data skew in your table design.

Resolution

Understand DynamoDB restore time factors

The time DynamoDB takes to restore a table varies based on multiple factors and isn't always correlated with the size of the table. The following factors affect restoration time:

• Table data distribution across partitions
• Number and size of secondary indexes
• Data skewness across partition keys
• Whether you perform a point-in-time recovery (PITR) or on-demand backup restore

When you perform a PITR of a DynamoDB table, the restoration takes at least 20 minutes, regardless of the table size. DynamoDB provisions all the resources to create the new table and start the restore process before it copies the actual data.

If DynamoDB evenly distributes the data in your table, then the restoration time is proportional to the largest single partition by item count. You can't calculate the exact table restoration time in advance.

When the restoration is in progress, the table shows the Restoring status. After DynamoDB completes the restoration, the table shows the Active status.

Note: You can't compare restoration times for two different tables with different schemas and data.

Identify and address data skew

Data skew occurs when one partition key has significantly more data than other partition keys. If your data has skew, then the restoration time might increase because of potential hot keys and throttling.

For example, your table's primary key might use the month of the year to partition. If December contains most of your data, then you have skewed data. To reduce the effect of data skew on restoration time, redesign your partition key strategy to distribute data more evenly.

Reduce restoration time

To improve the speed of your table restoration, take the following actions:

• Exclude secondary indexes from the restored table. You can add indexes after the restoration completes. For more information, see Restoring a DynamoDB table to a point in time.
• Address data skew in your partition key design to distribute data evenly across partitions.
• Document your average restore completion time regularly. Then, determine how these completion times affect your overall Recovery Time Objective (RTO).

Protect IAM policies and encryption keys during restoration

Don't modify or delete AWS Identity and Access Management (IAM) policies that grant the entity permission to restore when a restoration is in progress. If you modify or delete these policies, then the underlying RestoreTableToPointInTime or RestoreTableFromBackup operation can't write restored data to the table. IAM policies that involve source IP restrictions for the target restore table can cause similar issues.

Your backups might use an AWS Key Management Service (AWS KMS) managed key or customer managed key for encryption. Don't turn off or delete the key when a restore is in progress. If you turn off or delete the key, then the restore fails. After DynamoDB completes the restoration, you can change the encryption key for the restored table and turn off or delete the old key. For more information, see Managing encrypted tables in DynamoDB.

Related information

Restore a table in DynamoDB

Enable point-in-time recovery in DynamoDB

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