Cost Estimation on Plans

Price the proposed plan before an apply changes the bill

A Terraform plan can reveal a bill change while the change is still reviewable

A code review that checks only whether a plan succeeds can miss a costly change. Replacing a small database instance with a memory-optimized class may be functionally valid and still raise monthly spend by hundreds of dollars. Plan-based cost estimation translates proposed resources into an approximate recurring cost before apply. Tools such as Infracost and cost estimation features in managed Terraform platforms can read the planned resource graph, apply pricing data, and present a monthly estimate or delta alongside the infrastructure diff.

The important comparison is usually not the absolute total alone. A baseline represents the current or target branch configuration; the proposed branch is compared against it. If the current environment is estimated at $1,200 per month and a pull request proposes $1,460, the useful figure is the $260 increase and which resources account for it. A replacement may appear as both a removal and an addition, while a resize may be presented as a delta for one resource. Reviewers need to see the assumptions and resource-level breakdown, not just a green or red total.

A common workflow generates a Terraform plan in CI, exports or uploads plan data for the cost tool, and posts a comment to the pull request. The tool needs enough configuration and provider context to interpret planned resources, but it should not execute an apply. Keep the plan artifact tied to the commit that produced it. When the pull request changes, regenerate the plan and estimate; an estimate from an earlier commit can describe resources that no longer exist in the diff.

Separate estimation from approval policy. A cost report provides information; a budget threshold or policy decides whether a change requires approval or must be rejected. A team might allow a $20 monthly increase automatically, request a service owner above $100, and require finance review for a large commitment. Put the threshold and escalation owner in repository policy so the same change is not judged differently by each reviewer. A policy should still permit justified increases for capacity, reliability, or security work.

Cost tools price recognized resource attributes using public or configured pricing catalogs. Their estimates depend on region, instance family, storage class, capacity, and declared usage assumptions. They may not know actual request volume, utilization, discounts, savings plans, enterprise agreements, support fees, or all network transfer patterns. A resource billed by the hour can be estimated as if it ran continuously, even if a development environment is normally stopped overnight. A monthly figure is an estimate for a modeled usage period, not a promised invoice.

In an interview, describe how a cost estimate fits before apply and what makes it actionable: a baseline, a resource-level delta, assumptions, and an owner for approval. Mention that estimate quality depends on usage and pricing inputs. This shows you treat cost as a reviewable operational property rather than assuming Terraform will optimize it automatically.

The plan remains the source of proposed infrastructure changes. Cost estimation should not mutate HCL or alter the plan to fit a budget. If the estimate is too high, the team can revise the resource size, retention period, or architecture and generate a new plan. That keeps cost review auditable: reviewers can see both the technical diff and the cost effect produced from the same configuration revision.

The estimate should distinguish recurring cost from one-time or usage-dependent charges where the tool supports it. A larger disk can create ongoing storage cost; a snapshot may accrue based on retained data; a public endpoint can incur transfer or request charges driven by traffic. If one of these dimensions is not modeled, surface it as a limitation and ask the service owner for a usage estimate. Treat missing data as uncertainty to manage rather than silently interpreting it as zero.

Make the pull request cost report reproducible and reviewable

Connect the estimate to the exact plan reviewers approve

A reliable CI job runs formatting and validation first, creates a plan for the pull request revision, and passes that plan or its structured representation to the cost estimator. The report should be attached to the same pull request and commit status as the plan. If the branch advances, the workflow should invalidate or replace the old report. Otherwise, a reviewer may approve a price delta for a plan that is no longer the one Terraform will apply.

For an open source or cloud-connected workflow, avoid placing long-lived cloud credentials in the cost-estimation step unless the tool genuinely needs them. Some tools can estimate from plan JSON without querying a cloud account; others may need provider information or remote pricing configuration. Scope any credentials to read-only access and the smallest account set. Do not expose a binary plan or plan JSON publicly without checking its sensitivity: plan data can contain values derived from secrets even when CLI output redacts them.

Choose the baseline deliberately. Comparing a pull request to its base branch answers ?what does this change add?? Comparing the entire workspace to zero answers ?what does this environment cost?? Both can be useful but answer different questions. A drifted or stale baseline can produce misleading deltas. For a long-running branch, refresh the baseline or rebase it, then rerun plan and cost estimation. Document whether the report includes shared infrastructure, existing unmanaged resources, or only resources represented in the Terraform state.

A reviewer should be able to answer four questions from the report: which resources changed, which assumptions were used, what the monthly delta is, and who must approve the change. Resource tags can connect infrastructure to a team or cost center, but tags do not guarantee the provider's billing report will match the estimate. Keep ownership metadata consistent across modules and accounts. When a resource is intentionally expensive, put the reason and expected lifetime in the pull request description.

A practical policy can evaluate both absolute cost and delta. Absolute cost catches a new environment that is too large even when the delta comparison lacks a meaningful baseline. Delta catches a modest change to an existing service. Avoid a single universal dollar cutoff across services: an increase of $300 may be immaterial for a production data platform but significant for a small internal tool. Add a time-bound exception process so temporary migrations do not become permanent unreviewed spend.

When the report changes unexpectedly, inspect plan actions before blaming pricing data. A replacement can double-count old and new resources during the transition. A module can create more instances through count or for_each. A provider alias can place resources in a different region. A change in a usage assumption or pricing catalog can also shift the estimate even when HCL is unchanged. Preserve the prior report and identify which input changed so the team can distinguish infrastructure drift from estimator updates.

Cost review should occur with security and reliability review, not after them. A cheaper configuration that removes backups or weakens redundancy is not automatically a good change. Conversely, a more expensive instance may be justified by a latency target or recovery objective. Ask the author to connect the cost delta to a service requirement, expected usage, and alternatives considered. The goal is informed trade-offs, not minimizing one number regardless of impact.

For implementation practice, create a pull request that increases a database tier and verify the comment identifies the resource and monthly change. Then modify the branch and confirm the report refreshes. Test a plan that removes a resource and one that replaces it. Verify that approval gates block only when the configured policy says they should, and that an authorized exception is recorded with a reason. This validates the workflow rather than merely proving the estimator binary can run.

Treat cost estimates as a model with visible uncertainty

The estimate is useful only when its omissions are visible

Infrastructure pricing is not a single lookup for every resource. A virtual machine may have an hourly rate, while disks, snapshots, IP addresses, managed control planes, and network egress have separate charges. Serverless products can bill per request, execution duration, memory, or provisioned capacity. A plan reveals configuration but often cannot predict future traffic, data growth, cache hit rate, or the number of cross-region bytes. A cost tool can price declared capacity accurately and still understate the eventual invoice because actual usage is unknown.

Pricing catalogs can also lag provider changes or differ from negotiated rates. Public list price may exceed the organization's effective rate after a commitment discount, or a usage-based resource may be cheaper only above a particular volume. A team should know whether reports use list price, enterprise pricing, or a configured discount. Compare a representative estimate with actual billing data periodically. Large differences may reveal bad usage assumptions, missing resource types, or a configuration that behaves differently from the model.

Cost estimates are especially helpful for relative comparisons. If two proposed designs use the same pricing source and usage assumptions, their difference can guide a decision even when absolute totals are imperfect. Compare a larger always-on instance with a smaller autoscaled fleet, including the trade-off in latency, redundancy, and operational complexity. Add expected usage when known. State what is excluded, such as inter-region transfer, support, tax, or log ingestion, so a small displayed delta is not mistaken for the full total cost of ownership.

Do not treat a price threshold as a substitute for architecture judgment. The cheapest option may have a larger failure domain, weak recovery, or higher engineering cost. A cost policy should allow a documented exception when the service requirement warrants it and should identify who is accountable for the recurring charge. Set an expiration or review date for temporary resources such as migration replicas and test environments. Cost becomes hard to manage when nobody owns the estimate after deployment.

A useful operational loop compares the pre-apply estimate, actual bill attribution, and service usage after deployment. If the estimate assumed continuous runtime but an environment is usually stopped, the model may overstate monthly cost. If a service uses more requests or transfer than expected, the estimate may understate it. Update assumptions and the cost report process rather than hiding the discrepancy. Forecasting improves when teams capture utilization and ownership at the same time as infrastructure changes.

Cost output can include sensitive resource names, account identifiers, or topology details. Treat pull request comments according to repository visibility and avoid including secret values. Store plan artifacts with restricted permissions and short retention. The cost report usually needs only the pricing-relevant resource attributes; do not publish more plan data than necessary. This complements Terraform's sensitive-value handling, which redacts display but does not encrypt state or plan artifacts.

In an interview, explain the limits plainly: plan-based estimation sees configured resources and catalog pricing but cannot know future workload volume or every discount. Then outline how you would validate estimates against actual billing and use thresholds with owners and exceptions. A mature system measures prediction error and revises assumptions instead of presenting the estimate as an invoice guarantee.

Use this topic with Team Collaboration Guardrails to define approvals and ownership, and review Drift Detection Scanning when actual deployed resources differ from configuration. The relationship matters: a cost delta is meaningful only when the baseline reflects what is running and the person paying for the change is part of the review.

Flashcards

Question

What is plan-based cost estimation?

Click to reveal answer

Answer

Pricing proposed resources from a Terraform plan before apply so reviewers can assess recurring cost changes.

Question

Why report a cost delta against a baseline?

Click to reveal answer

Answer

It isolates the estimated change introduced by the pull request rather than showing only a total.

Question

Name two reasons an estimate may differ from the bill.

Click to reveal answer

Answer

Usage assumptions, negotiated discounts, network transfer, support charges, and pricing catalog timing can all differ.

Question

When should CI regenerate the cost estimate?

Click to reveal answer

Answer

After each relevant pull request revision when a new plan is generated.

Question

What should a cost exception include?

Click to reveal answer

Answer

A reason tied to service needs, an accountable approver, and a review or expiration point where appropriate.

Revision Notes

Key Takeaways

1. Estimate the proposed plan before apply and tie the report to the exact commit under review.
2. A baseline and resource-level delta make cost changes easier to review than a total alone.
3. Estimates rely on pricing and usage assumptions and may omit real workload or billing details.
4. Use cost thresholds with owners and an exception path that considers reliability and security.
5. Compare estimates with actual billing over time and improve assumptions when they diverge.

Interview Tips

• Explain how the plan report reaches a pull request and why it must refresh when the branch changes.
• Distinguish recurring infrastructure estimates from usage, discount, and support charges.
• Describe how a team can set approval thresholds without blindly rejecting valuable capacity changes.
• Mention validation against actual bills and how you handle estimation uncertainty.

Cheat Sheet