Do I need a separate service for state locking on every provider?

No, only AWS S3 requires a companion service (DynamoDB) for locking, Azure Blob Storage and GCS both provide native locking (blob lease-based and object locking respectively) without any additional resource. OCI is the outlier with no native locking mechanism at all, requiring a workaround (HTTP backend with custom locking, or careful process discipline) if you need to prevent concurrent applies from corrupting state.

What happens if two engineers run terraform apply at the same time against an OCI Object Storage backend?

Without a locking mechanism in place, both applies can proceed concurrently and corrupt the state file, since OCI Object Storage doesn't provide native state locking the way S3+DynamoDB, Azure Blob, or GCS do. This is a genuine architectural gap, not just a missing convenience feature, teams on OCI need to either implement the HTTP backend with custom locking or enforce apply discipline (a CI/CD pipeline as the sole apply path) to avoid this.

Is enabling versioning on the state bucket actually necessary, or just a nice-to-have?

It's close to essential. Object/blob versioning on the state storage (S3 versioning, GCS object versioning, Azure blob versioning) is what lets you recover a previous state file after a bad apply corrupts or loses data in the current one, without it, there's no built-in path back to a known-good state short of manual reconstruction.

Multi-Cloud Terraform Backend Compare

MonitoringMulti-Cloud

Compare Terraform state backend options across AWS S3, Azure Blob, GCS, and OCI Object Storage.

Filter Terraform Backend Comparison

Raw Output

Output will appear here...

What This Tool Does

A comparison of Terraform remote state backend options across AWS (S3 + DynamoDB), Azure (Blob Storage), GCP (Cloud Storage), and OCI (Object Storage), and state locking is the detail that most affects setup complexity: Azure Blob and GCS both provide native lease/object-based locking with no separate service required, AWS needs a companion DynamoDB table specifically for locking (a second resource to provision and pay for), and OCI has no native locking mechanism at all, requiring either the HTTP backend with custom locking or accepting the risk of concurrent-apply state corruption without it.

Technical Details

The comparison table is a static, hand-maintained dataset of feature rows grouped by category (overview, storage, security, availability, pricing) with free-text search across all fields; it's a reference snapshot, not a live specs feed, verify current locking mechanisms and setup steps directly against Terraform's provider documentation before finalizing a backend choice.

Common Use Cases

1Choosing GCS or Azure Blob over AWS S3 specifically to avoid provisioning and maintaining a separate DynamoDB table just for state locking, when starting a new Terraform project from scratch.
2Implementing a custom locking mechanism for an OCI Object Storage backend, since OCI has no native state locking, a gap that needs deliberate mitigation (HTTP backend with custom locking, or process discipline) before multiple engineers apply against the same state concurrently.
3Enabling S3 versioning (or GCS/Blob equivalent) as the actual mechanism providing state history and rollback capability, since accidentally disabling versioning on a state bucket removes your only path back to a previous state version after a bad apply.
4Migrating a Terraform backend between providers and re-mapping workspace representation, since AWS stores workspaces as key prefixes within the same S3 prefix, Azure and OCI use separate blobs/objects in the same container/bucket, and GCP uses separate objects with a prefix, structurally similar but not byte-identical in layout.

Common Questions

Do I need a separate service for state locking on every provider?: No, only AWS S3 requires a companion service (DynamoDB) for locking, Azure Blob Storage and GCS both provide native locking (blob lease-based and object locking respectively) without any additional resource. OCI is the outlier with no native locking mechanism at all, requiring a workaround (HTTP backend with custom locking, or careful process discipline) if you need to prevent concurrent applies from corrupting state.
What happens if two engineers run terraform apply at the same time against an OCI Object Storage backend?: Without a locking mechanism in place, both applies can proceed concurrently and corrupt the state file, since OCI Object Storage doesn't provide native state locking the way S3+DynamoDB, Azure Blob, or GCS do. This is a genuine architectural gap, not just a missing convenience feature, teams on OCI need to either implement the HTTP backend with custom locking or enforce apply discipline (a CI/CD pipeline as the sole apply path) to avoid this.
Is enabling versioning on the state bucket actually necessary, or just a nice-to-have?: It's close to essential. Object/blob versioning on the state storage (S3 versioning, GCS object versioning, Azure blob versioning) is what lets you recover a previous state file after a bad apply corrupts or loses data in the current one, without it, there's no built-in path back to a known-good state short of manual reconstruction.

Expert Tips

TIP

AWS's requirement for a separate DynamoDB locking table is a real extra piece of infrastructure to secure and maintain (with its own IAM policy), budget for it explicitly rather than treating the S3 backend setup as 'just a bucket'.

TIP

OCI's lack of native locking is the single biggest structural gap in this comparison, a team standardizing on OCI for Terraform state needs an explicit plan for concurrent-apply prevention from day one, not a workaround bolted on after a state corruption incident.

TIP

Versioning and MFA delete (on S3) or soft delete (Azure) protect against accidental state deletion or corruption, but none of these backends protect against a bad apply that successfully applies a wrong plan, versioning gets you back to a previous state file, it doesn't undo real infrastructure changes already made.

Related Learning Guides

Managed Database Services Comparison26 min read
Cloud Cost Comparison 202624 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.