Bicep vs Terraform on Azure: a practical take
Both deploy Azure resources. Both are good. Here's how I actually choose between them on real projects.
I get asked this constantly in cohorts: "Should we use Bicep or Terraform for our Azure infra?" My honest answer is, "it depends, but probably less than you think."
Here's how I decide on real projects.
What each one is good at
Bicep is best when:
- You're 100% on Azure and plan to stay there.
- You want zero state management — Bicep deployments are stateless from your side; Azure tracks the deployment object.
- You want first-day support for new Azure features. Microsoft ships Bicep coverage on the day a service GAs, often earlier.
- Your team is more comfortable with declarative DSLs than HCL.
- You're heavily using Azure-native tooling like deployment scripts, what-if, and Azure Policy.
Terraform is best when:
- You're multi-cloud, or you might be one day.
- You're deploying things outside Azure that integrate with it (GitHub repos, Datadog monitors, Cloudflare DNS, Azure DevOps projects, Microsoft Graph identities).
- Your organization already has Terraform expertise, modules, or governance tooling.
- You want a vibrant module ecosystem on the Terraform Registry.
- You like the explicit state file model and tools like
terraform planfor diffing.
What both are equally good at
Most things, honestly.
- Both produce idempotent deployments.
- Both have decent CI/CD integration.
- Both handle dependencies well.
- Both can be parameterized, modularized, and tested.
- Both have what-if/plan capability.
- Both can be governed with policies (Azure Policy for Bicep, OPA/Sentinel for Terraform).
If you're picking based on these axes, you're picking on a coin flip.
Where Bicep is genuinely better
State. You don't manage one. Azure's Resource Manager is the source of truth, and az deployment records each deployment as an object. No state file to lock, corrupt, or accidentally check in.
New Azure features. When Azure ships a new resource type, Bicep usually has support before Terraform's azurerm provider does. Sometimes by months.
Resource scoping. Deploying at management group, subscription, resource group, and tenant scope is built into Bicep. Terraform requires more provider configuration.
Where Terraform is genuinely better
Multi-cloud or multi-vendor. If you're deploying anything outside ARM-managed Azure resources — GitHub repos, Microsoft Graph apps, Cloudflare records, AWS S3 buckets — Terraform handles it natively. Bicep can't, and using Bicep + GitHub workflow steps + AWS CLI is messy.
Module ecosystem. The Terraform Registry has battle-tested community modules for almost everything. Bicep's public module registry is younger and thinner.
Refactoring tools. moved blocks, import blocks, and state mv give you a lot of control when you need to restructure existing infrastructure. Bicep's "deploy = whatever the file says" model is cleaner but less flexible when you've inherited a mess.
Cross-tool ecosystem. terraform-docs, tflint, terratest, and many more tools assume Terraform. The Bicep ecosystem is smaller.
My typical recommendation
| Situation | I pick |
|---|---|
| Greenfield Azure-only project, small to medium team | Bicep |
| Greenfield Azure-only, large team that loves IaC tooling | Terraform |
| Multi-cloud or "Azure + GitHub repos + Cloudflare DNS" | Terraform |
| Existing AzureRM Terraform — adding more stuff | Terraform |
| Existing ARM templates — modernizing | Bicep |
| Pure Microsoft 365 / Entra ID / Azure DevOps automation | Terraform |
The mistake I see most often is teams that switch from one to the other partway through, ending up with both. That's a worse problem than picking the "wrong" one.
What I do not pick on
Performance. Both are fast enough. If you have a 30-minute deployment, the bottleneck is Azure's API, not your tool.
Syntax pleasantness. Bicep is genuinely nicer to write than HCL. But you write IaC five percent of the time and read someone else's IaC ninety-five percent of the time. Pick the tool your team already knows.
Hype. Vendor blog posts come and go. Pick on what your team can support in two years.
The unsexy truth
The IaC choice matters less than the IaC discipline. A team that does Terraform with no review process, no CI validation, and a single shared workspace will have worse outcomes than a team doing Bicep with discipline. And vice versa.
If you're starting a new Azure project today, both are fine. Pick one, commit to it, write opinionated modules, gate it through CI, and stop debating.