### 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
@kksudo is the potential answer here to just set the [`dynamodb_enabled`](https://github.com/cloudposse/terraform-aws-tfstate-backend#input_dynamodb_enabled) variable to `false` and then use the [`use_lockfile`](https://developer.hashicorp.com/terraform/language/backend/s3#use_lockfile-1) setting in your backend config? Would this maybe be a suggestion to just document that approach better?
@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.
@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.
@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](https://github.com/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.
> [@kksudo](https://github.com/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.
Just FYI, OpenTofu 1.10 is out with the matching functionality. So this isnt an issue anymore.
We have a local fork in place that adds support for this using a feature flag. Would it be of interest to upstream the changes?
- adding a variable working as a feature flag
- both modes can be used in parallel (S3 and DynamoDB) which allows for smooth testing and migration
High maintainers, I've provided the MR and hope that it is to your liking. Please let me know if there is anything that should be adjusted to guarantee maximum compatibility.