Proper handling of DynamoDB replicas and GSIs with autoscaling #25331
Labels
enhancement
Requests to existing resources that expand the functionality or scope.
service/appautoscaling
Issues and PRs that pertain to the appautoscaling service.
service/dynamodb
Issues and PRs that pertain to the dynamodb service.
stale
Old or inactive issues managed by automation, if no further action taken these will get closed.
Community Note
Description
Currently, it's impossible to use terraform to cleanly create a new DynamoDB table with replicas or GSIs unless its billing mode is
PAY_PER_REQUEST
. The reason for this is that:This leads to a circular dependency, in which it's impossible to create a table using autoscaling and replicas/GSIs all in one go using proper terraform. There are two workarounds, both bad.
Using two
apply
sThis workaround is described in a comment on an earlier issue on the same subject, here.
apply
: Create aPROVISIONED
table with no replicas or GSIs, plus create autoscaling resources applying to the table (one each ofaws_appautoscaling_target
andaws_appautoscaling_policy
for reads, and one each for writes)apply
: Update the table to add replicas and GSIsThe advantage of this approach is that everything you create is in the terraform state so subsequent
plan
andapply
operations will use and return correct information. The disadvantage is that it requires running multipleapply
s and patching code in between, which is unpleasant at the best of times and clearly impossible in a CI/CD scenario.Using a
null_resource
with a local provisionerYou create the table with autoscaling but no replicas. You then have a
null_resource
whichdepends_on
the table and the autoscaling resources. Thisnull_resource
uses the AWS CLI in a local provisioner to create the replica tables and GSIs.This approach has the advantage of only requiring one
apply
and no ad hoc code patching, so can be used in CI/CD. However, the replica tables and GSIs you create are effectively not in IaC - they won't be modified by subsequent changes to config, nor will they be torn down when you run adestroy
. Plus, any terraform code changes that will affect them won't be shown in aplan
output. This approach is therefore also very suboptimal.New or Affected Resource(s)
Existing:
aws_dynamodb_table
Potential new:
aws_dynamodb_replica_table
aws_dynamodb_global_secondary_index
Potential Terraform Configuration
The workaround shown above relies on the fact that you can add replicas to an existing table without recreating it. My suggestion, then, would be to add a new resource to the provider which does this.
I've added an example config here for how the new resource would work.
Using new resources here would allow for multiple API calls to take place under the hood, circumventing the need for two
apply
s.To be clear - this is just one suggested solution to this problem. I've got no attachment to any particular solution but this seemed like a simple way to break the architectural deadlock around this.
References
The text was updated successfully, but these errors were encountered: