Planning and Estimating

Estimate cost before building: use provider pricing calculators for new designs and Infracost in pull requests to show the monthly cost impact of Terraform changes, so cost becomes a design input rather than a surprise.

The cheapest time to change an architecture is before it exists. Planning and estimating puts a price on a design while it is still a diagram or a pull request.

flowchart LR
  IDEA["Design or Terraform change"] --> CALC["Pricing calculator or Infracost"]
  CALC --> EST["Monthly estimate and drivers"]
  EST --> REV["Review: is it worth it?"]
  REV -->|yes| BUILD["Build and add to forecast"]
  REV -->|no| ALT["Try a cheaper alternative"]
  ALT --> CALC
  %% step IDEA: Every new service, environment or big change starts as a design or a pull request.
  %% step CALC: Calculators price designs; Infracost reads Terraform and prices the resources it will create.
  %% step EST: The estimate shows monthly cost and the biggest drivers, with usage assumptions stated.
  %% step REV: The team checks the cost against the value, just like latency or security.
  %% step BUILD: Approved estimates feed the forecast so finance is not surprised.
  %% step ALT: If it is too expensive, compare options: smaller sizes, managed vs self-run, another region.

Tools

Tool	Use
AWS Pricing Calculator, Azure Pricing Calculator, Google Cloud Pricing Calculator	Price a design before code exists; share the estimate link
Provider price list APIs	Automate lookups of unit prices
Infracost	Reads Terraform/OpenTofu, shows monthly cost and the cost diff of a change, comments on pull requests

Infracost in practice

infracost breakdown --path .                                 # monthly cost of this Terraform project
infracost breakdown --path . --format json --out-file base.json   # save a baseline on main
infracost diff --path . --compare-to base.json               # cost change of the branch

Usage-based resources (data transfer, Lambda invocations, S3 requests) need usage assumptions, set in an infracost-usage.yml file; otherwise they show as "depends on usage".

Estimates are assumptions

Write down the drivers next to the number: "2 × m7g.large, 500 GB gp3, ~2 TB egress/month". When the real bill arrives, compare and learn which assumptions were wrong. Big designs should include a cost section in the design document, reviewed like reliability and security.

Traps: estimating only compute and forgetting storage, data transfer and logging; showing a single number with no assumptions; and treating the estimate as a promise rather than a starting point for the forecast.