DynamoDB GSI Autoscaling doesn't require a scaling policy, leading to invalid infrastructure configuration

[Brusalk]

DynamoDB GSI Autoscaling doesn't require a scaling policy, leading to invalid infrastructure configuration

Background

When using GSI Autoscaling, it's possible to add autoscaling targets without adding an associated scaling policy.

 table.addGlobalSecondaryIndex({
    indexName: props.indexName,
    partitionKey: props.partitionKey,
    sortKey: props.sortKey,
  });
  table.autoScaleGlobalSecondaryIndexReadCapacity(props.indexName, {
    minCapacity: props.minReadCapacity,
    maxCapacity: props.maxReadCapacity,
  });
  table.autoScaleGlobalSecondaryIndexWriteCapacity(props.indexName, {
    minCapacity: props.minWriteCapacity,
    maxCapacity: props.maxWriteCapacity,
  });

When you do that, CDK (nor the underlying CloudFormation) error on the invalid configuration.

What's the impact

The end result is that DynamoDB results in failing to autoscale the GSI, resulting in the GSI only using the default levels, with the only notification to the customer being an "ERROR" field when looking at the GSI.

Currently, nothing prevents the customer from ending up with an invalid autoscaling configuration, that'll only get caught when they need autoscaling the most.

What should CDK do

In my opinion, CDK should fail the build because of the invalid autoscaling configuration on the GSI.

I imagine it'd be possible to detect whether no scaling policy was added for the GSI (either through the helpers, or manually through lower-level cloudformation resources)

Potential "gotchas" with the implementation

• A customer could add the underlying scaling policy using the low-level resource types themselves.

[github-actions]

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

[Brusalk]

Please keep this open

[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