Cutting Cloud Bills With Infracost in Your Terraform

The bill for that oversized RDS instance wasn’t decided by finance. It was decided in a Terraform pull request, by an engineer who picked db.r5.4xlarge because it was the example in a doc, reviewed by someone who had no idea what that line cost per month. Cloud overspend is almost always committed long before it’s noticed — usually 30 days later, in a billing dashboard, by someone who can’t easily trace it back to a single line of HCL.

Infracost closes that gap. It puts a dollar figure on a Terraform plan before you merge it, so the cost of a change is visible at the moment it’s cheapest to change your mind. Here’s how I wire it in.

What Infracost does

Infracost reads your Terraform — either the code or a plan JSON — figures out which resources have a price, looks them up against cloud pricing, and produces a monthly cost estimate plus a diff showing how a change moves the bill. It’s not a billing tool; it’s a forecast, run at PR time.

The quickest local taste:

infracost breakdown --path .

You get a per-resource monthly breakdown and a total. The numbers are estimates — they can’t know your actual data-transfer or request volume — but for the resources that dominate most bills (compute, databases, load balancers, NAT gateways), they’re close enough to make good decisions.

The real value is the diff

A breakdown is interesting once. The diff is what changes behavior. Infracost can compare the cost of your branch against the base and show only the delta:

infracost diff --path . --compare-to infracost-base.json

The output reads like a financial code review:

~ aws_db_instance.main
  +$1,840/month

  ~ instance_class
    db.r5.large → db.r5.4xlarge  +$1,840

Monthly cost change: +$1,840 (+612%)

That +612% in a PR comment is a conversation starter. Maybe the upsize is justified — but now it’s a decision, made deliberately, instead of a number nobody saw.

Wiring it into pull requests

The pattern that actually changes behavior is a PR comment on every plan. Infracost’s CI integration posts the cost diff right into the pull request, next to the code, where reviewers already are. The flow:

CI runs terraform plan and exports plan JSON.
infracost breakdown --path plan.json --format json --out-file infracost.json.
infracost comment posts (or updates) a comment on the PR with the diff.

terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > plan.json

infracost breakdown --path plan.json \
  --format json --out-file infracost.json

infracost comment github --path infracost.json \
  --repo "$REPO" --pull-request "$PR" \
  --github-token "$GITHUB_TOKEN"

Now every PR that touches infrastructure carries a price tag. The cultural shift is real: engineers start sizing things deliberately because they know the number will show up where their teammates can see it.

Enforcing a cost ceiling

Comments inform; sometimes you want to gate. Infracost can fail the build when a change exceeds a threshold, using a policy:

version: 0.1
policies:
  - name: monthly-increase-limit
    cost:
      total_monthly_cost:
        increase_limit: 500

A PR that adds more than $500/month to the bill fails until someone with authority approves it. I keep this threshold generous — the goal isn’t to block legitimate growth, it’s to make sure a five-figure mistake can’t sail through unnoticed. Pair it with policy-as-code that blocks oversized instance types outright, and you’ve got both a hard rule and a soft budget.

Usage-based costs and honest estimates

Infracost can’t guess your traffic, so by default it leaves out usage-based costs (S3 requests, Lambda invocations, data transfer). You can feed it assumptions with a usage file:

version: 0.1
resource_usage:
  aws_lambda_function.api:
    monthly_requests: 10000000
    request_duration_ms: 250

Use this for the handful of usage-driven resources that matter, and be honest about the assumptions. The estimate is only as good as the numbers you feed it — an unrealistic monthly_requests produces a confident, wrong forecast. Treat the usage file as a documented assumption, not a fact.

What it won’t catch

Set expectations so the team trusts the tool:

It estimates, it doesn’t bill. Reserved instances, savings plans, enterprise discounts, and spot pricing aren’t reflected in the list-price estimate. Your actual bill will usually be lower.
It prices what has a price. Resources without a public price (and anything in an unsupported provider) show as unknown, not free.
It can’t see usage you don’t declare. Out-of-the-blue data-transfer charges won’t appear unless you model them.

None of that undermines the core value: the direction and magnitude of a change’s cost, visible before merge.

Make it routine

The whole point is to make cost a normal part of review, not a quarterly fire drill. Put the diff in every infra PR, set a generous gate for the genuinely huge changes, and keep a usage file for the few resources where volume dominates. The expensive mistakes get caught at the one moment they’re free to fix — before anyone clicks merge.

Cost is one dimension of a change; correctness and security are others. We built our AI code review tooling to flag the risky parts of an infra diff alongside the pricey ones. For more on tightening your Terraform pipeline, see the full Terraform guides.

Cost figures are estimates based on list pricing. Always validate against your actual billing and discount agreements before making budget decisions.