Infrastructure cost in code review: making dollars a review dimension
Code review already checks correctness, security, and style, but cost is usually invisible in the diff. Here is how to make infrastructure cost a normal dimension of review, so reviewers weigh dollars alongside code.
Quick answer
Code review reliably checks correctness, security, and style, but cost is invisible in a Terraform diff: a one-line instance-type change can multiply the bill without looking any different. You make cost a review dimension by surfacing the priced cost delta in the pull request automatically, so reviewers see the dollar impact beside the code and can question it like any other concern. Over time this trains authors to check their own cost before pushing. The principle is put the cost delta in front of the reviewer so cost gets the same scrutiny as correctness.
A diff shows what changed in the code, but not what it costs. Changing an instance type from a small to a large is one character in the diff and a doubling of the bill. Reviewers cannot weigh cost they cannot see, so cost gets skipped in review not from neglect but from invisibility. Making cost a review dimension means putting the dollar impact where the reviewer already looks.
Why cost is invisible in review
| Review dimension | Visible in diff? |
|---|---|
| Correctness | Yes, in the logic |
| Security | Often, in the config |
| Cost | No, hidden in resource sizing |
Correctness and security leave traces in the diff a trained reviewer can spot. Cost does not: the sizing, count, and type fields that drive cost look like ordinary configuration, and their dollar consequence is nowhere in the text. So even a diligent reviewer misses cost, because there is nothing to see. The fix is to add the missing signal.
Surfacing the cost delta
The signal is the priced cost delta, posted automatically on the pull request. When a reviewer opens a PR and sees this change adds 300 dollars a month, cost becomes as visible as a failing test. They can then apply judgment, is that expected, is it justified, the same judgment they apply to logic and security. c3x posts this delta as a PR comment, so the dollar figure sits in the review thread with no extra tool to open.
Reviewing cost like any concern
Once the delta is visible, reviewers treat it as a normal review item: an unexplained jump gets a question, a large addition gets a justification, a surprising number gets investigated. This is not about blocking every costly change, since some are necessary, but about ensuring cost is considered rather than shipped blind. A reviewer asking why does this add 300 a month often uncovers an accidental oversizing the author did not intend.
The author-side effect
Knowing that the cost delta will appear in review changes author behavior before the review even happens. Authors start checking their own cost impact before pushing, right-sizing preemptively because they do not want to explain a surprise in review. This self-correction is the biggest long-term benefit, the same cultural shift that cost awareness aims for, achieved through routine visibility rather than mandates.
Making it routine
Add cost commenting to every infrastructure repository so the delta is always present, and set a team norm that unexplained cost jumps get questioned in review, just like unexplained logic changes. When cost is a standing part of every review, it stops being an afterthought and becomes a habit. Price your changes against the resource catalog so the delta reviewers weigh is grounded in real rates and worth taking seriously.
FAQ
Why is cost invisible in code review?
Because cost is hidden in resource sizing, count, and type fields that look like ordinary configuration in a diff, with no dollar consequence visible in the text. Correctness and security leave traces a reviewer can spot, but a one-line instance-type change that doubles the bill looks unremarkable, so even a diligent reviewer misses cost from invisibility, not neglect.
How do I make cost a code review dimension?
Surface the priced cost delta in the pull request automatically, so a reviewer opening a PR sees that a change adds a given amount per month as clearly as a failing test. That gives them the missing signal to apply judgment about whether the cost is expected and justified, the same scrutiny they apply to logic and security.
How should reviewers handle cost in review?
Treat the cost delta as a normal review item: an unexplained jump gets a question, a large addition gets a justification, a surprising number gets investigated. It is not about blocking every costly change, since some are necessary, but ensuring cost is considered rather than shipped blind. A reviewer asking why a change adds cost often uncovers accidental oversizing.
Does cost-aware review change author behavior?
Yes, and this is the biggest long-term benefit. Knowing the cost delta will appear in review, authors start checking their own cost impact before pushing and right-size preemptively to avoid explaining a surprise. That self-correction, driven by routine visibility rather than mandates, is the cultural shift toward engineering cost awareness that cost-aware review aims for.
How does C3X make cost a review dimension?
C3X prices the Terraform plan statically against a live catalog with no cloud credentials and posts the cost delta as a comment on the pull request, so the dollar impact sits in the review thread beside the code with no extra tool to open. That gives reviewers the missing signal to weigh cost alongside correctness, and trains authors to check cost before pushing.
What to do next
Give cost the scrutiny correctness gets. C3X posts the cost delta in every infrastructure PR for reviewers. Start with the quickstart.
Related posts
- Terraform module cost estimation: pricing reusable infrastructure
Reusable Terraform modules hide their cost behind clean interfaces, so a single module call can provision an expensive stack. Here is how to estimate module cost and expose it so callers know what they are deploying.
- Terraform PR cost comment workflow: putting dollars in the review
A cost comment on the pull request is where infrastructure cost becomes visible to reviewers. Here is how to build the workflow that generates a plan, prices it, and posts the cost to GitHub or GitLab automatically.
- Terragrunt module cost inheritance: pricing DRY infrastructure
Terragrunt keeps infrastructure DRY by layering shared inputs across environments, which spreads a resource's cost across inherited configuration. Here is how to trace and estimate cost through a Terragrunt hierarchy.
- Build vs buy for infrastructure: the cost model that includes the parts people forget
Self-hosting looks cheaper until you price the engineers who run it. Managed looks expensive until you price the outage you avoided. Here is a build-versus-buy model with the operational and risk costs made explicit.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.