Choosing an infrastructure-as-code tool is a decision teams live with for years — state files, module libraries, and CI/CD pipelines all get built around it, and switching later is expensive. The landscape has also shifted meaningfully since most "Terraform vs. everything else" comparisons were written: HashiCorp changed Terraform's license in 2023, a community fork emerged and stabilized, and both AWS and Microsoft have matured their own first-party infrastructure-as-code tools. This article compares the five options an enterprise team is most likely to actually be choosing between today: Terraform, OpenTofu, Bicep, Pulumi, and AWS CDK.
Terraform and its open-source fork OpenTofu remain the default choice for multi-cloud environments because of their provider ecosystem. Bicep and AWS CDK are single-cloud tools — Bicep for Azure, CDK for AWS — that trade portability for tighter integration with their vendor's native deployment engine. Pulumi is the general-purpose-language option for teams that want real programming constructs (loops, functions, tests) instead of a declarative DSL. None of these are objectively "best" — the right choice depends on cloud scope, team language preference, and how much the license terms of each project matter to your organization.
Key Takeaways
- Terraform and OpenTofu use HashiCorp Configuration Language (HCL) and call the widest range of cloud and SaaS providers through a plugin model — the default choice for genuinely multi-cloud environments.
- OpenTofu exists because of a licensing decision, not a technical disagreement: HashiCorp moved Terraform from the open-source MPL 2.0 license to the more restrictive Business Source License (BSL) in August 2023, and OpenTofu forked the last MPL-licensed release under Linux Foundation governance.
- Bicep is Microsoft's Azure-only infrastructure-as-code language. It is not a general-purpose programming language by design — it compiles to the same Azure Resource Manager (ARM) JSON templates Azure has always used, so anything ARM supports, Bicep supports.
- AWS CDK lets teams write infrastructure in TypeScript, Python, Go, Java, C#, or .NET, then synthesizes that code into standard AWS CloudFormation templates for deployment — it is AWS-only by design.
- Pulumi is the general-purpose-language alternative to Terraform, supporting the same style of multi-cloud provider coverage but through real programming languages instead of a declarative DSL.
- The license terms of the tool you pick are now a real operational risk factor, not a footnote — evaluate them with the same rigor as technical fit.
What Each Tool Actually Is
Terraform
Terraform is HashiCorp's declarative infrastructure-as-code tool, written in HashiCorp Configuration Language (HCL). It works against a large ecosystem of providers — plugins that translate Terraform's resource model into API calls for a specific platform — which is why it became the default choice for teams managing infrastructure across more than one cloud, or across cloud plus SaaS platforms like GitHub, Datadog, or Cloudflare.
OpenTofu
OpenTofu is a fork of Terraform, created after HashiCorp announced on August 10, 2023 that it was moving all future Terraform releases from the Mozilla Public License 2.0 (MPL 2.0) to the Business Source License (BSL) v1.1. HashiCorp co-founder and then-CTO Armon Dadgar explained the change as a response to "other vendors who take advantage of pure OSS models... for their own commercial goals, without providing material contributions back," and framed it as necessary for "commercial open source models... to evolve for the ecosystem to continue providing open, freely available software." The BSL primarily restricts vendors from building competing commercial products directly on top of HashiCorp's code — HashiCorp stated ordinary users and enterprise customers would see minimal practical disruption.
OpenTofu forked the last MPL-licensed Terraform release, is governed under the Linux Foundation as a multi-vendor community project, and maintains HCL compatibility with Terraform. For teams whose primary concern is long-term license certainty rather than any specific missing feature, OpenTofu is a direct, drop-in-compatible alternative.
Bicep (Azure)
Bicep is Microsoft's declarative domain-specific language for deploying Azure resources. Per Microsoft's own documentation, Bicep "isn't intended as a general programming language" — it exists specifically to make Azure Resource Manager templates easier to author than raw ARM JSON. During deployment, the Bicep CLI transparently compiles a .bicep file into a standard ARM JSON template, so every resource type, API version, and property that ARM supports is available in Bicep, typically on the same day it ships for ARM. Bicep is open source and free, maintained by Microsoft with community contributions on GitHub, and is supported through standard Microsoft Support channels. It is Azure-only by design — there is no equivalent Bicep provider for AWS or GCP resources.
A minimal Bicep example, deploying a storage account:
param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
name: storageAccountName
location: location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: {
accessTier: 'Hot'
}
}
AWS CDK
The AWS Cloud Development Kit (CDK) lets teams define AWS infrastructure using general-purpose programming languages — TypeScript, JavaScript, Python, Java, C#/.NET, and Go are all supported. Rather than deploying directly, a CDK application "synthesizes" into a standard AWS CloudFormation template, which CloudFormation then deploys and manages exactly as it would a hand-written template. This gives teams access to real language features — loops, conditionals, functions, unit tests, and package management — while still deploying through AWS's native, AWS-only infrastructure engine.
Pulumi
Pulumi takes the same general-purpose-language approach as AWS CDK, but extends it across clouds rather than confining it to one vendor. Teams write infrastructure definitions in TypeScript, JavaScript, Python, Go, C#, .NET, Java, or YAML, and Pulumi's engine translates that into API calls against whichever cloud or SaaS provider the code targets — a similar scope of provider coverage to Terraform, but through real code instead of HCL. Pulumi's core engine and providers are open source; Pulumi Cloud, a hosted state and collaboration backend, is an optional commercial add-on rather than a requirement — teams can self-manage state instead.
Comparison at a Glance
| Tool | Language | Cloud scope | Deploys via | License |
|---|---|---|---|---|
| Terraform | HCL (declarative) | Multi-cloud | Provider plugins | Business Source License (BSL) v1.1 |
| OpenTofu | HCL (declarative) | Multi-cloud | Provider plugins | MPL 2.0 (open source) |
| Bicep | Bicep DSL (declarative) | Azure only | ARM JSON template | Open source, free |
| AWS CDK | TS, Python, Go, Java, C#/.NET | AWS only | CloudFormation template | Apache 2.0 (open source) |
| Pulumi | TS, Python, Go, C#, Java, YAML | Multi-cloud | Pulumi engine + providers | Apache 2.0 core (open source); Pulumi Cloud optional/commercial |
License terms summarized from each project's own documentation and license files; confirm current terms directly with each vendor before making a procurement decision, as license terms can change.
Trade-offs and Alternatives
A declarative DSL (HCL, Bicep) is easier to read at a glance, harder to accidentally write imperative bugs into, and has a smaller learning curve for teams new to infrastructure code. A general-purpose language (Pulumi, AWS CDK) gives you real loops, conditionals, unit tests, and your existing package ecosystem — genuinely useful for complex, highly parameterized infrastructure — at the cost of a steeper learning curve and more ways to write code that's hard to reason about.
Bicep and AWS CDK are deliberately single-cloud. In practice, that focus is often an advantage, not a limitation: because they map so directly onto their vendor's native template format, new Azure or AWS features tend to show up in Bicep and CDK close to their general-availability date. Terraform, OpenTofu, and Pulumi's provider model gives broader reach — one tool, one state approach across clouds — at the cost of occasionally lagging a specific vendor's newest feature until a provider update ships.
This is a newer consideration for infrastructure tooling but a real one. Terraform's BSL terms restrict competing commercial products, not ordinary internal use — but enterprise procurement and legal teams increasingly want that distinction verified for their own use case rather than assumed. OpenTofu's MPL 2.0 license and Linux Foundation governance remove that ambiguity entirely. Bicep, AWS CDK, and Pulumi's core are all under permissive open-source licenses (Bicep is open source and free; CDK and Pulumi's engine are Apache 2.0).
The single biggest predictor of a successful IaC rollout is usually whether the tool matches skills the team already has, not any feature comparison. A team of Python or TypeScript developers moving into infrastructure work will likely ship faster with Pulumi or CDK than with a new DSL; a platform team standardized on HCL across dozens of existing Terraform modules has a real cost to switching, license considerations aside.
Common Mistakes
If an organization is genuinely, durably single-cloud, Bicep or AWS CDK's tighter native integration is usually a better fit than a multi-cloud tool's broader-but-shallower coverage. Multi-cloud optionality that never gets used is a cost paid every day for a benefit that's never realized.
Assuming either "BSL means we can't use Terraform" or "BSL doesn't matter for us" without having legal or procurement actually read the current license terms against the organization's specific use case. This is a five-minute conversation that avoids a much larger one later.
Using Bicep for some Azure resources and Terraform for others in the same environment is workable, but only with an explicit, documented boundary for which tool owns which resources. Without that boundary, teams end up with drift, duplicate resource definitions, or state conflicts that are difficult to untangle.
Decision Guidance
How Halden Solutions Approaches This
From an engineering perspective, we treat the IaC tool as a decision that follows from cloud scope and team skills, not the other way around. For Azure-first environments — which, in line with our own architecture recommendations, is the default posture we start from — Bicep is frequently the right first choice: it stays current with Azure Resource Manager by design and removes an entire category of "does the provider support this yet" questions. In practice, for genuinely multi-cloud environments, or organizations bringing existing HCL module libraries, Terraform or OpenTofu remains a strong default, and we help teams evaluate the license implications of each concretely rather than by reputation. For enterprise environments where the team's engineering strength is already in a general-purpose language, Pulumi or AWS CDK (depending on cloud scope) can reduce the ramp-up time to productive infrastructure code considerably.
Frequently Asked Questions
OpenTofu forked from the last MPL-licensed Terraform release and maintains HCL compatibility, and most existing Terraform configurations and providers work with it. Teams should still test their specific module set and provider versions before switching, as the two projects have diverged incrementally since the fork.
Yes — per Microsoft's documentation, Bicep compiles directly to ARM JSON, so any resource type, API version, or property available in ARM is available in Bicep, generally from the same day it ships for ARM templates.
Technically yes, as long as they aren't asked to manage the same individual resources. This requires a clear, documented boundary for which tool owns which part of the account to avoid drift or conflicting changes.
According to HashiCorp's own announcement, the BSL is primarily intended to restrict third parties from building competing commercial products directly on top of Terraform's code, and the company stated that most end users, partners, and enterprise customers would see minimal disruption. Organizations with specific concerns — particularly those building tooling or services that resell or wrap Terraform — should have their legal team review the current license text directly.
No. Pulumi's core engine and providers are open source, and teams can self-manage state in their own backend instead of using the commercial Pulumi Cloud offering.
Conclusion
There is no single correct answer to "which infrastructure-as-code tool should we use" — the honest answer depends on how many clouds you actually run, what languages your team already knows well, and how much weight your organization puts on license terms and governance model. Terraform and OpenTofu remain the strongest default for genuinely multi-cloud estates; Bicep and AWS CDK earn their place through tighter native integration when an organization is committed to one cloud; and Pulumi fits teams that want the full expressiveness of a general-purpose language without giving up multi-cloud reach. The most expensive mistake is picking based on which tool is most talked about rather than which one matches the environment actually being built.
Halden Solutions helps enterprise teams evaluate infrastructure-as-code tooling against their actual cloud footprint, team skills, and governance requirements — explore our Cloud & Platform Engineering services or read more on operating a cloud platform well and our practical guide to cloud architecture.
Sources
- OpenTofu Manifesto and Project Overview — OpenTofu Foundation
- HashiCorp Adopts Business Source License — HashiCorp official blog, August 10, 2023
- Bicep Overview — Microsoft Learn
- AWS Cloud Development Kit (CDK) Developer Guide — AWS Documentation
- Pulumi Documentation: How Pulumi Works — Pulumi
- Terraform Documentation — HashiCorp Developer