Terraform S3 backend has native state locking now (no DynamoDB)

Every Terraform S3 backend tutorial tells you to create a DynamoDB table for state locking. As of Terraform 1.10, you don’t need it.

The old way

terraform {
  backend "s3" {
    bucket         = "my-tfstate"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Plus a DynamoDB table with a LockID string partition key. One more resource to create, one more thing to manage, one more thing to pay for (pennies, but still).

The new way

terraform {
  backend "s3" {
    bucket       = "my-tfstate"
    key          = "prod/terraform.tfstate"
    region       = "us-east-1"
    use_lockfile = true
    encrypt      = true
  }
}

That’s it. Terraform uses S3 conditional writes to create a .tflock file next to your state file. If the lock file already exists, the write fails atomically. No DynamoDB.

What changed

S3 added support for conditional writes (If-None-Match) in 2024. Terraform 1.10 shipped use_lockfile to take advantage of it. The locking is built into S3 itself — no sidecar database needed.

Should you migrate?

For new projects, just use use_lockfile = true and skip DynamoDB entirely.

For existing projects, it’s not urgent. The DynamoDB approach still works and isn’t deprecated. But if you’re cleaning up infrastructure or setting up new state backends, one fewer resource is one fewer thing to break.

Gotcha

The use_lockfile option requires Terraform >= 1.10. If your team has mixed Terraform versions, make sure everyone is on 1.10+ before switching, or you’ll have some runs acquiring the DynamoDB lock and others using the S3 lock file.