(DynamoDB): Add regionalArns to set of import props for DynamoDB Table

[jd-carroll]

Describe the feature

Not sure what the best approach to this would be, but...

If you create a table with replication regions in one stack and then import that table in another stack, none of the granted permissions in the second stack will allow access to the replicated tables.

I think its a fair question to ask: "How does the second stack know what replication regions exist?"

However, I still think there should be some way to import the table and grant access to all replication tables.

Right now I need to do something like this:

    const importedTable = Table.fromTableAttributes(scope, 'import-table', {
      tableName: myTableName,
    });

    knownReplicationRegions.forEach((region) => {
        // @ts-ignore
        importedTable.regionalArns.push(
          stack.formatArn({
            region,
            service: 'dynamodb',
            resource: 'table',
            resourceName: myTableName
          })
        );
      });

Use Case

More easily work with imported tables that have replication regions

Proposed Solution

Add replication regions to list of supported attributes with importing the table.

Something like:

Table.fromTableAttributes(scope, 'control-plane', {
  tableName: myTableName,
  replicationRegions: knownReplicationRegions
});

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.31.1

Environment details (OS name and version, etc.)

MacOS

[peterwoodworth]

Thanks for submitting this, we accept contributions! Check out our contributing guide if you're interested - there's a low chance the team will be able to address this soon but we'd be happy to review a PR 🙂

[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