AWS::DynamoDB::Table - RestoreArn

[lwoggardner]

1. AWS::DynamoDB::Table-RestoreArn

2. Scope of request

AWS::DynamoDB::Table supports PointInTimeRecoverySpecification but it is not possible to gain control of a restored table via Cloudformation.

3. Expected behavior

It should behave similarly to EBS and RDS restores from SnapshotIds

In Create, it should validate the properties of the RestoreArn (DescribeBackup) are compatible with the other cloudformation properties of the table,, and then create a new table using RestoreTableFromBackup. After the restore is complete, the table should be updated to the new property specifications as per a normal Update.

Updating the RestoreArn attribute should cause Replacement.

4. Suggest specific test cases

Standard case Create.

• Create a DynamoDB Table and take a manual backup. Record the BackupArn
• Create a stack containing an AWS::DynamoDB::Table with RestoreArn property set to above BackupArn, and all other properties compatible with the original table.

Should Create successfully, via call to RestoreTableFromBackup.

Standard case Update.

• Create a stack with AWS::DynamoDB::Table without RestoreArn or TableName and minimal required properties
• Take a manual backup and record the BackupArn.
• Update the stack with RestoreArn

Should Update successfully, creating a new table via RestoreTableFromBackup and deleting the old table (normal replacement behaviuor).

Uncommon case. Restore with Change to TableName

should succeed

Uncommon case. Restore with valid Changes

In addition to RestoreArn, also add GlobalSecondaryIndexes, change other "no interruption properties) BillingMode, Capacity, Streams,Tags, TTL - should behave as though create with the restore specification and immediately update with other properties.

should succeed.

Failure case. RestoreArn set with TableName unchanged.

Since restoreArn required replacement, updating it without changing an explicitly set TableName should fail.

Failure case. Restore with other "replacement changes" - should fail.

Set LocalSecondaryIndexes, AttributeDefinitions, KeySchema to be different from those in the backup. Expect failure to create, or update before any call to RestoreBackup is made.

5. Helpful Links to speed up research and evaluation

https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeBackup.html https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_RestoreTableFromBackup.html

6. Category (required) - DB

[PatMyron]

CloudFormation resource import supports AWS::DynamoDB::Table, so restored tables can now be CloudFormation-managed

[lwoggardner]

I am happy there is now a possibility to acheive the outcome via import resources. However, here is what I think is required to implement this using the new import feature via automation.

• use api to restore the table, with some kind of user input to select which indexes to exclude. Wait for the table restore to complete.
• create cfn template with deletion policy set to retain as placeholder for the table, and with properties set to match the table and indexes
• use the api to create the stack via changeset with import resources.
• Run changset via api and wait for completion.
• run drift detection to ensure restored table matches the template
• create final cfn template removing deletion policy and applying any updated properties
• run and wait for the cfn update to complete If anything goes wrong anywhere above make sure to delete the table and the imported stack resource.

That work and complexity (heavy lifting) should not have to be done by every customer when it could be implemented once and encapsulated in a property like it is for ebs and rds.

[Gtofig]

Any update on this? I think the restore story for DynamoDB tables managed via CFN/CDK is still overly complex.

[jakedaleweb]

+1 we would like this too so our RDS and Dynamo restoration strategies can match

[nepalibidur14]

+1 Any updates will be highly appreciated.