The terraform vs cloudformation debate usually comes down to one question: are you all-in on AWS, or not? Both are infrastructure-as-code tools that let you define servers, networks, and databases in text files instead of clicking through a console. Terraform (from HashiCorp) works across dozens of clouds and services; CloudFormation is AWS-native and only touches AWS. That single difference drives most of the decision, but licensing, tooling, and how each handles state matter more in 2026 than they used to.
What changed in 2026
A few shifts reshaped this comparison since the early 2020s. Terraform switched from an open-source license to the Business Source License (BSL), which triggered the community fork OpenTofu — a drop-in, permissively licensed alternative that many teams now run instead of Terraform proper. HashiCorp is also under IBM's ownership now, which has some organizations quietly hedging their bets. On the AWS side, CloudFormation gained an IaC generator that can import existing resources into templates, and the AWS CDK (which compiles real code into CloudFormation under the hood) has become the way a lot of AWS-heavy teams write templates without hand-editing YAML.
So the practical field in 2026 is really Terraform-or-OpenTofu versus CloudFormation-or-CDK. The core tradeoff, though, is unchanged: breadth versus depth.
The core difference
Terraform speaks HCL (HashiCorp Configuration Language) and uses a provider model — plugins for AWS, Google Cloud, Azure, Cloudflare, Datadog, GitHub, and hundreds more. One tool and one language describe your whole stack, even across vendors. The catch is that Terraform tracks what it built in a state file that you have to store and protect somewhere (typically an S3 bucket or a managed backend), and a corrupted or lost state file is a genuinely bad day.
CloudFormation speaks YAML or JSON and only manages AWS. In exchange for that narrow scope, AWS manages the state for you inside the service, tracks drift, and rolls back a failed deployment automatically. There is no state file to babysit, and support for brand-new AWS features often lands in CloudFormation first.
Side-by-side comparison
| Factor |
Terraform / OpenTofu |
CloudFormation |
| Cloud coverage |
Multi-cloud, many providers |
AWS only |
| Language |
HCL |
YAML or JSON (or code via CDK) |
| State management |
You host and secure it |
Managed by AWS |
| Rollback on failure |
Manual or planned |
Automatic |
| New-service support |
Depends on provider updates |
Often first to get it |
| Cost of the tool |
Free (OSS/OpenTofu); paid Cloud tiers |
Free; pay only for resources |
| Ecosystem |
Large module registry |
Smaller, plus CDK constructs |
| Lock-in |
Portable across clouds |
Tied to AWS |
Keep the pricing directional and check current figures yourself: the tools themselves are largely free, but HashiCorp's managed Terraform Cloud/HCP tiers and AWS's higher-tier support plans do cost money.
Where each one wins
Reach for Terraform (or OpenTofu) when:
- You run more than one cloud, or mix cloud with SaaS services like Cloudflare and Datadog.
- You want one language and workflow across everything.
- You value a huge module registry and portability if you ever migrate.
Reach for CloudFormation (or CDK) when:
- You are firmly on AWS and expect to stay there.
- You want AWS to own state, drift detection, and automatic rollbacks.
- You need day-one support for the newest AWS services.
- Your org already leans on AWS-native tooling like Service Catalog or Control Tower.
A simple rule: single-cloud AWS shops usually get less friction from CloudFormation; anyone touching multiple clouds is almost always happier with Terraform.
What to watch out for
- State is the sharp edge in Terraform. Use remote state with locking from day one. Never let two people run applies against the same unlocked state.
- The BSL license is not the MIT license. For most users it changes nothing, but if a permissive open-source license is a hard requirement, evaluate OpenTofu instead.
- CloudFormation YAML gets verbose fast. If templates balloon, that is the signal to move to CDK and write in a real programming language.
- Do not chase "multi-cloud" you will never use. Portability has real value, but adopting Terraform's extra machinery to hedge a migration that never comes is a common, quiet tax.
FAQ
Is Terraform better than CloudFormation?
Neither is universally better. Terraform wins on breadth and portability; CloudFormation wins on AWS depth, managed state, and automatic rollbacks. The right pick depends on whether you are multi-cloud.
What is OpenTofu, and should I use it?
OpenTofu is a community fork of Terraform created after the license change, and it stays broadly compatible. Use it if you want a permissively licensed tool without leaving the Terraform ecosystem.
Can I use both together?
Yes, and some teams do — Terraform for cross-cloud pieces and CloudFormation or CDK for deep AWS-specific stacks. It adds coordination overhead, so only split when there is a clear reason.
Does CloudFormation cost extra?
The service itself is free; you pay only for the AWS resources it creates. Verify current pricing on higher support tiers before you budget.
Where to go next
Still deciding on a cloud first? Read AWS vs GCP in 2026. To understand how containers get deployed on top of this infrastructure, see Docker vs Kubernetes in 2026. And if you are shaping the front end of the same stack, React vs Vue in 2026 covers that tradeoff in the same honest way.