HashiCorp and AWS have officially rolled out Terraform AWS Provider 6.0, a major release that changes how we manage infrastructure across multiple regions. For years, Terraform users had to juggle multiple provider configurations and aliases to handle regional resources. With this release, that workflow gets streamlined — reducing duplication, improving performance, and simplifying infrastructure as code.<h2>Why This Release Matters</h2>The AWS provider is the glue that connects Terraform code to AWS services. Every resource you create — whether it’s a VPC, EC2 instance, or KMS key — flows through this provider.Until now, each provider block targeted only one AWS region, forcing practitioners to maintain duplicate provider definitions (<code>alias</code> blocks) for every region they needed. This approach worked but was cumbersome, especially for enterprises operating across 10, 20, or more regions.Provider 6.0 changes that. You can now define multiple regions directly at the resource level, using a <code>region</code> argument, all within a single provider configuration. No more cluttered aliases, no more redundant boilerplate.<h2>Key Enhancements in AWS Provider 6.0</h2>Here are the highlights that make this release important:<ul><li>Single provider block for multi-region Manage resources in different regions without loading multiple provider instances. This lowers memory usage and simplifies codebases.</li><li>Per-resource region parameter Every resource now supports an optional <code>region</code> argument (except global services like IAM, Route 53, and CloudFront).</li><li>Global resources remain global Services that don’t belong to a region continue to work as before — unaffected by the new model.</li><li>Improved performance Reduced provider duplication results in faster Terraform initialization and lower memory consumption.</li><li>Better resource imports Import commands now accept a region suffix (<code>@regionID</code>) to simplify bringing existing infrastructure under Terraform management.</li><li>Terraform plugin framework upgrade AWS API clients are mapped per region, making multi-region workflows more efficient and reliable.</li></ul><h2>Example: VPC Peering Across Regions</h2>Previously, you had to define two providers (one per region). Now, you can define both resources in a single configuration:<pre><code class="language-hcl">provider "aws" {
 region = "us-east-1"
}

resource "aws_vpc" "main" {
 cidr_block = "10.0.0.0/16"
}

resource "aws_vpc" "peer" {
 region = "us-west-2"
 cidr_block = "10.1.0.0/16"
}

resource "aws_vpc_peering_connection" "main" {
 vpc_id = aws_vpc.main.id
 peer_vpc_id = aws_vpc.peer.id
 peer_region = "us-west-2"
 auto_accept = false
}

resource "aws_vpc_peering_connection_accepter" "peer" {
 region = "us-west-2"
 vpc_peering_connection_id = aws_vpc_peering_connection.main.id
 auto_accept = true
}
</code></pre>Notice how both VPCs and the accepter resource simply use the <code>region</code> attribute, eliminating the need for a <code>provider "aws" { alias = "peer" }</code> block.<h2>Example: Multi-Region KMS Keys</h2>KMS multi-region keys are another great fit for this feature:<pre><code class="language-hcl">provider "aws" {
 region = "us-west-2"
}

resource "aws_kms_key" "primary" {
 region = "us-east-1"
 description = "Primary multi-region key"
 deletion_window_in_days = 30
 multi_region = true
}

resource "aws_kms_replica_key" "replica" {
 description = "Replica key"
 deletion_window_in_days = 7
 primary_key_arn = aws_kms_key.primary.arn
}
</code></pre><h2>Migrating to Version 6.0</h2>If your current setup uses provider aliases (<code>provider "aws" { alias = "peer" ... }</code>), here’s how to migrate:<ol><li>Upgrade provider Pin the provider to version 6.0 in your configuration:<pre><code class="language-hcl">terraform {
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~&gt; 6.0"
 }
 }
}
</code></pre></li><li>Refresh your state Run:<pre><code class="language-bash">terraform plan -refresh-only
terraform apply -refresh-only
</code></pre></li><li>Update configurations Replace provider aliases with the new <code>region</code> argument at the resource level.<pre><code class="language-hcl"># Old way
resource "aws_kms_key" "test" {
 provider = aws.peer
 description = "Multi-Region key"
 multi_region = true
}

# New way
resource "aws_kms_key" "test" {
 region = "us-west-2"
 description = "Multi-Region key"
 multi_region = true
}
</code></pre></li><li>Re-run <code>terraform init -migrate-state</code> to finalize migration.</li></ol><h2>Things to Keep in Mind</h2><ul><li>This release introduces breaking changes, so carefully test in a non-prod environment first.</li><li>Always pin provider versions in production to avoid surprises:<pre><code class="language-hcl">version = "~&gt; 6.0"
</code></pre></li><li>Multi-region support does not apply to global AWS services — these stay region-agnostic.</li><li>Check the <a target="_blank" rel="noopener noreferrer nofollow" href="https://registry.terraform.io/providers/hashicorp/aws/latest">Terraform Registry upgrade guide</a> for detailed migration notes.</li></ul><h2>Final Thoughts</h2>The Terraform AWS Provider 6.0 release is a big step forward for teams managing AWS infrastructure at scale. By collapsing multiple provider aliases into a single provider block, it makes configurations cleaner, faster, and easier to maintain — especially in multi-region deployments.For DevOps teams, this means less boilerplate, lower memory usage, and a smoother developer experience when working with Terraform and AWS.

Terraform AWS Provider 6.0: A New Era of Multi-Region Infrastructure Management

For years, the recommended way to securely manage Terraform state in AWS was to store state in S3 and use DynamoDB for locking. This worked well, but it also meant extra AWS resources, extra IAM permissions, and more setup overhead. Now that’s changing. With the latest Terraform updates, the S3 backend supports its own native lockfile mechanism. No DynamoDB required.Let’s dive into what this means, how it works, and how you can migrate.<h2>Why Terraform Needs State Locking</h2>Terraform stores information about your infrastructure in a state file (<code>terraform.tfstate</code>). When you run <code>terraform apply</code>, Terraform updates this state file after making changes in the cloud.But what happens if two engineers (or a CI/CD pipeline + an engineer) run <code>apply</code> at the same time?<ul><li>They both read the “old” state.</li><li>They both make changes.</li><li>They overwrite each other’s updates.</li></ul>The result? State corruption.That’s why Terraform implements state locking: only one run can hold the lock at a time.<h2>The Old Way: DynamoDB Locking</h2>Traditionally, we solved this by:<ul><li>Storing state in S3</li><li>Using a DynamoDB table for locks</li></ul>Terraform would insert a lock entry in DynamoDB at the start of a run, and delete it when finished. This worked, but it required:<ul><li>Creating and maintaining a DynamoDB table</li><li>Adding IAM permissions for DynamoDB</li><li>Paying a tiny but nonzero cost for DynamoDB</li></ul><h2>The New Way: S3 Lockfile</h2>Terraform now supports S3-native locking. Instead of DynamoDB, it uses a <code>.tflock</code> object stored in the same bucket alongside your state file.Example:<pre><code class="language-javascript">my-bucket/
 └── envs/prod/network/terraform.tfstate
 └── envs/prod/network/terraform.tfstate.tflock 👈 new lockfile
</code></pre>When you run <code>terraform apply</code>:<ol><li>Terraform creates the <code>.tflock</code> file.</li><li>If another process tries to run, it fails because the lockfile exists.</li><li>When the run finishes, Terraform deletes the <code>.tflock</code> file.</li></ol>Simple. Reliable. No DynamoDB.<h2>How to Enable S3 Lockfile</h2>In your Terraform backend configuration:<pre><code class="language-hcl">terraform {
 backend "s3" {
 bucket = "my-terraform-state"
 key = "envs/prod/network/terraform.tfstate"
 region = "ap-south-1"
 encrypt = true
 use_lockfile = true # 👈 enables the new lockfile mechanism
 }
}
</code></pre>Re-initialize:<pre><code class="language-bash">terraform init -migrate-state
</code></pre><h2>IAM Permissions for S3 Lockfile</h2>In addition to normal S3 permissions for the state file, you’ll need Get/Put/Delete on the <code>.tflock</code> object.Here’s a minimal IAM policy snippet:<pre><code class="language-json">{
 "Effect": "Allow",
 "Action": [
 "s3:GetObject",
 "s3:PutObject",
 "s3:DeleteObject"
 ],
 "Resource": "arn:aws:s3:::my-terraform-state/envs/prod/network/terraform.tfstate.tflock"
}
</code></pre>Don’t forget to also allow access to the state file itself.<h2>Migrating From DynamoDB Locking</h2>If your backend currently looks like this:<pre><code class="language-hcl">backend "s3" {
 bucket = "my-terraform-state"
 key = "envs/prod/network/terraform.tfstate"
 region = "ap-south-1"
 dynamodb_table = "terraform-locks" # old way
}
</code></pre>Change it to:<pre><code class="language-hcl">backend "s3" {
 bucket = "my-terraform-state"
 key = "envs/prod/network/terraform.tfstate"
 region = "ap-south-1"
 use_lockfile = true
}
</code></pre>Then run:<pre><code class="language-bash">terraform init -migrate-state
</code></pre>Terraform can temporarily use both DynamoDB and lockfile, but DynamoDB locking is now deprecated and will be removed in a future release. Plan to migrate sooner rather than later.<h2>Best Practices</h2><ul><li>Enable S3 Versioning → Always turn on bucket versioning for your state bucket. This lets you roll back if state corruption happens.</li><li>Force Unlock → If a run dies and the <code>.tflock</code> file remains, use <code>terraform force-unlock &lt;LOCK_ID&gt;</code>.</li><li>CI/CD Discipline → Let your CI/CD pipelines handle <code>terraform apply</code>, and keep local runs for <code>plan</code> to avoid collisions.</li><li>Restrict IAM → Make sure only trusted CI roles or engineers can access both state and lock files.</li></ul>

Terraform

Terraform AWS Provider 6.0: A New Era of Multi-Region Infrastructure Management

Terraform S3 Lockfile: The New Way to Lock State Without DynamoDB