Does Infracost Support Bicep or ARM Templates?

By ResourcePulse Team · May 25, 2026 · 4 min read

Short answer: no. Infracost reads Terraform, not Bicep or ARM. If your Azure infrastructure is written in Bicep or ARM JSON, Infracost cannot estimate its cost, and there is no plugin or flag that changes that today.

If you came here hoping for a yes, I get it. Infracost is the tool everyone points to for cost estimates in pull requests, so it is the first thing you try. Then you read the docs, see "Terraform" everywhere, and start wondering whether you missed something. You did not. This post explains what Infracost actually covers, why Bicep is not on the list, and what you can use instead.

One thing up front: I work on ResourcePulse, one of the alternatives I mention near the end. I will be straight about where it fits and where it does not, and about the other options too.

What Infracost actually supports

Infracost was built around Terraform. It parses your Terraform HCL or a Terraform plan JSON, figures out which resources you are creating, and prices them. It also handles Terragrunt, since that sits on top of Terraform.

That is the whole input surface. Bicep, ARM templates, Pulumi, CloudFormation, raw CLI scripts: none of those are Terraform, so none of them are read.

"But the docs mention Azure"

This is where people get tripped up. Infracost does support Azure, and the docs say so. The catch is what "Azure support" means: it prices Azure resources that you defined in Terraform. So azurerm_linux_virtual_machine in an HCL file works fine. The same VM written as Microsoft.Compute/virtualMachines in a Bicep file does not, because the file never gets parsed in the first place.

Azure support and Bicep support are two different things. Infracost has the first one and not the second.

Why Bicep and ARM are not just a quick add

Bicep and ARM are a different shape of problem than Terraform, which is part of why this gap has stayed open for years (there is a long-standing request on the Infracost repo asking for exactly this).

Terraform has a plan step that produces a clean, structured list of every resource and its final settings. Infracost leans on that. Bicep does not work the same way. You compile Bicep to ARM JSON, and to see the real resource list with everything resolved you run an Azure what-if deployment, which talks to Azure and needs credentials. It is a more involved pipeline, and it is Azure-specific, so it never fit neatly into a Terraform-first tool.

Options for estimating Bicep and ARM costs

You have three realistic paths. I will be straight about the trade-offs, including for our own tool.

1. Roll your own with what-if plus the Retail Prices API

Azure gives you the raw materials for free. The az deployment group what-if command tells you what a Bicep deployment will create or change. The Azure Retail Prices API is a public, no-auth endpoint that returns pay-as-you-go prices for any service. Wire those two together in a script and you can post a cost number on a pull request.

Good if you want full control and have time to maintain it. Less good when you hit the parts nobody warns you about: matching what-if output to the right meter, handling SKUs whose names differ between Bicep and the pricing API, regions, reservations, and consumption-based services that have no fixed monthly price. It works, but it becomes a small internal product you now own.

2. Azure Cost Estimator (ACE)

ACE, also known as arm-estimator, is an open-source CLI that estimates costs for ARM, Bicep, and Terraform. It calls the Retail Prices API directly, so the data stays current, and it can fail a pipeline when an estimate goes over a limit you set. It has a GitHub Action too.

If you want a command-line tool you run yourself and wire into your own pipeline output, ACE is solid and worth a look.

3. ResourcePulse

This is the one we build, so weigh it accordingly. ResourcePulse is a GitHub Action that reads the Bicep or ARM in a pull request and posts a comment with the estimated monthly cost of what changed, plus policy checks (things like "this storage account is not using the SKU we standardised on"). The aim is that the cost shows up in the review where the team already is, instead of in a separate report someone has to go open.

It is free for one repository, so you can put it on a real project and see the comment on your next PR without talking to anyone. If your costs are mostly fixed infrastructure (VMs, App Service, databases, storage), it will give you a useful number. Consumption-based resources are harder to predict without knowing usage, and we say so in the comment rather than inventing a figure.

So which one

If you are on Bicep or ARM and you want cost visibility inside pull requests, your choices are a DIY script, ACE, or ResourcePulse. Try the free tier on one repo and see whether the PR comment changes how your team talks about cost. That is the whole pitch, and you can find out in one merge.