Cost as a CI/CD Gate

Why this matters

Every module so far reacts to cost after it's incurred: Cost Analysis shows last month, budgets alert once spend crosses a line, showback reports what already happened. Even the fastest of these is a monthly or daily feedback loop — and by then the money is spent and the Terraform is already applied. This module closes the loop at the earliest possible point: the pull request. By estimating the cost of an infrastructure change from its Terraform plan and posting it as a PR comment — and enforcing hard cost guardrails as policy — you show engineers the price of a decision while they're still making it, exactly the "shift left" instinct behind tracks 10, 11, and 17. This is the culmination of module 00's culture shift: cost becomes a checked, visible property of every change, like tests and security scans already are.

Concepts

Shift cost left: from month-end to the pull request

The core idea is shifting cost feedback left — moving it from the end of the lifecycle (the bill) to the beginning (the code review), the same move you already made for tests (track 10), security scanning (track 11), and policy (track 17). A cost estimate at PR time is worth more than a perfect report at month-end for one reason: it reaches the engineer at the moment the decision is cheap to change. Adding node_count = 10 or bumping a disk to Premium in a Terraform PR is a one-line edit to reconsider before merge; the same change discovered on next month's bill is a deployed, running, argued-over cost. The whole Inform-phase premise (module 00 — "put the number where the decision is made") hits its sharpest point here: the PR diff is where infrastructure cost is born, so it's where the number belongs.

Infracost: cost from a Terraform plan

Infracost is the standard open-source tool for this. It reads a Terraform plan (the terraform plan output from track 09 — the same plan you learned to read the N to add from) and produces a cost estimate by pricing each resource the plan would create/modify against cloud pricing data. It works because a Terraform plan is a precise, declarative statement of exactly what will exist — SKUs, sizes, counts, regions — which is exactly what you need to price it. Infracost runs in two main modes: infracost breakdown (the full estimated monthly cost of a configuration) and infracost diff (the delta a change introduces — "this PR adds $340/month"), which is the one that belongs in a PR. Key honesty about what it can and can't do:

• It estimates usage-independent costs well (a VM's hourly rate, a disk's provisioned size, a fixed node count) — the things the plan pins down.
• It can't know usage-based costs (data egress, requests, storage consumed, function invocations) without a usage file you provide with assumptions — so its estimate is a projection under stated assumptions, not a guaranteed bill. This is the same caveat as module 01's forecasts, just at plan-time.

The value isn't a to-the-cent bill; it's a directionally-correct, per-PR delta that catches the accidental 10x before it merges.

Wiring it into CI (tracks 09/10)

The gate lives in the CI pipeline you built in track 10 (GitHub Actions / the CI system), operating on the Terraform from track 09. The pattern, on every PR that touches infrastructure:

1. terraform init and terraform plan -out=plan.tfplan, then terraform show -json plan.tfplan > plan.json — the machine-readable plan (track 09).
2. infracost breakdown --path plan.json on the PR branch and on the base branch — or infracost diff — to compute the cost delta.
3. Post the delta as a PR comment (Infracost's GitHub/GitLab integration, or a step that comments), so reviewers see "+$340/month" right next to the code diff.
4. Optionally fail the check if the delta exceeds a threshold (see guardrails).

This is deliberately the same shape as the test/scan/policy steps already in your pipeline (track 10) and the signing/SBOM gates (track 18) — cost is just another automated check on the change. Infracost needs an API key (free tier available) for pricing data, stored as a CI secret (track 10's secrets handling / track 16). Because it runs on a plan, it never touches real infrastructure — the estimate is free and safe.

Cost guardrails as policy (tracks 11/17)

A PR comment informs; a guardrail enforces. Two complementary layers, both reusing machinery you already have:

• Threshold gates in CI — fail the PR check if the cost diff exceeds a limit (e.g. ">$500/month increase requires approval"), using Infracost's policy support (it can evaluate policies written in OPA/Rego — the same policy-as-code engine you met for admission control in track 11 and could apply to infra). This makes an expensive change a blocking, override-with-approval event, not a silent merge.
• Preventive Azure Policy — deny the expensive thing at deploy time regardless of pipeline, using Azure Policy from track 17 (and track 11): deny VM SKUs above a size in dev, deny Premium disks in non-prod, restrict regions, require a lifecycle policy on storage (module 04). This is the defense-in-depth you already understand — the CI gate catches it in review, and Azure Policy catches it even if someone bypasses CI (a portal click, a rogue terraform apply). The CI gate is fast feedback; Azure Policy is the hard backstop.

The design principle is the track-11/17 one: guardrails, not gates that block everything — the goal is to make the expensive path require a conscious, approved decision, not to forbid spending. A gate that fails on every $5 increase gets disabled; a gate that flags a $2,000/month jump for a human to approve gets respected.

The estimate is directional — treat it as a signal, not a contract

The failure mode that discredits the whole practice is over-trusting the number. Infracost's estimate is a projection under assumptions — it prices what the plan declares, applies default or usage-file assumptions for consumption, and can't see runtime reality (autoscaling that never triggers, a spot discount from module 05, an existing reservation, real egress). So the estimate can be materially off on usage-heavy resources, and someone will eventually "catch it being wrong" and argue the gate is worthless. The correct framing (and the honest one): the gate's job is to catch the direction and the order of magnitude — the accidental count = 100, the Premium-disk-in-dev, the forgotten always-on cluster — before merge, and to make cost visible and discussed in review. It is a signal that prompts a conversation, not a contract that predicts the invoice. Tune the threshold so it fires on changes worth a human look, feed it a realistic usage file for your big consumption resources, and pair it with the actual post-deploy cost tracking (modules 01-02) that measures what really happened. Plan-time estimate + post-deploy measurement is the full loop; the estimate alone is only half.

Command reference

Infracost runs on a Terraform plan — it never touches real infrastructure, so these are free and safe. The Azure Policy commands reuse track 17.

Flag breakdown — the PR-time cost diff, the heart of the gate:

infracost diff \
  --path plan.json \
  --compare-to infracost-base.json \
  --format json \
  --out-file infracost.json

• --path plan.json — the PR branch's Terraform plan (JSON via terraform show -json, track 09) — what the change would create.
• --compare-to infracost-base.json — the base branch's prior Infracost breakdown; the diff between them is the delta this PR introduces ("+$340/mo").
• --format json --out-file infracost.json — machine-readable output the next step (infracost comment / a policy check) consumes to post the comment and/or enforce the threshold.

Flag breakdown — an Infracost policy that fails the check on a big increase (OPA/Rego, track 11 engine):

infracost breakdown --path plan.json --format json --out-file infracost.json
infracost comment github --path infracost.json --policy-path cost-policy.rego \
  --repo org/repo --pull-request 42 --github-token "$GITHUB_TOKEN"

• --policy-path cost-policy.rego — a Rego policy (the same policy-as-code language as track 11's admission control) evaluated against the estimate — e.g. "fail if diffTotalMonthlyCost > 500". This is what turns the comment into a blocking guardrail, overridable with an approval.
• --repo / --pull-request / --github-token — where to post and how to authenticate (a CI secret, track 10/16), so the result lands on the PR.

Hands-on exercises

Infracost runs on a plan, so everything here is free and touches no real infrastructure. Reuse a Terraform config from track 09 (or write a tiny one). You'll need a free Infracost API key.

1. Install and authenticate Infracost. Install the CLI (per its docs) and run infracost auth login for a free API key. Confirm with infracost --version. Note it needs only pricing data — no Azure credentials, because it prices a plan, not live resources.

2. Break down a real Terraform config. Point Infracost at a track-09 config:

   cd <your-track-09-terraform-dir>
   terraform init
   terraform plan -out=tf.plan
   terraform show -json tf.plan > plan.json
   infracost breakdown --path plan.json
   

   Read the per-resource monthly estimate. Note which resources it prices confidently (VMs, disks — usage-independent) and which show Monthly cost depends on usage (egress, requests). That split is the whole "directional, not exact" lesson made visible.

3. Compute a cost diff for a change. Edit the config to make something more expensive (bump a VM SKU, add count, switch a disk to Premium). Re-plan, then:

   infracost diff --path plan.json
   

   Read the "+$X/month" delta. This number — the delta a change introduces — is what belongs in a PR, far more actionable than an absolute total.

4. Provide a usage file for a consumption resource. For a resource whose cost depends on usage, create an infracost-usage.yml with an assumption (e.g. monthly egress GB, request count) and re-run infracost breakdown --path plan.json --usage-file infracost-usage.yml. Watch the previously-unknown cost become an estimate. Write down: this number is only as good as your assumption — a projection, not a promise (the module 01 forecast caveat, at plan time).

5. Catch an accidental 10x. Deliberately introduce the classic mistake — change a node/replica count from 2 to 20, or a size an order of magnitude too big. Run infracost diff and see the delta explode. This is exactly what the PR gate exists to surface before merge — the accidental blowout caught in review, not on the bill.

6. Wire it into CI (design or real, track 10). In a GitHub Actions workflow (or your track-10 CI), add a job on infrastructure PRs that runs terraform plan → terraform show -json → infracost diff → infracost comment github, storing the Infracost API key as a CI secret (track 10/16). If you have a repo handy, wire it for real and open a PR to see the comment; otherwise write the workflow YAML and explain each step's place in the pipeline (same shape as your test/scan steps).

7. Add a threshold guardrail as policy (track 11 engine). Write a small Rego policy that fails the check when the monthly diff exceeds a threshold (e.g. $200), and attach it via --policy-path. Test it against your exercise-5 blowout (fails) and a trivial change (passes). Note this is the same policy-as-code language you used for admission control in track 11 — now guarding cost instead of security.

8. Add the preventive Azure Policy backstop (track 17). Design (or assign) an Azure Policy that denies an expensive choice at deploy time — e.g. deny Premium disks or oversized VM SKUs in a dev-tagged scope (reusing the tag from track 17 module 06 and the Deny effect from track 11 module 05 / track 17 module 03). Write down why you want both this and the CI gate: the CI gate is fast feedback in review; Azure Policy is the hard backstop that catches a portal-click or a CI bypass.

9. Diagnose and fix: the cost gate everyone ignores (or games). The discredited-gate failure mode. Scenario: the team wired an Infracost gate that fails the build on any increase over $5/month. Within a week, engineers are routinely overriding it, or worse, someone "proved it wrong" (it estimated $400 for a resource whose real bill was $90 because autoscaling never triggered), and now nobody trusts it. Diagnose: two coupled problems — the threshold is too low (it fires on trivial changes, training people to override reflexively), and the estimate was over-trusted as exact on a usage-heavy resource where Infracost can't see runtime reality (autoscaling/spot/reservations). Fix: (a) raise the threshold to a level worth a human's attention (flag changes big enough to matter, e.g. >$200-500/mo, requiring approval — a guardrail, not a tollbooth — the track-11/17 principle); (b) reframe the number as a directional signal that prompts a conversation, not a contract; (c) feed a realistic usage file for the big consumption resources so estimates are less wrong; and (d) pair it with post-deploy actuals (modules 01-02) so real cost is measured, not just estimated. Lesson: a cost gate that blocks everything or claims to predict the invoice gets disabled; a guardrail that flags the changes worth discussing, framed as a signal and backed by real measurement, gets respected.

10. (No cleanup needed.) Infracost created no real resources. If you assigned a real Azure Policy in exercise 8, remove it (az policy assignment delete) unless you want to keep the guardrail.

Independent challenge

No commands given. Drawing on this module, the Terraform from track 09, the CI pipeline from track 10, the policy-as-code (OPA/Rego admission control) from track 11, the Azure Policy Deny and tagging from track 17 (modules 03/06), and the post-deploy cost tracking from modules 01-02, build a complete cost-gate for an infrastructure repo. It must: run Infracost on every infrastructure PR and post the monthly cost diff as a PR comment; enforce a threshold guardrail (a Rego policy that requires approval above a sensible limit — justify the number, not $5); include a preventive Azure Policy backstop that denies at least one expensive choice at deploy time (tied to the Environment tag); provide a usage file so at least one consumption-based resource is estimated rather than "depends on usage"; and be defended in writing as defense-in-depth — what the CI gate catches, what Azure Policy catches, and why you need both. Finish with two or three sentences on how you'd close the loop by comparing the plan-time estimate to the actual post-deploy cost (modules 01-02), and why the estimate alone is only half the practice. The deliverable is the pipeline config, the policies, and the written defense.

Common mistakes & troubleshooting

• Setting the threshold too low. A gate that fails on every trivial increase trains engineers to override reflexively and then it's decoration. Flag changes worth a human's attention (hundreds/month, requiring approval) — a guardrail, not a tollbooth (tracks 11/17).
• Treating the estimate as an exact bill. Infracost prices what the plan declares under stated assumptions; it can't see autoscaling, spot (module 05), reservations, or real egress. Frame it as a directional signal, and it stays credible.
• Not providing a usage file. Usage-based resources show "depends on usage" and get ignored, or default assumptions mislead. Supply realistic usage for your big consumption resources so their estimates mean something.
• CI gate or Azure Policy, not both. The CI comment is fast feedback but bypassable; Azure Policy is the deploy-time backstop but has no PR context. You need both — defense-in-depth (tracks 11/17).
• Running Infracost against live infra instead of a plan. It works off the Terraform plan JSON (track 09). Feed it terraform show -json, not live resources — that's why it needs no Azure credentials and touches nothing.
• Estimate without post-deploy measurement. A plan-time estimate is half the loop; without comparing to actual cost (modules 01-02) you never learn how wrong it was, and the gate can't be tuned. Close the loop.
• Leaking the Infracost API key. It's a CI secret (track 10/16) — never commit it. It's only pricing-data auth, but still handle it like any secret.

Checkpoint quiz

Write down your answer to each question before expanding it — checking without attempting first is the single easiest way to fool yourself into thinking you've learned this.

Next

Continue to 08-capstone-project — you've now built the full FinOps practice: the framework (module 00), visibility and allocation (01), budgets (02), the Optimize levers (03-05), showback (06), and the shift-left cost gate (this module). The capstone asks you to run all of it, for real, against your own subscription — one cost analysis, one firing budget, one measured rightsizing, one orphaned-resource sweep, and one cost gate in a PR — and prove each with evidence.