Terraform Backend Storage Calculator

Project remote backend storage needs across all Terraform state files and versions.

About Terraform Backend Storage Calculator

Remote backends like S3, Terraform Cloud or GCS often retain historical state versions for rollback and audit purposes. Formula: storage = state_size × workspaces × versions_retained. State files are typically small (KB to a few MB), so this is rarely a meaningful cost driver on its own — but it matters for retention policy planning and understanding backend object counts at scale.

Formula

storage_MB = state_size_MB × workspaces × versions_retained

state_size_MB: Size of a single state file (MB)
workspaces: Number of workspaces
versions_retained: Historical state versions kept

Worked example

With the default values below, Terraform Backend Storage Calculator returns Total Backend Storage of 300.0. Change any input above and every figure here is recalculated in your browser.

Inputs used

State File Sizeaccepts 0–100,000 MB: 2.5 MB
Number of Workspacesaccepts 1–100,000 workspaces: 4 workspaces
Versions Retainedaccepts 1–1,000,000 versions: 30 versions

Results

Total Backend Storage: 300.0 MB
Total Backend Storage: 0.293 GB
Storage per Workspace: 75.0 MB

Step by step

1Storage: state size × workspaces × versions= 300.0MB
2Per-workspace storage= 75.0MB

Assumptions and limits

The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Do I need to keep every historical state version?

It depends on your backend's versioning policy — S3 bucket versioning with a lifecycle rule can auto-expire old versions after N days, while Terraform Cloud retains state history separately from your storage cost concerns.

Why would state file size grow over time?

As you manage more resources, add more complex resource attributes (e.g. large `for_each` maps, sensitive value tracking), or nest more modules, the JSON-serialized state naturally grows.

Is backend storage cost typically significant?

Rarely on its own — even hundreds of MB of state history costs cents per month on S3-class storage. It's more useful to track for object count limits or audit/compliance retention requirements than for cost optimization.

How can I reduce state file size directly?

Split very large monolithic configurations into smaller, independently-applied root modules — this also improves plan/apply speed and reduces blast radius, with smaller per-module state as a side benefit.