Terraform DynamoDB Resource In Use Retry

Threat/Impact Level: HIGH | Exploitability/Downtime Risk: HIGH | Time to Fix: 10 mins

TL;DR

• What broke: Terraform issued a DynamoDB UpdateTable API call while AWS was already processing a concurrent operation (index backfill, autoscaling policy update, or a prior GSI modification) on the same table — AWS rejected it with ResourceInUseException.
• How to fix it: Add explicit depends_on chains between DynamoDB resources, use lifecycle { ignore_changes } for attributes managed out-of-band, and wrap destructive changes in a retry loop via null_resource + AWS CLI.
• Shortcut: Use our Client-Side Sandbox above to auto-refactor this — paste your failing aws_dynamodb_table block and get corrected HCL instantly.

Error: updating DynamoDB Table (my-production-table): ResourceInUseException:
  Table is being updated: my-production-table
    status code: 400, request id: 4a1b2c3d-xxxx-xxxx-xxxx-ffffffffffff

How to Fix It (The Solution)

Basic Fix — Serialize Operations with `depends_on` and Reduce Parallelism

If you are managing multiple DynamoDB resources or autoscaling attachments in the same workspace, force serialization:

 resource "aws_dynamodb_table" "main" {
   name           = "my-production-table"
   billing_mode   = "PAY_PER_REQUEST"
   hash_key       = "pk"

+  lifecycle {
+    ignore_changes = [
+      # Ignore read_capacity/write_capacity mutated by autoscaling out-of-band
+      read_capacity,
+      write_capacity,
+    ]
+  }
 }

 resource "aws_appautoscaling_target" "dynamodb_table_read" {
   ...
+  depends_on = [aws_dynamodb_table.main]
 }

Run apply with reduced parallelism to prevent race conditions:

- terraform apply
+ terraform apply -parallelism=1

Enterprise Best Practice — Retry Wrapper via `null_resource`

For pipelines that cannot tolerate manual intervention, wrap the sensitive update in a polling retry using AWS CLI inside a null_resource. This is especially critical for GSI additions on large tables where backfill can take 20–40 minutes.

-resource "aws_dynamodb_table" "main" {
-  name         = "my-production-table"
-  billing_mode = "PROVISIONED"
-  read_capacity  = 5
-  write_capacity = 5
-
-  global_secondary_index {
-    name            = "gsi-email"
-    hash_key        = "email"
-    projection_type = "ALL"
-    read_capacity   = 5
-    write_capacity  = 5
-  }
-}

+resource "aws_dynamodb_table" "main" {
+  name         = "my-production-table"
+  billing_mode = "PROVISIONED"
+  read_capacity  = 5
+  write_capacity = 5
+
+  # Do NOT declare GSIs here if adding them post-creation.
+  # Manage GSI additions via null_resource below to control retry logic.
+
+  lifecycle {
+    ignore_changes = [global_secondary_index, read_capacity, write_capacity]
+  }
+}
+
+resource "null_resource" "add_gsi_email" {
+  depends_on = [aws_dynamodb_table.main]
+
+  triggers = {
+    gsi_definition = "gsi-email-v1"
+  }
+
+  provisioner "local-exec" {
+    command = <<-EOT
+      set -e
+      MAX_RETRIES=15
+      RETRY_INTERVAL=60
+      for i in $(seq 1 $MAX_RETRIES); do
+        STATUS=$(aws dynamodb describe-table \
+          --table-name my-production-table \
+          --query 'Table.TableStatus' \
+          --output text)
+        if [ "$STATUS" = "ACTIVE" ]; then
+          echo "Table ACTIVE. Applying GSI update..."
+          aws dynamodb update-table \
+            --table-name my-production-table \
+            --attribute-definitions AttributeName=email,AttributeType=S \
+            --global-secondary-index-updates \
+              '[{"Create":{"IndexName":"gsi-email","KeySchema":[{"AttributeName":"email","KeyType":"HASH"}],"Projection":{"ProjectionType":"ALL"},"ProvisionedThroughput":{"ReadCapacityUnits":5,"WriteCapacityUnits":5}}}]'
+          break
+        fi
+        echo "Table status: $STATUS. Waiting $RETRY_INTERVAL seconds... ($i/$MAX_RETRIES)"
+        sleep $RETRY_INTERVAL
+      done
+    EOT
+  }
+}

💡 Tired of pasting proprietary infrastructure configs into public LLMs? Generic AI interfaces log your company's ARNs, connection strings, and private keys. StackEngine enforces client-side zero-trust boundaries—the sandbox above executes 100% locally in your browser. Drop your broken manifest above to redact secrets locally and synthesize deterministic patch drafts with your own API key.

(For CI/CD pipeline automation, install via npm i -g stackengine).

# policy/dynamodb_serial.rego
deny[msg] {
  input.resource_changes[_].type == "aws_dynamodb_table"
  input.terraform_version  # confirm plan file context
  not input.variables.parallelism == "1"
  msg := "DynamoDB table changes MUST be applied with -parallelism=1 to prevent ResourceInUseException."
}

resource "aws_dynamodb_table" "main" {
  ...
  lifecycle {
    precondition {
      condition     = can(regex("^ACTIVE$", data.aws_dynamodb_table.main_check.table_status))
      error_message = "DynamoDB table is not in ACTIVE state. Aborting to prevent ResourceInUseException."
    }
  }
}