FinOps for Azure Bicep: How to Catch Cost Before It Deploys

By ResourcePulse Team · · 5 min read

FinOps for Azure Bicep: How to Catch Cost Before It Deploys

FinOps practice is built around a simple idea: the people who build cloud infrastructure should see its cost consequences while they can still change them.

Most Azure teams get this backwards.

Cost review happens in a dashboard, after the infrastructure is running. The Bicep files are already merged. The resources are already deployed. The expensive SKU choice is already a line item in next month's invoice. The FinOps team flags it, engineering explains the context, and everyone agrees it was reasonable at the time.

This loop repeats every month.

Where cost decisions actually happen

Azure infrastructure cost is set at design time, not deployment time. The decision to use a P2v3 instead of a P1v3 App Service plan, or zone-redundant storage instead of locally-redundant storage, happens when someone writes or reviews a Bicep file.

That moment is the pull request.

If FinOps is going to reach engineers, it needs to reach them there. Not three weeks later in a cost anomaly report.

The gap in most Bicep workflows

Standard Bicep PR reviews answer three questions:

  1. Is the template valid?
  2. Does it follow team conventions?
  3. Will it deploy without errors?

None of these touch cost. A reviewer can approve a PR that adds €800/month in recurring spend without knowing it. The template is correct. Nothing flags it.

Azure Cost Management will catch it eventually. Eventually is not useful.

What shift-left FinOps actually looks like

When it works, the PR comment shows which resources changed and what the estimated monthly cost is. SKU changes become readable: Standard_LRS to Standard_GRS is a cost change, not just a string change. Region mismatches surface before they deploy. Governance checks run alongside, because the same PR that introduces an expensive service often also misses required tags.

No Azure subscription access needed. The estimate comes from the Bicep file itself.

What the comment actually says

Say a PR bumps a SQL database from General Purpose to Business Critical and adds a NAT Gateway for a new subnet. The diff is four lines. Nothing in it says "money." A cost-aware comment turns that into:

Estimated monthly change: +€1,040

  • SQL Database sql-reporting: General Purpose → Business Critical → +€830/mo
  • NAT Gateway nat-spoke-2: new resource → +€32/mo base, +usage
  • ⚠ Missing required tag environment on 2 resources

Coverage: 2 of 3 changed resources priced. Container App excluded (consumption-based — depends on traffic).

Now the reviewer has the one fact the diff hid: this "small" change adds about €1,000 a month, most of it from a tier flip nobody flagged. That is a different conversation, and it happens while the change is still cheap to undo.

Why the PR is the right place for this

FinOps teams often have the data but not the access. The engineers who make spending decisions are not in their workflow.

The PR is where those engineers are. A comment that says "this change adds €420/month, mostly from the SQL Business Critical tier" lands while the engineer still has context and can do something about it. A dashboard alert three weeks later does not.

How to set it up

Static analysis against the Bicep files. No deployment, no Azure credentials. The estimate is approximate but directionally correct, which is all you need at review time.

Filter for the PRs that actually move cost: SKU changes, new resources, quantity changes, region changes. Ignore the noise. A GitHub Actions comment that updates in place keeps the signal in the conversation, not in a separate tool. A Bicep PR review checklist covers what to look for on the human side.

What this is not

This does not replace Azure Cost Management or budget alerts. Those still matter.

It just means there's less for them to flag. If the expensive decision gets caught at PR time, the dashboard has a quieter week.

For more on where costs shift at PR time, see Shift-Left Cloud Costs: Catch Overruns Before They Deploy.

If you want this running on your own repository, ResourcePulse is the GitHub Action we build for exactly this: it posts the cost estimate and policy review as a PR comment, needs no Azure subscription access, and is free on one repo. Put it on a project and see the comment on your next Bicep PR.