Skip to content
Calcrivo

Terraform Backend Storage Calculator

Calculate total remote backend storage needed across workspaces and retained state file versions.

Inputs

MB

Size of a single terraform.tfstate file.

workspaces

Number of workspaces, each with its own state file.

versions

Number of historical state versions kept (e.g. S3 versioning, Terraform Cloud history).

Total Backend Storage

300.0MB

Total Backend Storage

0.293GB

Storage per Workspace

75.0MB

Step by step

  1. Storage: state size × workspaces × versions

    2.5MB × 4 × 30

    = 300.0MB

  2. Per-workspace storage

    2.5MB × 30

    = 75.0MB

How it works

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

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.

You might also need