Making Cost Visible at the Right Moment
The most powerful deployment of Infracost is not running it locally — it is integrating it into your CI/CD pipeline so that cost estimates appear automatically on every Pull Request that modifies infrastructure. This makes cost a standard part of code review, not an afterthought.
The workflow is:
- Developer opens a Pull Request modifying Terraform code.
- CI pipeline runs
terraform planand saves the plan as JSON. - Infracost analyzes the plan JSON and computes the cost diff — the difference between the current infrastructure cost and the proposed infrastructure cost.
- Infracost posts a formatted comment directly on the Pull Request.
- Reviewers see the cost impact alongside the code diff.
Setting Up GitHub Actions Integration
Wiring this up is a CI job scoped to pull requests that touch Terraform files, granted permission to post PR comments, that checks out the code, authenticates to Infracost, generates a breakdown, and posts (or updates) a comment with the result.
What the PR Comment Looks Like
When Infracost runs on a PR that upgrades an RDS instance and adds a NAT Gateway, the comment it posts looks like this:
💰 Infracost Estimate
This PR vs. Main Monthly cost $553.26 $133.26 Diff +$420.00 📈 Changed resources:
aws_db_instance.main+$400.00
Upgraded fromdb.t3.micro→db.m5.large
aws_nat_gateway.egress+$20.00
New resource: 730 hours + estimated 10GB data processed
The Behavioral Shift: Cost-Aware Engineering
This integration creates a concrete psychological shift. The developer sees the cost before they click "Merge." Two outcomes become possible:
Cost Avoidance: The developer realizes they accidentally used a production-grade instance size in a development environment config. They fix it before it ever runs. The cost was never incurred — it was avoided entirely.
Justified Spend: The developer sees the $400 increase and confirms: "Yes, we need the larger database for the new analytics feature. The product team approved this." The cost is now a conscious, documented decision visible in the PR history.
Both outcomes are wins. The first saves money. The second creates an audit trail that explains why the bill increased — invaluable when finance asks three months later.
Interviewers often ask: "How do you handle cloud cost governance at scale?" A weak answer focuses on tagging policies and monthly budget alerts. A strong answer describes a layered approach: (1) shift-left estimation via Infracost in PRs so costs are visible before deployment; (2) policy guardrails via OPA or Sentinel to block obviously expensive misconfigurations (e.g., no db.r5.24xlarge in non-production); and (3) continuous monitoring via AWS Cost Explorer or a FinOps platform to catch drift between estimates and actuals. This shows you understand prevention, guardrails, and detection as complementary layers.