DevTools Hub

Search tools

Search for a developer tool

CloudFormation vs Terraform

Part of the AWS Toolkit

Both tools solve the same underlying problem — describe infrastructure as a file instead of a sequence of console clicks, so it can be reviewed, versioned, and applied repeatedly. Where they actually differ isn't "which one is more powerful," it's a handful of concrete tradeoffs that decide which one fits a given team.

Scope: one cloud vs. many

CloudFormation only provisions AWS resources — it's a first-party AWS service, free to use (you pay for the resources it creates, not the service itself), with zero setup beyond an AWS account. Terraform provisions resources across any cloud or service with a provider written for it — AWS, GCP, Azure, Cloudflare, Datadog, and hundreds more — through one consistent workflow. If everything you run lives in AWS and always will, that breadth doesn't buy you much. If you run workloads across more than one cloud, or need to manage SaaS resources (DNS records, monitoring, CI config) in the same place as your infrastructure, it's the reason Terraform gets reached for over a single-cloud tool.

Language: YAML/JSON vs. HCL

CloudFormation templates are YAML or JSON, with a fixed set of intrinsic functions (!Ref, !GetAtt, !Sub, and the rest) layered on top — see What Is an ARN? for what those functions typically resolve to. Terraform uses HCL (HashiCorp Configuration Language), purpose-built for this and more expressive out of the box — native for_each loops over a map or set, conditional expressions, and reusable modules with typed input variables. Both are declarative — you describe the end state, not the steps to get there — but HCL was designed for the job specifically, where CloudFormation's syntax grew out of JSON/YAML with functions bolted on.

State: managed for you vs. a file you own

This is the biggest operational difference. CloudFormation tracks a stack's state internally — there's nothing to store, back up, or lock yourself. Terraform tracks state in an explicit file (terraform.tfstate) that you're responsible for — typically stored remotely (an S3 bucket with a DynamoDB lock table is the common pattern for AWS) so a team can share it safely. That file is also sensitive: it can contain resource attributes in plain text, so losing it, corrupting it, or exposing it publicly are all real operational risks CloudFormation simply doesn't have, in exchange for Terraform's cross-cloud flexibility.

Previewing a change

Both tools let you see what's about to happen before it happens. CloudFormation does this with a change set — submit a modified template, and CloudFormation reports which resources it will add, modify, or delete, including whether a change will replace a resource entirely, without touching anything until you explicitly execute it. Terraform's plan step does the equivalent, printed as a diff before terraform apply. Neither one guarantees the actual apply will succeed — a service quota, an IAM permission gap, or a runtime constraint can still fail after a clean preview.

What happens when something fails

CloudFormation defaults to automatic rollback: if a stack fails partway through creation, it deletes everything it already created and returns the account to where it started, with no partially-built stack left behind. Terraform has no equivalent default — a failed apply leaves whatever it already created in place, tracked in state, and it's on you to fix the underlying issue and re-apply (or manually tear down what's there). CloudFormation's behavior is safer by default; Terraform's gives you more control over exactly what happens next, at the cost of having to decide.

Licensing and governance

CloudFormation is fully AWS-proprietary — there's no license question, because there's no separate license; using it just means using AWS. Terraform's history is more complicated: it was open source under the Mozilla Public License 2.0 until August 2023, when HashiCorp relicensed it under the Business Source License 1.1, restricting competing commercial use. Within weeks, a group of vendors forked the last MPL-licensed version as OpenTofu, donated to the Linux Foundation as a genuinely open, vendor-neutral alternative that stays command-line compatible with Terraform. Separately, IBM completed its acquisition of HashiCorp in February 2025, so Terraform itself is now developed under IBM. None of this changes what either tool does day to day, but it's worth knowing if "which one has stable, vendor-neutral governance" matters for a long-lived infrastructure investment.

Try it yourself

Check a CloudFormation template's structure — required sections, resource shape, dangling Refs — with CloudFormation Validator, entirely in your browser.

Related tools