(aws-dynamodb): Updating the TTL value is not really possible
- Dominant language
- TypeScript
- Stars
- 12.9k
- Forks
- 4.6k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 71
Description
## :question: General Issue
### The Question
The initial question that led me to creating this issue was "How do I update the TTL value of an existing DynamoDB Table?". The Documentation starts out with saying, the default for `TableOptions.timeToLiveAttribute` is TTL disabled. This is only partially true, as I discovered later. To reproduce this simply create a Table like the following:
```ts
new dynamodb.Table(this, "MyTableWithTTL", {
partitionKey: { name: "Index", type: dynamodb.AttributeType.STRING },
timeToLiveAttribute: "TTL",
});
```
After a stack containing a table with TTL (like the one above) is deployed, the next goal is to change the `TableOptions.timeToLiveAttribute` to `"NewTTL"`. The most intuitiv step is to just change `"TTL"` to `"NewTTL"`. This however won’t change the real TTL attribute. Sadly, neither CloudFormation nor CDK notify the user of his mistake.
A close look at the DynamoDB documentation reveals, that the TTL needs to disabled before being reenabled with a new value. So, the next logical step would be to first remove the `TableOptions.timeToLiveAttribute`, as the default is disabled per CDK documentation, and afterwards deploy a second time with the new value set.
However, this will only exclude the `TimeToLiveSpecification` from the generated CloudFormation file. When this is then deployed, that TTL will remain in place, as CloudFormation won't remove it if the parameter is simply removed. To actually remove a TTL with CloudFormation the provided CloudFormation file needs to contain the `TimeToLiveSpecification` parameter with `AttributeName` set to the current TTL attribute and `Enabled` set to false. The update will take longer than usual in this case, as the TTL is removed. This is, as far as I'm aware, currently not possible with the way `TableOptions` are designed.
### Environment
- **CDK CLI Version:** 1.89.0 (build df7253c)
- **Module Version:** 1.89.0
- **Node.js Version:** v14.15.5
- **OS:** macOS Big Sur
- **Language (Version):** TypeScript (3.9.9)
### Other information
#### Related issues
https://github.com/aws/aws-cdk/issues/10576
The issue was closed because of staleness and the described solution doesn’t match my observations.
#### CloudFormation example
```yaml
AWSTemplateFormatVersion: "2010-09-09"
Resources:
MyTableWithTTL:
Type: AWS::DynamoDB:Table
Properties:
TableName: MyTableWithTTL
AttributeDefinitions:
- AttributeName: Index
AttributeType: S
KeySchema:
- AttributeName: Index
KexType: HASH
TimeToLiveSpecification:
AttributeName: "TTL"
Enabled: true
```
#### Suggestions on how to fix
Because of the described behavior, I would like to request two improvements:
1. The CDK documentation should explicitly warn, that a created TTL can currently not be updated nor be removed with the CDK Table construct.
2. Having to disable and reenable the TTL setting is not a great user / developer experience. As CloudFormation requires this behavior, maybe this could be translated by a CDK provided custom resource. Ideally that resource could handle removing and setting the TTL, so that updates are easily possible if one would like to change the TTL attribute in CDK.
The first improvement strikes me as rather easy and should ideally be implemented sooner than later. The second however appears to be more difficult and I'm not sure how feasible this is or if this is even something that should be included in this. I just think it would make usage easier and the behavior more user friendly.
Contributor guide
Research direction
Start with TableOptions.timeToLiveAttribute and the generated CloudFormation TimeToLiveSpecification described in the issue, then review related issue #10576 and the DynamoDB TTL behavior. Done means documenting the limitation clearly or defining a viable update path that disables the old TTL before applying the new attribute.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, typescript
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100