Project remote backend storage needs across all Terraform state files and versions.
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.
storage_MB = state_size_MB × workspaces × versions_retained
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.
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.
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.
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.