feat: Ignore GSI changes

[pablotp]

what

• Ignore the changes made to the global-secondary-index.

why

• Changes made to the global_secondary_index.read|write_capacity by the autoscaler causes drift.

references

• No method to ignore changes in DynamoDB GSI hashicorp/terraform-provider-aws#671

[pablotp]

/terratest

[RoseSecurity]

Until the provider addresses this bug, this situation appears fair. We might need to add a README note to document that setting this option means Terraform will ignore any changes to GSIs and require manual or automated application.

[pablotp]

Until the provider addresses this bug, this situation appears fair. We might need to add a README note to document that setting this option means Terraform will ignore any changes to GSIs and require manual or automated application.

Sounds good 👍🏻
I've just pushed aa6c434
Please let me know whether or not it meets your expectations. I generated the README.d using make readme, and it added a couple of unrelated changes (mainly replacing <br> with <br/>).

[mergify]

💥 This pull request now has conflicts. Could you fix it @pablotp? 🙏

[RoseSecurity]

/terratest

I can't think of any alternative solutions to this issue, but I'd love to get a second set of eyes from the team on this change.

[pablotp]

I can't think of any alternative solutions to this issue, but I'd love to get a second set of eyes from the team on this change.

Right now, I can't either.
After using this solution for a bit, I must admit that it gets tricky when you need to make changes apart from read|write_capacity (e.g., new secondary indexes). Therefore, I feel like this issue needs a solution at the provider level hashicorp/terraform-provider-aws#671.

[nitrocode]

Seems reasonable

[aknysh]

/terratest

[nitrocode]

Actually 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

[nitrocode]

Only downside to migrating from global_secondary_index argument to the new aws_dynamodb_global_secondary_index resource is that it's experimental...

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/dynamodb_global_secondary_index

[nitrocode]

@aknysh this might still be the best way to go until the new resource is no longer experimental. What do you think?

Also, it looks like tests are failing on this which doesn't seem to have to do with this PR

TestExamplesComplete 2026-02-17T22:21:32Z logger.go:66: │ Error: creating AWS DynamoDB Table (eg-test-second): operation error DynamoDB: CreateTable, https response error StatusCode: 400, RequestID: VLA6KTJ3UHHNUSSPLIOEO3SUJJVV4KQNSO5AEMVJF66Q9ASUAAJG, ResourceInUseException: Table already exists: eg-test-second

[aknysh]

@aknysh this might still be the best way to go until the new resource is no longer experimental. What do you think?

Also, it looks like tests are failing on this which doesn't seem to have to do with this PR

TestExamplesComplete 2026-02-17T22:21:32Z logger.go:66: │ Error: creating AWS DynamoDB Table (eg-test-second): operation error DynamoDB: CreateTable, https response error StatusCode: 400, RequestID: VLA6KTJ3UHHNUSSPLIOEO3SUJJVV4KQNSO5AEMVJF66Q9ASUAAJG, ResourceInUseException: Table already exists: eg-test-second

@pablotp @nitrocode it seems like a solution, but I know it gets and will get tricky to maintain the secondary indexes once they are ignored.
Maybe we can redesign the module to use this new feature which is already released?
hashicorp/terraform-provider-aws#44999

If it's experimental, we can prob wait for it to became GA, in which case I'm OK with the cnanges in the PR

[pablotp]

@aknysh this might still be the best way to go until the new resource is no longer experimental. What do you think?
Also, it looks like tests are failing on this which doesn't seem to have to do with this PR

TestExamplesComplete 2026-02-17T22:21:32Z logger.go:66: │ Error: creating AWS DynamoDB Table (eg-test-second): operation error DynamoDB: CreateTable, https response error StatusCode: 400, RequestID: VLA6KTJ3UHHNUSSPLIOEO3SUJJVV4KQNSO5AEMVJF66Q9ASUAAJG, ResourceInUseException: Table already exists: eg-test-second

@pablotp @nitrocode it seems like a solution, but I know it gets and will get tricky to maintain the secondary indexes once they are ignored. Maybe we can redesign the module to use this new feature which is already released? hashicorp/terraform-provider-aws#44999

If it's experimental, we can prob wait for it to became GA, in which case I'm OK with the cnanges in the PR

Apologies for not having cleaned up this PR. We attempted this, but the problem is what @aknysh has already pointed out ⤵️

will get tricky to maintain the secondary indexes once they are ignored.

Maybe we can redesign the module to use this new feature which is already released hashicorp/terraform-provider-aws#44999

This seems to be the way to go 👍🏻