No More DynamoDB: Native S3 Locking Now Available in Terraform 1.11 and Later

---

Table of Contents:

1. Overview

2. What is Terraform State Locking?

3. Why Switch to S3 Native State Locking?

4. How to Transition to S3 Native State Locking?

5. Key Considerations Before Migration

6. The Future of State Locking in Terraform

7. Conclusion

---

Overview

For years, terraform users have used AWS S3 to store remote state and relied on a DynamoDB table for state locking to avoid conflicts during concurrent operations. With the latest Terraform release, native state locking in S3 is now fully supported—eliminating the need to manage a separate DynamoDB table. This simplifies backend configuration and reduces the overhead of maintaining extra AWS resources.

In this article, we’ll break down what this update means, how to migrate from DynamoDB-based locking to S3 native locking, and what Terraform users should keep in mind during the transition.

What is Terraform State Locking?

State locking prevents multiple Terraform processes from making simultaneous changes to the state file, helping avoid conflicts and potential data corruption. Traditionally, when using an S3 backend, this required configuring a separate DynamoDB table to manage the lock—an effective but operationally complex solution.

With the latest release, Terraform now natively supports state locking directly in S3, removing the need for a DynamoDB table while still providing reliable and secure locking.

Why Switch to S3 Native State Locking?

1. Simplified Backend Setup

   Eliminates the need to create and manage a separate DynamoDB table, reducing overall configuration complexity.

2. Reduced AWS Costs

   No more DynamoDB read/write capacity charges—leading to potential savings on your AWS bill.

3. Easy Migration

   Existing state files remain unaffected. A simple configuration update is all that’s needed and Terraform manages the transition seamlessly.

4. Better State Management

   Leverages Amazon S3’s built-in locking capabilities to maintain consistency—without relying on extra AWS services.

How to Transition to S3 Native State Locking?

• Current Setup Using DynamoDB for Locking

  In the past, a standard S3 backend configuration with DynamoDB-based locking looked like this:

terraform {
  backend "s3" {
    bucket         = "anantacloud-tfstate-bucket"
    key            = "us-east-1/dev/vpc/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "anantacloud-tfstate-locking" # Legacy state lock
    encrypt        = true
  }
}

• Updated Configuration (S3 Native Locking)

  To switch to S3 native state locking, simply update the backend configuration as follows:

terraform {
  backend "s3" {
    bucket         = "anantacloud-tfstate-bucket"
    key            = "us-east-1/dev/vpc/terraform.tfstate"
    region         = "us-east-1"
    use_lockfile   = true # New S3 native locking!
    encrypt        = true
  }
}

Following the update, Terraform will automatically handle state locking via Amazon S3, eliminating the need for DynamoDB or additional manual configurations. It will generate a locking file named terraform.tfstate.lock to secure the lock.

Key Considerations Before Migrating

Before switching to S3 native state locking, keep the following in mind:

• Terraform Version: Make sure you're using Terraform 1.x or later, as native S3 locking is only supported in newer versions.

• Existing Locks: If your state is currently locked via DynamoDB, Terraform will automatically release the lock once the DynamoDB configuration is removed.

• IAM Permissions: Confirm that your IAM user or role has the necessary permissions to use S3 state locking. Specifically, ensure the policy includes:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject",
    "s3:DeleteObject"
  ],
  "Resource": "arn:aws:s3:::anantacloud-tfstate-bucket/*"
}

We highly recommend to test the migration in a non-production environment first to verify the locking mechanism works as expected

The Future of State Locking in Terraform

As Terraform continues to emphasize simplicity and automation, the introduction of native S3 state locking marks a significant evolution. HashiCorp has already signaled plans to deprecate DynamoDB-based locking in future versions, making it wise to begin testing and migrating now.

Adopting S3 native state locking offers a cleaner, more cost-effective approach to managing Terraform state—eliminating the need for DynamoDB and reducing overall complexity.

Conclusion

Native S3 state locking is a major improvement for Terraform users. With a small backend configuration change, you can transition smoothly and prepare your infrastructure for the future.

If you haven’t already, start experimenting with native locking in your development environment—and simplify your state management by moving on from DynamoDB.

SPEAK TO OUR CLOUD EXPERT