Title banner for 'Choosing an IaC Tool in 2026.' On the left, generalized multi-cloud tools (Terraform / OpenTofu / Pulumi / Crossplane); on the right, cloud-native tools (CloudFormation, CDK / Bicep / Config Connector); in the center, a 'specialized ⇄ generalized' axis with six use-case branches.

Key Points

  1. There are a dozen-plus IaC tools, but the first decision is a single axis: specialized (each cloud's native tooling) vs. generalized (multi-cloud). Decide that, then map your use case.
  2. Who this is for: individual developers and small teams deciding which tool to start writing with today, and practitioners weighing org-wide standardization. No prior knowledge assumed.
  3. What you get: a candidate map, an explicit list of tools to avoid adopting in 2026 (end-of-support), a practical Terraform-vs-OpenTofu decision, a six-use-case guide, and — the part this English edition centers — why tool choice is increasingly a governance and sovereignty decision, not only a technical one.
  4. This is a companion to the Japanese edition, not a translation. The technical core is shared; the international forces (OSS license/governance, EU digital sovereignty, compliance-driven auditability) are centered here.

Written: 2026-06 / Scope: individual developers, small teams, and standardization owners / last_updated: 2026-06-12 Changelog: 2026-06-12 initial version

This is an educational overview, not licensing or compliance advice

IaC tools change fast — licenses, versions, and end-of-support (EoS) dates shift frequently. Every date, version, and license label here reflects the state as of 2026-06 and is provided without warranty of accuracy, completeness, or currency. In particular, whether a given license fits your specific usage (commercial use, the definition of a "competitive offering") must be checked against each tool's full license text and official announcements, with legal counsel where appropriate. Always confirm the latest state in each project's official Releases / Docs before adopting. This content is provided "AS IS"; the author and YATA-NODE assume no liability for any damages arising from its use.

Where this fits: this article is about which tool to encode your infrastructure with. Read it alongside Virtualization & Sandboxes (what you deploy onto) and the dependency-hygiene pair, Choosing an SBOM Tool and Making Sense of OSS Licenses. Each reads independently.

Quick terms: IaC (Infrastructure as Code) — declaring infrastructure (servers, networks, databases) as code so the same environment is reproducible and reviewable. Declarative — you describe the desired end state and the tool reconciles the diff. State — a record of what the tool currently manages (self-managed in Terraform-family tools; usually held by the cloud in native ones). Provider/plugin — the extension that lets a generalized tool drive a given cloud. BSL (Business Source License) — a source-available, OSI-non-approved license; Terraform adopting it in 2023 triggered the OpenTofu fork. DSL (Domain-Specific Language) — a language designed for a specific purpose (here, for describing infrastructure config). CDK (Cloud Development Kit) — define infrastructure in a general-purpose programming language that synthesizes into templates (e.g., AWS CDK).

The tools are many; the deciding axis is just "specialized vs. generalized"

Here's the conclusion first. There are over a dozen IaC tools, but the first thing to decide is a single axis: specialized (each cloud's native tooling) or generalized (multi-cloud). Settle that, and the rest is mapping your use case.

The reason to use IaC at all — declaring config as code so you get reproducible environments, review, and diffs — is common to every tool. The difference appears at one point only: do you commit deeply to one cloud, or span several clouds in one language? That is the specialized/generalized split.

A specialized (cloud-native) to generalized (multi-cloud) spectrum. CloudFormation, ARM, and SAM at the left; CDK, Bicep, and Config Connector in the middle; Terraform, OpenTofu, Pulumi, and Crossplane at the right, with pros and cons of each side compared below.
  • Specialized (native) strengths: the vendor's fastest support for new services (native tooling tends to land first), full access to native features, state managed by the cloud, and a free tool itself. The weakness is being locked to one cloud.
  • Generalized strengths: spanning AWS / Azure / GCP and beyond in one language, a huge ecosystem, and transferable skills (HCL, TypeScript, etc.). The weaknesses are that new-service support lags (providers are built after the fact) and that you run state yourself.

The core judgment is simple. If you finish inside one cloud and want its full power, go specialized. If you use multiple clouds, want migration headroom, or a wider talent pool, go generalized. In practice, the most common answer is a layer-by-layer hybrid — covered in the use-case guide at the end.

The candidate map, and "tools to avoid adopting in 2026"

Sorting the main candidates into specialized / generalized looks like this (licenses as of 2026-06):

  • Generalized / multi-cloud tools: Terraform (HCL / 1.1), OpenTofu (HCL / 2.0, a Terraform fork), Pulumi (TS, Python, Go, etc. / Apache 2.0), Crossplane (Kubernetes-native / Apache 2.0).
  • AWS-native: CloudFormation (the classic), CDK (write in a programming language; compiles to CloudFormation), SAM (serverless-focused).
  • Azure-native: ARM Template (JSON; still works but migration is encouraged), Bicep (the modern standard DSL), AVM (Azure's official reusable module set).
  • GCP-native: Config Connector (via Kubernetes), Infrastructure Manager (Terraform managed by Google). GCP's native story is thin, and notably Google itself recommends Terraform for IaC.

Each card groups tools by where they come from (general-purpose, multi-cloud vs. each cloud's first-party). Multiple tools sit in one card because they differ in abstraction (a high-level language vs. a low-level template) or in standing (current vs. migrate-away). For example, Azure's first-party set holds both the low-level, somewhat verbose ARM Template and the high-level Bicep that writes the same thing concisely. The use-case guide later narrows down which to pick.

A category map of IaC candidates in four zones (generalized / AWS-native / Azure-native / GCP-native), each tool shown as a card with its license and release year, and tools reaching end-of-support drawn with strikethrough.

Now the most practically important fact that older comparison posts miss: the tools to avoid adopting in 2026 because they are reaching, or have reached, end-of-support. Pick one of these off a stale article and you start with debt.

  • AWS Copilot CLI — end-of-support on 2026-06-12. After this date it receives no updates, security patches, or technical support. New adoption is discouraged; container-app builders are pointed to other approaches (check the official announcement for the recommended successor).
  • GCP Cloud Deployment Manager — support ended 2026-03-31. Google officially recommends migrating to Infrastructure Manager (Terraform-based).
  • cdktf (CDK for Terraform) — officially deprecated by HashiCorp as of 2025-12-10. If you want to write IaC in a programming language, consider Pulumi (below).

Dates and versions go stale fast

All of the above reflect the state as of 2026-06. IaC releases and announcements move quickly, so always confirm the official announcement / Releases before adopting. This article is written from "what was officially announced," and the authoritative status is whatever the primary source says now.

Terraform or OpenTofu — and why it's a governance choice

The first fork in the generalized road is Terraform vs. OpenTofu. Keep the history short and tie it straight to the decision.

On 2023-08-10, HashiCorp changed Terraform from MPL 2.0 (OSS) to BSL 1.1 — source-available rather than open source. The community forked OpenTofu, now a Linux Foundation project, GA in early 2024 with HCL compatibility. IBM completed its acquisition of HashiCorp on 2025-02-27, but Terraform's BSL remains in place as of 2026-06, with no official relaxation announced.

Practically, the decision comes down to two points:

  • Maximize OSS purity / avoid Terraform's BSL → OpenTofu. Foundation stewardship — where it's much harder for a single company to unilaterally change the license — is the reassurance. (The engine is MPL 2.0, but the providers and modules you use carry their own licenses; confirm those separately.)
  • You already have a HashiCorp contract / want Terraform Cloud (HCP) / want the deepest ecosystem → Terraform. Note that the BSL restricts providing a competitive offering — per HashiCorp's licensing FAQ, ordinary non-production and production use, including commercial use, is allowed; only paid products that significantly overlap a HashiCorp commercial product are excluded.

Zoom out and this is part of a broader 2020s pattern: vendor-held OSS licenses can move for commercial reasons, and the community sometimes pushes them back.

  • Elastic relicensed Elasticsearch/Kibana to + in 2021 (triggering the OpenSearch fork), then added as a third option in 2024 ("Elasticsearch Is Open Source. Again!").
  • Redis moved to an SSPL-based model in 2024 (triggering the Valkey fork), then re-added AGPLv3 in Redis 8 (2025).
  • Terraform → OpenTofu sits squarely in this series — except there has been no return.

The contrast is foundation-governed neutrality: OpenTofu sits under the Linux Foundation, and Crossplane reached CNCF Graduated status (announced 2025-11-06) — a tier requiring vendor-neutral governance and a third-party security audit, which makes a unilateral license change structurally harder (though not legally impossible). So tool choice now carries a real axis: vendor-held (BSL risk, acquisition uncertainty) vs. foundation-held (much harder for a single company to flip the license unilaterally).

A five-axis overview sharpens the trade-offs (◎ = strongest / ○ = good / △ = mixed / ✕ = limited, as of 2026-06):

ToolLicenseMulti-cloudNew-service supportLearning cost
Terraform / OpenTofuBSL 1.1 / MPL 2.0◎△ (providers lag)Medium (HCL)
PulumiApache 2.0◎△Low (TS/Py/Go)
CrossplaneApache 2.0◎△Medium (K8s-first)
CloudFormationAWS✕ (AWS only)◎ (fastest tier)Medium–high (verbose)
CDKApache 2.0✕ (AWS only)○Low (language-based)
BicepMIT✕ (Azure only)◎Low (rich IntelliSense)

Six use cases — what to start writing with today

Map the axes above to your case, ordered from most to least common.

A six-use-case mapping of recommended IaC tools: multi-cloud → OpenTofu; single AWS, serverless → SAM + CDK; single Azure → Bicep + AVM; single GCP → Terraform; want to write in a language → Pulumi; Kubernetes-centric → Crossplane. A branching diagram with a note that hybrids are the realistic default.
  1. Multiple clouds (two or more) → OpenTofu (or Terraform). Choose OpenTofu to avoid the BSL, Terraform for the contract/ecosystem. Standardize the whole estate in one language.
  2. AWS only, serverless-centric → SAM + CDK. SAM for Lambda / API Gateway, CDK for the surrounding VPC / IAM. More productive than hand-writing CloudFormation.
  3. Azure only → Bicep + AVM. Bicep is effectively the successor to ARM Templates; AVM (verified modules) gives you a solid base. Migrate existing ARM incrementally.
  4. GCP only → Terraform / OpenTofu + the Google provider. GCP's native story is thin and Google recommends Terraform; for Kubernetes-centric ops, Config Connector is also an option.
  5. You want to write in a programming language (TS / Python / Go) → Pulumi (or CDK, AWS-only). Reuse existing skills, with easier testing and abstraction.
  6. Kubernetes-centric, integrated with GitOps → Crossplane. A mature CNCF project that pairs well with ArgoCD / Flux and treats each cloud's resources the Kubernetes way.

In practice, hybrids win

Unifying on one tool is ideal, but real estates are right-tool-per-layer. For example: "Azure in Bicep, the Cloudflare bits in Terraform," "AWS serverless in SAM, everything else in CDK," or "standardize on OpenTofu to sidestep the BSL." Don't chase perfect unification from day one — anchor on the best tool for your primary cloud and patch the overflow with a generalized tool.

Sovereignty and compliance are now choice-drivers too

Beyond features and licenses, two regulatory currents are nudging tool choice — not by mandating any specific tool, but by shifting the value of portability and auditability. (Both are jurisdiction-flavored, which is why this English edition centers them; the regulations themselves live in the communication-security and enterprise-app-dev editions.)

  • EU digital sovereignty. As sovereign-cloud offerings mature across the EU, the underlying motive — "don't get locked to one vendor" — raises the value of generalized tools that keep a migration path open, while native IaC still gives reproducibility inside a sovereign boundary. The pragmatic read is two-layered: native for in-boundary reproducibility, generalized for portability.
  • Compliance-driven auditability. Regulators and procurement increasingly want reproducibility and auditability of configuration. Neither the EU CRA (which obliges product manufacturers on documentation and risk assessment) nor NIS2 (which obliges operators on risk-management measures) mandates IaC or policy-as-code as such — but IaC plus policy-as-code is a leading way to produce the reproducibility and audit evidence both regimes value, which quietly promotes IaC from a "deployment convenience" to a "source of compliance evidence." In the US, FedRAMP's 20x direction emphasizes automated, continuous validation over point-in-time, narrative review, pushing the same way.

The throughline: external policy and market forces raise the value of generalized portability and neutrality, while still leaving room for native reproducibility inside sovereign boundaries — exactly the specialized-vs-generalized trade-off from the top of this article, now with governance weight on the scale.

Summary — three steps

Choosing an IaC tool compresses to three steps:

  1. Narrow to one axis: decide specialized (cloud-native) or generalized (multi-cloud). Single cloud → specialized; multiple clouds / migration headroom → generalized.
  2. Drop the end-of-support tools: as of 2026-06, don't newly adopt AWS Copilot CLI (EoS 2026-06-12) / GCP Cloud Deployment Manager (ended 2026-03-31) / cdktf (deprecated 2025-12-10). Don't let stale articles steer you.
  3. Map your use case: pick your branch from the six above and start with one. A layer-by-layer hybrid beats forced unification.

The question isn't "which is strongest" but "which fits your cloud and the way you work" — and, increasingly, which governance posture you want. If in doubt: OpenTofu for multi-cloud, CDK for AWS, Bicep for Azure are safe starting points. Pair this with Virtualization & Sandboxes, Choosing an SBOM Tool, and Making Sense of OSS Licenses.

References (primary sources, as of 2026-06)