Support S3 Native State Locking

[kksudo]

Describe the Feature

Terraform v1.10 introduced native S3 state locking through the use_lockfile attribute.
Previously, state file locking required access to a DynamoDB table, but this is no longer necessary.

Expected Behavior

The terraform-aws-tfstate-backend module should support the use_lockfile attribute in the Terraform backend configuration for S3. This would allow users to enable native S3 state locking, eliminating the need for provisioning a DynamoDB table for state file locking.

Use Case

Currently, the terraform-aws-tfstate-backend module sets up a DynamoDB table alongside the S3 bucket for state storage to handle state file locking. With Terraform v1.10 introducing S3 native state locking, the need for DynamoDB can be completely removed, simplifying the infrastructure setup.

This feature is valuable for:

• Reducing costs by avoiding DynamoDB provisioning.
• Simplifying the Terraform backend setup for smaller-scale projects.
• Aligning the module with the latest Terraform features to provide modern capabilities to users.

For example, users managing state files in a less complex environment, such as those without heavy requirements for DynamoDB-specific features like point-in-time recovery, can now have a more streamlined experience.

Describe Ideal Solution

The module should include an optional parameter (e.g., enable_native_locking) to toggle the use of S3 native state locking.

• When this parameter is set to true, the module should configure the backend to include use_lockfile = true, and skip creating a DynamoDB table.
• When set to false (default for backward compatibility), the existing behavior with DynamoDB state locking should remain intact.

This ensures both backward compatibility and support for the new native locking feature, allowing users to choose the solution that best fits their needs.

Alternatives Considered

No response

Additional Context

https://developer.hashicorp.com/terraform/language/backend/s3#state-locking

[Gowiem]

@kksudo is the potential answer here to just set the dynamodb_enabled variable to false and then use the use_lockfile setting in your backend config? Would this maybe be a suggestion to just document that approach better?

[scottdspangler]

@osterman Any update on the implementation of this feature?. Within the current Cloud Posse terraform-aws-tfstate-backend and using Terraform 1.11.0 , I have started receiving deprecation warnings >

Warning: Deprecated Parameter
│
│ The parameter "dynamodb_table" is deprecated. Use parameter "use_lockfile"
│ instead.

[Gowiem]

@scottdspangler is that an issue with the outputted template file? If so, you can feel free to edit that template after it is written or provide your own template file. I know that we've previously discussed removing that templating altogether because it's largely not necessary and we could accomplish the same for consumers through an output block.

cc @Nuru as I believe you and I were the ones who were chatting about removing the templating functionality.

[Gowiem]

@kksudo friendly ping on my previous question to you as well -- I'm interested if that works for you moving forward. This functionality of using native state locking currently diverges between Terraform + OpenTofu and we can't expect this module to only support the native state locking in the short term.

[kksudo]

@kksudo friendly ping on my previous question to you as well -- I'm interested if that works for you moving forward. This functionality of using native state locking currently diverges between Terraform + OpenTofu and we can't expect this module to only support the native state locking in the short term.

For some reason, I did not test this option. In my case, I implemented this functionality myself on my end.