Terraform 1.10+: Native S3 Locking — No More DynamoDB Needed
Terraform 1.10 introduces native S3 state locking — here’s why it matters and how to migrate safely.
🚀 Introduction
Goodbye DynamoDB, Hello Native S3 Locking!
Starting with Terraform 1.10, the S3 backend now supports native locking using S3 object versioning and lockfiles.
✅ No need to configure and maintain a DynamoDB table for state locking.
✅ Simpler, cleaner, and cost-effective Terraform backend setup!
In this post, you’ll learn:
What’s changed
Why it matters
Step-by-step how to migrate
Updated IAM permissions needed
Common FAQs
🔥 What’s New?
Before Terraform 1.10:
S3 stored the state file.
DynamoDB managed the lock to prevent simultaneous updates.
Now:
S3 does both state storage and locking natively!
DynamoDB is no longer needed.
From Terraform 1.11:
The dynamodb_table argument is deprecated.
You’ll get warnings if you keep using it.
Future versions may completely remove support.
🎯 Why It Matters
🚀 Simpler Setup: Only S3 is needed.
🚀 Lower AWS Costs: No DynamoDB throughput billing.
🚀 Fewer IAM policies: Only S3 permissions needed.
🚀 Fewer Failure Points: Reduced complexity.
🛠 How to Migrate — Step-by-Step
1. Upgrade Terraform to 1.10+
Check your current version:
terraform -versionInstall Terraform 1.10 or newer if needed.
2. Enable S3 Bucket Versioning
S3 versioning must be enabled for lockfile support.
You can enable versioning for your bucket using the AWS S3 console or the command below. Replace <your-tf-state-bucket-name> with your bucket name.
aws s3api put-bucket-versioning \
--bucket <your-tf-state-bucket-name> \
--versioning-configuration Status=Enabled3. Update Terraform Backend Configuration
Remove dynamodb_table From your current S3 backend config and add use_lockfile = true.
👉 Old (DynamoDB-based):
terraform {
backend "s3" {
bucket = "your-tf-state-bucket-name"
key = "path/to/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-locks"
}
}👉 New (Native S3 Locking):
terraform {
backend "s3" {
bucket = "your-tf-state-bucket-name"
key = "path/to/terraform.tfstate"
region = "us-east-1"
use_lockfile = true # NEW: enables native locking using S3
}
}✅ The new important setting:
use_lockfile = true(Default is true from Terraform 1.10+, but it’s better to explicitly set it for clarity.)
4. Update IAM Permissions
You no longer need DynamoDB permissions.
Update your IAM role or policy to allow only necessary S3 operations.
Minimal required permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-tf-state-bucket-name",
"arn:aws:s3:::your-tf-state-bucket-name/*"
]
}
]
}You can also add optional recommendations:
s3:GetObjectVersion
s3:DeleteObjectVersion
👉 These are helpful if your organization uses strict security controls around S3 object versioning and deletions.
5. Reinitialize Terraform Backend
After updating your configuration, you must reinitialize the backend.
terraform init -reconfigure✅ This will update the backend settings without touching your state files.
6. (Optional) Clean up the Old DynamoDB Table
If no other systems are using it, you can safely delete the DynamoDB table.
aws dynamodb delete-table --table-name terraform-locks⚡ Pro tip: Backup the table first if you’re unsure.
🚨 Important Notes
use_lockfile = true is now the preferred and future-compatible setting.
Starting Terraform 1.11, dynamodb_table will be deprecated — you’ll get warnings.
In future versions (1.12+), dynamodb_table might be removed entirely, causing errors if not migrated.
S3 versioning is mandatory for lockfiles to work correctly.
🔍 Common Questions
Q: Can I continue using DynamoDB?
👉 Yes, for now. But expect deprecation warnings after 1.11.
Q: Is native S3 locking production-ready?
👉 Yes, HashiCorp has officially documented and recommended it.
Q: What happens if I don’t enable versioning?
👉 Terraform will fail with an error because locking depends on S3 object versions.
Q: Do I need S3 Object Lock (WORM)?
👉 No. S3 Versioning is sufficient. Object Lock is not required.
🎯 Conclusion
Native S3 locking is the future for Terraform on AWS.
✅ Simpler backend.
✅ Lower infrastructure cost.
✅ Easier IAM management.
✅ Future-proof your projects before the old dynamodb_table breaks!
If you haven’t migrated yet — now is the perfect time! 🚀