Infrastructure as Code

Terraform vs CloudFormation: Which IaC Tool to Choose

Hire DevOps Expert Team
10 min read
Updated August 2026
Share:

The short version

Use Terraform if you are multi-cloud or touch any non-AWS service; it manages AWS, Azure, GCP, and hundreds of other providers from one workflow using HCL. Use CloudFormation if you are all-in on AWS and want an AWS-native tool with zero state management, automatic rollback, and day-one support for new AWS services. If a truly open-source license matters to you, look at OpenTofu, the community fork of Terraform.

01The short answer: the decision in one rule

Here is the rule that resolves most of these debates. If your infrastructure lives entirely inside AWS and you expect it to stay that way, CloudFormation is a reasonable default, it is AWS-native, free, and there is no state file to manage. If anything in your stack touches a non-AWS service, or you expect to go multi-cloud, Terraform gives you a single tool and workflow to manage all of it.

In practice, the second case is common. The moment you add Cloudflare for DNS, Datadog for monitoring, or manage a SaaS provider alongside your cloud, CloudFormation can no longer be your one tool, and Terraform can. That is why teams tend to land on Terraform as they grow. Everything below is detail on top of this one rule.

02What Terraform is

Terraform is an infrastructure-as-code tool created by HashiCorp in 2014. You describe your infrastructure in a language called HCL (HashiCorp Configuration Language), and Terraform provisions and manages it. Its defining feature is breadth: through its provider ecosystem, Terraform manages resources across AWS, Azure, GCP, and a very large number of other providers and SaaS platforms, all from the same workflow.

Two things define the Terraform experience. First, HCL is concise and purpose-built for infrastructure, with features like for_each, count, conditionals, and reusable modules, and most engineers pick it up quickly. Second, Terraform keeps a state file that tracks every resource it manages. You choose where that state lives, typically a remote backend such as Amazon S3 or a managed service, and you control access to it. That state model gives you flexibility and transparency, at the cost of having to manage the state yourself. Terraform's docs at developer.hashicorp.com are the primary reference.

03What CloudFormation is

AWS CloudFormation is Amazon's native infrastructure-as-code service, and it has been around since 2011. You define your resources in JSON or YAML templates, and CloudFormation provisions them as a stack. It is deeply integrated with AWS: new AWS services tend to get CloudFormation support early, and features like StackSets let you deploy across many accounts and regions.

The big practical differences from Terraform are that CloudFormation is AWS-only, and it manages state for you. There is no state file to store or secure; AWS tracks it behind the scenes. CloudFormation also rolls back automatically: if a deployment fails partway, it returns the stack to its last healthy state without you intervening. The tool itself is free; you pay only for the AWS resources it creates. AWS documents it at docs.aws.amazon.com.

04Terraform vs CloudFormation, side by side

Here is the direct comparison across the dimensions that usually decide it.

DimensionTerraformCloudFormation
CloudsMulti-cloud: AWS, Azure, GCP, and many moreAWS only
LanguageHCL (concise, purpose-built)JSON or YAML
StateYou manage it (remote backend such as S3)AWS manages it, nothing to run
RollbackYou review the plan; drift shows on next planAutomatic rollback to last healthy state
EcosystemLarge provider and module registryDeep, first-party AWS integration, StackSets
CostFree tool (paid options for collaboration)Free tool (you pay for AWS resources)
Best forMulti-cloud, non-AWS services, complex estatesTeams that are all-in on AWS

05The real differences that matter

Beyond the table, a handful of differences show up in daily work.

State management.

This is the biggest philosophical split. Terraform's user-managed state is more work to set up, but it is inspectable and gives you control over backends and access policies, which teams with strict compliance or audit needs often prefer. CloudFormation's managed state is one less thing to run, at the cost of that transparency.

Syntax.

Most engineers find HCL cleaner and more readable than CloudFormation's JSON or YAML, especially as templates grow. CloudFormation's YAML mirrors AWS's own resource model closely, which can feel familiar if you live in AWS, but it gets verbose at scale.

Rollback and drift.

CloudFormation's automatic rollback is a genuine convenience. Drift, where someone changes a resource outside your templates, is handled differently: CloudFormation has an explicit drift-detection command you run, while Terraform surfaces drift every time you run a plan, which many teams prefer because you see it constantly rather than having to check.

Scale.

CloudFormation stacks have hard limits that push large estates toward many stacks with cross-stack references, which gets fiddly. Terraform's modules and workspaces give you more flexible ways to slice a big estate, though you have to design that structure yourself.

Ecosystem.

Terraform's provider and module registry is a real advantage: there are battle-tested modules for common patterns like a VPC, an EKS cluster, or an RDS database, which can save you real time. You will see specific provider counts quoted around the web; treat those numbers loosely, they vary by source. The point that holds is that the breadth is large.

06The 2026 wildcard: Terraform's license change and OpenTofu

Here is the part most comparisons still skip, and it may matter more to your decision than any feature.

In 2023, HashiCorp changed Terraform's license from the open-source MPL to the Business Source License (BUSL), a source-available license that is not OSI open source. For most teams using Terraform internally, day-to-day usage did not change; the license mainly restricts offering Terraform as a competing commercial service. But it was a real shift, and it prompted a reaction.

The community forked the last open-source version of Terraform into OpenTofu, now hosted by the Linux Foundation. OpenTofu keeps Terraform's HCL language and provider compatibility, has been production-ready since early 2024, and by 2026 is a mature, near drop-in replacement for most Terraform workflows. It has also been accepted into the Cloud Native Computing Foundation. Separately, IBM acquired HashiCorp, with the deal closing in 2025, so Terraform is now an IBM product; that did not change the license, but it raised questions about long-term direction.

Terraform vs CloudFormation at a glance, with the OpenTofu wildcard. If an open-source license is a hard requirement, OpenTofu belongs in the conversation alongside these two.

Terraform vs CloudFormation at a glance, with the OpenTofu wildcard. If an open-source license is a hard requirement, OpenTofu belongs in the conversation alongside these two.

What does this mean for your choice? If you were going to pick Terraform and an open-source license matters to you or your customers, evaluate OpenTofu as well; for most teams it behaves like Terraform. If you are choosing CloudFormation because you are all-in on AWS, none of this changes your decision. Either way, it is worth knowing the landscape shifted, so you are not surprised later.

07You are not limited to these two

"Terraform vs CloudFormation" is the common framing, but it is not the whole field. A few alternatives are worth knowing:

OpenTofu

The open-source Terraform fork described above, for teams that want Terraform's model without the BUSL license.

Pulumi

Which lets you define infrastructure in general-purpose programming languages like TypeScript, Python, or Go, rather than a dedicated config language.

AWS CDK

Which also uses real programming languages but compiles down to CloudFormation, so it stays AWS-native while giving you a nicer authoring experience.

Azure Bicep

Azure's cleaner, native alternative to raw ARM templates, if your world is Azure rather than AWS.

You do not need to evaluate all of these. But knowing they exist keeps the decision honest: the answer is not always one of just two tools.

08Which should you choose?

Here is the honest, scenario-based verdict.

1

All-in on AWS, simple to moderate needs:

CloudFormation (or AWS CDK if you want real languages). You get AWS-native integration and nothing extra to manage.

2

Multi-cloud, or any non-AWS services:

Terraform. This is its core strength, and it is not close.

3

Complex logic, many environments, reusable patterns:

Terraform. HCL and the module registry handle this well.

4

Open-source license is a hard requirement:

OpenTofu, which behaves like Terraform for most teams.

5

Already have deep Terraform or deep CloudFormation expertise:

Lean toward what your team already knows, unless a concrete need pushes you to switch.

There is no universally correct answer, and you should be skeptical of anyone who gives you one. If you want a second opinion tailored to your stack, our Terraform consulting team makes this call with startups regularly, and our infrastructure as code services cover the broader setup. If you are still getting your head around the fundamentals, our explainer on what infrastructure as code is is a good starting point.

Not sure which fits your stack?

We help startups choose between Terraform, CloudFormation, and the alternatives, then set it up so it holds as you scale.

Terraform consulting

09Migrating from CloudFormation to Terraform

Because teams often start on CloudFormation and move to Terraform as they grow, this migration is common enough to plan for honestly. It is doable, but it is not free.

The typical path: tools such as cf2tf or former2 help convert existing CloudFormation templates into Terraform configuration, and terraform import brings your already-provisioned resources under Terraform's management so you do not have to recreate them. The work that takes time is reconciling state, testing that Terraform's plan matches reality, and restructuring templates into clean modules rather than a direct one-to-one translation. Budget real engineering time for it, and migrate incrementally rather than all at once. If you would rather not run that migration yourself, our managed DevOps services and DevOps automation teams do exactly this kind of work.

Frequently Asked Questions

Common questions about Terraform and CloudFormation

Quick answers to the most common questions.

01Is Terraform better than CloudFormation?
Neither is universally better. Terraform wins when you are multi-cloud or use non-AWS services, thanks to one workflow across providers and a large module ecosystem. CloudFormation wins when you are all-in on AWS and want zero state management, automatic rollback, and day-one support for new AWS services.
02Should I use Terraform or CloudFormation?
Use CloudFormation if your infrastructure lives entirely in AWS and you want the simplest AWS-native option. Use Terraform if anything touches a non-AWS service, or you expect to go multi-cloud. Most teams that grow beyond pure AWS end up on Terraform.
03Is Terraform still open source?
Terraform moved from the open-source MPL license to the source-available Business Source License in 2023, so it is no longer OSI open source. Most teams can still use it free for internal work. If a truly open-source license matters to you, OpenTofu is the MPL-licensed community fork.
04What is OpenTofu?
OpenTofu is an open-source fork of Terraform, created after the 2023 license change and governed by the Linux Foundation. It keeps Terraform's HCL language and is a near drop-in replacement for most workflows.
05Can I migrate from CloudFormation to Terraform?
Yes. Teams commonly move to Terraform as they add non-AWS services or need more flexibility. Tools such as cf2tf and former2 help convert templates, and terraform import brings existing resources under management, but plan for real migration effort.
Get Expert Help

Choosing an IaC tool, or untangling one you have outgrown?

We help teams pick between Terraform, CloudFormation, and the alternatives, and set up infrastructure as code that will hold as you scale.

No pressure. Just a conversation to see if we're a good fit.