Terraform workspace cost tracking: pricing per environment

Quick answer

Terraform workspaces reuse one configuration across environments, feeding each a different set of variables, so dev, staging, and production created from the same code carry very different costs. You track cost per workspace by pricing the plan for each workspace's variables separately, since the same resources sized by different variables produce different bills. Comparing workspace costs surfaces the common problem of a dev or staging environment sized like production. The principle is price each workspace with its own variables, because the cost lives in the values, not the shared code.

Terraform workspaces are a common way to run the same configuration for several environments: one codebase, a workspace each for dev, staging, and production, differing only in variable values. That shared code hides a cost trap, because the variables that differ between workspaces, instance sizes, replica counts, retention periods, are exactly what drives cost. Tracking cost per workspace keeps each environment's spend honest.

Same code, different cost

Workspace	Typical variable sizing	Relative cost
dev	Small instances, single node	Low
staging	Medium, production-like subset	Moderate
prod	Large, multi-node, replicated	High

Because the code is shared, the only thing separating a cheap dev workspace from an expensive production one is the variable set. That is fine when the sizing is intentional, but it is easy for a dev workspace to inherit production-sized defaults, or for a staging environment to run a full production replica when a smaller one would do. You cannot see this from the code alone; you have to price each workspace.

Pricing per workspace

To price a workspace, plan it with its own variables and price the resulting resources. Running this for every workspace produces a per-environment cost breakdown from a single configuration. Because static pricing reads theplan JSON and needs no cloud credentials, you can price all workspaces in CI, even ones you have not deployed, and compare them side by side. c3x prices whichever plan you hand it, so switching workspace variables and re-running gives each environment's number.

Catching oversized non-prod

The most valuable finding from per-workspace pricing is the oversized non-production environment. A dev workspace costing 60 percent of production is a red flag: development rarely needs that. Comparing workspace costs makes these obvious, and the fix is usually a variable change, smaller instances, fewer replicas, shorter retention, applied only to the non-prod workspaces. This is the workspace-level version ofdev and staging optimization.

Cost in the PR, per workspace

When a pull request changes the shared configuration, it affects every workspace, so the cost impact differs per environment. A change that adds a replica adds one replica's cost to dev but perhaps three to production, depending on variables. Pricing the change against each workspace's variables shows the full blast radius of a shared-code change, which a single estimate would miss. Report the per-workspace delta on the PR so reviewers see that a config tweak lands differently across environments.

Keeping environments proportionate

Set an expectation for the cost ratio between environments, dev a small fraction of production, staging a defined portion, and use per-workspace pricing to hold to it. When a workspace drifts out of proportion, the numbers flag it. Price each workspace against theresource catalog so the comparison is grounded in real rates and the ratios you enforce reflect true spend.

FAQ

Why do Terraform workspaces have different costs?

Because workspaces reuse one configuration across environments, feeding each a different set of variables, and those variables, instance sizes, replica counts, retention periods, are exactly what drives cost. So dev, staging, and production created from the same code carry very different bills. The cost lives in the variable values, not the shared code, which is why you must price each workspace separately.

How do I track cost per Terraform workspace?

Plan each workspace with its own variables and price the resulting resources, producing a per-environment breakdown from a single configuration. Because static pricing reads the plan JSON and needs no cloud credentials, you can price all workspaces in CI, even undeployed ones, and compare them side by side to see how the same code costs different amounts per environment.

How do I catch an oversized non-production environment?

Compare workspace costs: a dev workspace costing a large fraction of production is a red flag, since development rarely needs that sizing. Per-workspace pricing makes these obvious, and the fix is usually a variable change, smaller instances, fewer replicas, or shorter retention, applied only to the non-prod workspaces without touching the shared code.

How does a shared config change affect each workspace's cost?

Because the configuration is shared, a change affects every workspace, but its cost impact differs per environment depending on variables: adding a replica adds one replica's cost to dev but perhaps three to production. Pricing the change against each workspace's variables shows the full blast radius that a single estimate would miss, so report the per-workspace delta on the PR.

How does C3X track per-workspace cost?

C3X prices whichever Terraform plan you hand it against a live catalog with no cloud credentials, so switching workspace variables and re-running produces each environment's cost. That lets you compare dev, staging, and production built from the same configuration, catch oversized non-prod environments, and report the per-workspace cost delta of a shared-config change on the pull request.

What to do next

Price each environment from shared code. C3X prices any Terraform plan, so every workspace gets its own number. Start with the quickstart.