Another set of eyes here pleae <https://github.com...
# pr-reviewsr
RB
02/17/2026, 10:17 PMAnother set of eyes here pleae https://github.com/cloudposse/terraform-aws-dynamodb/pull/141
✅ 1
❌ 1
RB
02/17/2026, 10:22 PMActually on second thought, it looks like the linked issue is now fixed in a recent aws provider update 6.28.0
• https://github.com/hashicorp/terraform-provider-aws/releases/tag/v6.28.0
• No method to ignore changes in DynamoDB GSI hashicorp/terraform-provider-aws#671 (comment)
• new aws_dynamodb_global_secondary_index resource hashicorp/terraform-provider-aws#44999
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/dynamodb_global_secondary_index
RB
02/17/2026, 10:22 PMSo it seems the fix might be to migrate the
global_secondary_indexRB
02/17/2026, 10:34 PMAhh… but it is experimental which seems risky
g
Gabriela Campana (Cloud Posse)
02/18/2026, 9:37 PM@johncblandii @Andriy Knysh (Cloud Posse)
a
Andriy Knysh (Cloud Posse)
02/18/2026, 10:06 PM@RB I'm not sure what's the best approach here 🙂
• If we merge the PR, that will work (until someone wants to update/add secondary indexes, in which case it does not work anymore and requires jumping through many hoops)
•
aws_dynamodb_global_secondary_indexAndriy Knysh (Cloud Posse)
02/18/2026, 10:06 PMwhat we did before, is solution # 3:
Andriy Knysh (Cloud Posse)
02/18/2026, 10:08 PMadd a variable to enable/disable including an attribute into the lifecycle management. You will need to repeat the code - it's two resources instead of one b/c the lifecycle does not support dynamic variables
r
RB
02/18/2026, 10:15 PMugh, i guess now that im reading more about it, i dislike all of the options, but the option that i least dislike is option 2, the experimental resource
RB
02/18/2026, 10:16 PMthanks for reviewing andriy
a
Andriy Knysh (Cloud Posse)
02/18/2026, 10:20 PMwe don't even know if the new experimental`aws_dynamodb_global_secondary_index` resource will not drift in the same way - the autoscaler changes the index capacity, and terraform shows the same drift, but now on this new resource (in which case we are back to option #1 (implemented in the PR) or option #3)
r
RB
02/18/2026, 11:42 PMugh… also option 2 requires an experimental environment variable for everyone. it’s not a viable solution for a module.
RB
02/18/2026, 11:43 PM# 3 is the ugliest because 2 resources, exactly the same, but with different lifecycle.ignore_rules would need to be maintained
2 Views