Terraform remote backend cost compared: object storage, locking, and scale

Quick answer

Object storage backends for Terraform state cost pennies in storage but can accumulate request and versioning charges at scale. A team with 400 workspaces running plans every pull request might store under 1 GB yet make millions of requests a year, landing in the 5 to 40 dollars a month range, plus a locking mechanism. Managed backends charge per resource under management instead, which can reach thousands per month. The cost drivers are request volume, version retention, and the number of workspaces, not state size.

Terraform state is small. A large workspace's state file might be 2 MB, and a thousand of them fit in 2 GB. Because of that, backend cost gets ignored, which is usually correct and occasionally wrong in an expensive way.

The cost does not come from storage. It comes from requests, from versioning that nobody prunes, and from the per resource pricing of managed offerings once your estate gets large.

What the options cost

Backend	What you pay for	Typical monthly cost
Object storage plus lock table	Storage, requests, lock reads and writes	About 1 to 40 dollars
Object storage with native locking	Storage and requests only	About 1 to 30 dollars
Blob storage with lease locking	Storage, transactions	About 1 to 25 dollars
Managed run service	Per managed resource	Scales with estate size
Self hosted state service on a VM	Instance, storage, operations	About 20 to 60 dollars plus your time

For most organizations the object storage option is an obviously good deal. It becomes interesting only at high workspace counts and high plan frequency, which is exactly what a mature platform produces.

Requests, not bytes

Every plan reads state, every apply writes it, and every operation takes and releases a lock. With 400 workspaces, 20 plans per workspace per month from pull requests and CI, and several requests per operation, you land in the low millions of requests a year.

At object storage request pricing that is still single digit to low double digit dollars per month, but the pattern matters when automation misbehaves. A polling loop that checks state every 30 seconds across 400 workspaces makes about 35 million requests a month, and that is no longer a rounding error. Request charges are the same mechanism described inS3 request fees.

Versioning that never gets pruned

Object versioning on a state bucket is the right default, because it is the cheapest possible recovery from a corrupted apply. Left unmanaged, it is also a slow leak: every apply writes a new version, and a busy workspace can produce hundreds of versions a year.

Storage is still small in absolute terms, but the real cost shows up in list operations and in incident response, where finding the right version among 900 is painful. Apply a lifecycle rule that keeps 90 days of noncurrent versions and expires the rest, and keep the bucket focused. The same logic asversioning storage cost applies.

Locking options and their price

The classic pattern pairs object storage with a key value lock table. On demand capacity makes that table nearly free at Terraform's request volumes, often under 1 dollar a month, but a table accidentally provisioned with fixed capacity can cost 20 to 30 dollars a month doing nothing.

Newer native locking in object storage removes the separate table entirely, which is one fewer resource, one fewer set of permissions, and one fewer bill. If your provider version supports it, taking that path simplifies both the architecture and the cost model.

Per resource pricing changes the math

Managed run services usually price per resource under management rather than per state file. That model is pleasant at 200 resources and expensive at 50,000, and infrastructure estates grow without anyone deciding to.

Before committing, count resources across all workspaces and project two years of growth. Include the ones people forget: every subnet, route table entry, IAM policy attachment, and DNS record is a managed resource. Estates routinely have 5 to 10 times more resources than engineers estimate.

State layout drives cost more than the backend

One giant state file is slow, risky, and makes every plan read megabytes. Thousands of tiny ones multiply request volume, lock operations, and per resource fees. Somewhere in between, typically one state per service per environment, is both operationally sane and cheap.

Splitting state also shrinks plan times, which reduces CI runner minutes, and that saving usually dwarfs the backend bill itself. A plan that reads a 40 MB state file and evaluates 3,000 resources burns runner time on every pull request, so state layout is a CI cost decision as much as a storage one. The tradeoffs are explored in Terraform state storage cost.

Keep the backend boring and measure what it enables

The practical answer for most platform teams is object storage with versioning, a lifecycle rule, native or table based locking, and one state per service per environment. That costs perhaps 10 dollars a month and will not be the thing that surprises you.

What deserves attention is the infrastructure the state describes. c3x reads the plan JSON produced against whatever backend you chose and prices the resources statically, with no cloud credentials, so the same pipeline that manages state can report the monthly cost of what it is about to create. The backend is plumbing, and the resources are the bill.

FAQ

How much does a Terraform remote state backend cost?

Object storage backends usually run about 1 to 40 dollars a month including requests and a locking mechanism, because state files are tiny and the charges come from request volume rather than bytes. Managed run services price per resource under management instead, which is cheap at 200 resources and expensive once an estate reaches tens of thousands.

What actually drives Terraform backend cost?

Requests, version retention, and workspace count, not state size. With 400 workspaces and 20 plans each per month you reach low millions of requests a year. Misbehaving automation makes it worse: a loop polling state every 30 seconds across 400 workspaces generates roughly 35 million requests a month, which stops being a rounding error.

Should I enable versioning on my Terraform state bucket?

Yes, it is the cheapest recovery from a corrupted apply. But add a lifecycle rule, because every apply writes a new version and a busy workspace produces hundreds a year. Keeping about 90 days of noncurrent versions and expiring the rest keeps storage small and, more importantly, makes finding the right version during an incident practical.

Is a separate lock table still necessary?

Not always. The classic pattern pairs object storage with a key value lock table, which on demand capacity keeps under a dollar a month, though a table accidentally set to provisioned capacity can cost 20 to 30 dollars doing nothing. Newer native locking in object storage removes the table entirely, simplifying permissions, architecture, and the bill.

How does state layout affect cost?

More than the backend choice does. One giant state file makes every plan read megabytes and evaluate thousands of resources, burning CI runner minutes on every pull request. Thousands of tiny states multiply requests, locks, and per resource fees. One state per service per environment is usually both operationally sane and cheap, and the CI time saved typically exceeds the backend bill.

What to do next

The backend is plumbing, the resources are the bill. C3X prices your Terraform plan with no cloud credentials. Start with the quickstart.