DynamoDB: Global Table creation doesn't set retention policy for replica tables

[BalintLab]

Status

Investigating (Default)

What is the issue?

The level 2 Table construct creates global tables that are not in alignment with DynamoDB best practices (uses Table CFN resource + custom resources vs the GlobalTable CFN resource)

This poses a serious risk of deleting the replicas if their retain policy was set up on the construct:

const XRTable2_lvl2 = new Table(this, 'Table', {
   tableName: "XRTable2_lvl2",
   partitionKey: { name: 'id', type: AttributeType.STRING },
   replicationRegions: ['us-east-1', 'us-east-2', 'us-west-2'],
   billingMode: BillingMode.PROVISIONED,
});
XRTable2_lvl2.autoScaleWriteCapacity({
   minCapacity: 1,
   maxCapacity: 10,
}).scaleOnUtilization({ targetUtilizationPercent: 75 });
XRTable2_lvl2.applyRemovalPolicy(RemovalPolicy.RETAIN)

I used the above code to create my global tables. When I deleted the CF stack manually, root table was preserved as per removalpolicy, but all replicas were deleted.

This construct should adhere to dynamodb best practices and create a GlobalTable resource: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/V2globaltables_reqs_bestpractices.html

Reference:

• Documentation: https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk-lib/aws-dynamodb#amazon-dynamodb-global-tables

• Code: https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-dynamodb/lib/replica-provider.ts

Error message

No response

What is the impact?

If Global tables are created this way, the replica tables retention policy won't be set. This means, the replica tables can be accidentally deleted despite what the code snippet suggests

Workaround

No response

Who is affected?

Anyone creating global tables based on this doc using this library

How do I resolve this?

Customers could use the level 1 CFNGlobalTable constuct as a workaround: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_dynamodb.CfnGlobalTable.html

Related issues

No response

[peterwoodworth]

The replicas aren't created through Cfn, so this would need to be handled by the custom resource handler. Could potentially skip deleting some regions here

aws-cdk/packages/aws-cdk-lib/aws-dynamodb/lib/replica-handler/index.ts

Lines 31 to 43 in bbdb16a

	if (updateTableAction) {
	const data = await dynamodb.updateTable({
	TableName: tableName,
	ReplicaUpdates: [
	{
	[updateTableAction]: {
	RegionName: region,
	},
	},
	],
	}).promise();
	console.log('Update table: %j', data);
	} else {

[BalintLab]

I'd also recommend creating a global table resource (CfnGlobalTable) when replicaregions is set as per DynamoDB best practices
Also, its not just the retentionpolicy, but any other attribute you set subsequently

[rix0rrr]

This issue was for the existing Table construct, which used custom resources to implement table replication. We no longer recommend the use of the Table construct.

Instead, the TableV2 construct has been released in 2.95.1 (#27023) which maps to the AWS::DynamoDB::GlobalTable resource, has better support for replication and does not suffer from the issue described here.

---

Be aware that there are additional deployment steps involved in a migration from Table to TableV2. You need to do a RETAIN deployment, a delete deployment, then change the code to use TableV2 and then use cdk import. A link to a full guide will be posted once it is available.

Here are some other resources to get you started (using CfnGlobalTable instead of TableV2) if you want to get going on the migration:

• Migrating from Table to CfnGlobalTable, by Samaneh Utter, an AWS Senior Solutions Architect
• AWS CDK and Amazon DynamoDB Global Tables, by Wojciech Matuszewski from Stedi
• Migrating from Table to CfnGlobalTable, by Sharon Diskin from CloudBit

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.