Our team has historically been AWS-only and manages infrastructure with Terraform. We recently delivered a small Azure project and briefly tried Bicep before switching back to Terraform. Now we have a larger, more complex Azure project coming up, so I'm reconsidering Bicep.
The main arguments for Bicep are its first-party Azure support and the possibility that new Azure features will appear there before they reach the Terraform provider. On the other hand, the team already knows Terraform, understands its state management, and could reuse our existing tooling, workflows, and conventions—even though our AWS modules themselves would need to be rewritten for Azure. GitLab's infrastructure security scanner also doesn't currently support Bicep, which is another concern. I've additionally heard that Bicep does not handle resource deletion and lifecycle management like Terraform does, although deployment stacks may help with that.
For a larger Azure deployment, would you recommend staying with Terraform or moving to Bicep?
4 Answers
Terraform also lets one deployment coordinate multiple providers. For example, an Azure resource could provide an output used to configure another service, identity system, DNS provider, or source-control organization. Bicep is primarily focused on Azure’s ARM-managed resources, so you may end up needing separate tools and automation around it.
Bicep is essentially a nicer syntax for ARM templates and is stateless. It can be a good choice when you only need to describe Azure resources, but Terraform gives you a stateful plan/apply workflow, drift tracking, and broader provider coverage. Bicep also doesn’t automatically remove resources just because they disappeared from a template in the same way Terraform does. Azure deployment stacks can help with resource lifecycle and cleanup, but they aren’t identical to Terraform state.
The specific provider gaps are worth investigating before changing tools. Many Azure issues are simply features that were added to the platform recently and haven’t reached the provider yet. Filing an issue or using an API-based Terraform provider can sometimes solve the problem without abandoning the existing workflow. It would help to know which Azure resources or features caused trouble previously.
I’d stay with Terraform. The biggest benefit isn’t reusing AWS modules; it’s keeping the same language, state management, CI workflows, review process, and operational habits across clouds. Azure Verified Modules can reduce the amount of module code you need to write, and the Azure API provider can cover some features that the main provider hasn’t exposed yet.
Agreed. There’s not much reason to add another tool and another mental model when the team already operates Terraform successfully. Even if someone is new to infrastructure as code, a cloud-agnostic tool is a useful skill to learn.
That lifecycle difference would make me cautious for a large environment. If state and drift management matter, I’d default to Terraform and accept the occasional delay while the Azure provider catches up.