Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To use Terraform state locking without DynamoDB, set use_lockfile = true in the S3 backend configuration. Terraform then creates a lock object by appending .tflock to the configured state key. This is opt-in, and the Terraform identity needs permission to read, create or update, and delete the lock object.
Enable S3 native state locking
Add use_lockfile = true to your existing backend "s3" configuration. For example:
terraform {
backend "s3" {
bucket = "example-bucket"
key = "path/to/state"
region = "us-east-1"
use_lockfile = true
}
}The bucket, key, and region above are example values; replace them with the backend settings for your environment. The S3 backend documentation lists the default for use_lockfile as false, so locking is not enabled unless you opt in. See HashiCorp’s S3 backend documentation.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Grant access to both the state and lock objects
Terraform stores state at the configured bucket and key. It uses a separate lock object at the same path, with .tflock appended to the key. For a state key of path/to/state, the lock key is path/to/state.tflock.
#1 Best Overall
Scope the Terraform identity’s permissions to the relevant state and lock object paths, including workspace paths where applicable. The state object needs the documented read and write access; native locking additionally requires these permissions on the lock object:
s3:GetObjectto read the lock.s3:PutObjectto create or update it.s3:DeleteObjectto remove it when unlocking.
Non-default workspaces use the configured workspace key prefix and workspace name in the object path. Account for those paths in the policy rather than granting broad access to the whole bucket. HashiCorp’s S3 backend documentation lists the backend permissions and path behavior. The backend does not require s3:DeleteObject on the state object itself; do not confuse that with the delete permission needed for the lockfile.
Rank #2
HashiCorp strongly recommends enabling S3 bucket versioning. It provides recoverable prior state versions if the current state is accidentally deleted or changed through human error.
Reinitialize after changing the backend
After changing backend configuration, run terraform init again before running plans, applies, or state operations. During reinitialization Terraform may offer to migrate existing state. Follow the CLI prompt and your team’s change-control process; do not manually edit the state file as a substitute. See HashiCorp’s documentation for terraform init.
- Update the S3 backend configuration to include
use_lockfile = true. - Run
terraform initfrom the working directory. - If Terraform prompts about migrating state, review the prompt and proceed according to your approved change process.
- Confirm that every client that reads or writes this state can use the locking configuration you are rolling out.
What changes when you move away from DynamoDB?
HashiCorp’s current S3 backend documentation describes DynamoDB-based locking as deprecated and says it will be removed in a future minor Terraform version. The page does not identify the removal release, nor does it state the first Terraform version that supports use_lockfile; do not infer either version from this guidance.
The documentation permits configuring S3 lockfiles and DynamoDB arguments together to accommodate older Terraform clients that support only DynamoDB locking. That coexistence can help teams roll out compatible configuration, but confirm that all clients participating in state operations support the mechanism before removing the legacy DynamoDB argument. Enabling S3 locking changes the S3 backend’s locking mechanism; terraform init is the required reinitialization step when the backend configuration changes.
How Terraform locking protects state
When the backend supports locking, Terraform automatically locks state for operations that could write it. If Terraform cannot acquire a lock, it stops rather than proceeding with a potentially conflicting write. HashiCorp explains this behavior in its state locking documentation.
Avoid -lock=false: it disables locking for most commands, and HashiCorp does not recommend doing so. Use terraform force-unlock only to recover your own lock after automatic unlocking has failed. Removing another operator’s active lock can allow concurrent writers and risk state consistency.
Choose the approach that fits your team
| Approach | What it provides | Key consideration |
|---|---|---|
| S3 lockfile | Native S3 backend locking, enabled with use_lockfile = true. |
All participating clients must support the configuration; the Terraform identity needs read, write, and delete permissions on the .tflock object. |
| DynamoDB locking | Legacy locking configuration for the S3 backend. | HashiCorp documents it as deprecated and allows coexistence with S3 lockfiles for compatibility with older clients. The removal release is not specified. |
| HCP Terraform | A managed service option that HashiCorp describes as providing state storage, locking, remote execution, and collaboration features. | This is a broader managed-workflow choice, not simply a replacement backend setting. See HashiCorp’s HCP Terraform documentation. |
When deciding, consider client compatibility, who operates the state infrastructure, how narrowly you can scope IAM access, your state recovery and versioning requirements, and whether you want managed remote execution and collaboration. HashiCorp tests the S3 backend against Amazon S3 and makes no guarantees for other S3-compatible providers; consult the backend documentation before relying on an alternate provider.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
