Comparison
Terraform vs CloudFormation
Two widely used IaC choices for AWS infrastructure, with practical trade-offs.
Comparison table
| Factor | Terraform | CloudFormation |
|---|---|---|
| Provider support | Large provider ecosystem (AWS, Azure, GCP, GitHub, Datadog, Snowflake...) | AWS only (plus limited third-party via CloudFormation Extensions) |
| Language | HCL (HashiCorp Configuration Language), readable and typed | YAML or JSON, verbose; CDK generates it from TypeScript/Python |
| State management | Explicit state file (remote backend such as S3 with locking); you manage it | Managed by AWS (stack state); no state file to manage |
| Drift detection | terraform plan shows drift from state; no automatic remediation | Drift detection built in (CloudFormation drift detection); it reports drift, correcting it is a separate step |
| Module ecosystem | Large (Terraform Registry, including AWS and HashiCorp published modules) | CloudFormation modules and public registry extensions |
| New AWS service support | Depends on AWS provider releases, so support can follow a launch | Often available at or soon after launch; varies by service |
| Error messages | Varies by provider and resource | Rollback errors can be hard to interpret |
| Cost | Source-available (BSL); OpenTofu is the open source fork; HCP Terraform/Terraform Enterprise for remote execution | No charge for native AWS resource types, you pay for the resources created; third-party extensions may be billed |
When to choose each
Choose Terraform when:
- You use or plan to use multiple cloud providers or SaaS services alongside AWS
- You want a broad module ecosystem (AWS modules from the public registry)
- HCL readability and IDE support (VSCode HCL extension) matter to your team
- You want Atlantis or HCP Terraform for PR-based plan/apply workflows
- Your team has existing Terraform or OpenTofu expertise and tooling investment
Choose CloudFormation when:
- You are AWS-only and want AWS-native support for new AWS services without waiting for provider updates
- You want AWS-managed state (no S3/DynamoDB to maintain)
- You prefer AWS CDK (TypeScript/Python) over HCL for infrastructure code, CDK synthesises to CloudFormation
- You need StackSets for deploying the same stack to many AWS accounts in an Organization
- Your team already has CloudFormation expertise and a working set of templates
For multi-cloud or mixed-provider estates, Terraform or OpenTofu is often a good fit, thanks to portability, the module ecosystem and community tooling (tflint, checkov, Atlantis). For AWS-only teams, CloudFormation or CDK can be equally sound.
When does Terraform fit, and when does CloudFormation fit?
Terraform fits teams that manage more than AWS, or that want one workflow across accounts, clouds and SaaS products, while CloudFormation fits teams that are committed to AWS and value a service managed by AWS itself. Neither is wrong, and many mature organisations run both for different layers.
Team size and skills play a role. A small AWS-only team with existing templates, or developers who prefer writing infrastructure in a general-purpose language through the AWS CDK, can be very productive with CloudFormation underneath. A platform team supporting several product teams across providers usually benefits from Terraform's single language and its wide provider catalogue.
Operating model is the third factor. CloudFormation keeps stack state inside AWS, so there is no state storage to design. Terraform keeps state in a file you must store, lock, back up and protect, typically in object storage with locking. That gives more control and more responsibility, and it is where many Terraform problems begin.
- Multi-cloud or heavy SaaS configuration (monitoring, DNS, identity): Terraform.
- AWS only, small team, low appetite for state management: CloudFormation or CDK.
- Developers want TypeScript or Python for infrastructure: CDK, which generates CloudFormation.
- Organisation wide guardrails across many AWS accounts: CloudFormation StackSets are worth evaluating.
How should we decide between them?
Use a short decision framework: scope of providers, who owns state, how changes are reviewed, and how much lock-in you can accept. Score each honestly, and treat the result as a default rather than a rule. The aim is a choice your team can operate without heroics.
Provider scope is the clearest filter. If you will manage anything outside AWS in code, Terraform removes the need for a second tool. Change review is the next filter: Terraform's plan output and CloudFormation change sets both show what will change before you apply, so check which one your reviewers and pipeline tooling handle better.
Finally, consider licensing and governance. HashiCorp relicensed Terraform from the Mozilla Public License to the Business Source License in 2023, and later became part of IBM. In response, the community created OpenTofu, an open source fork now hosted by the Linux Foundation. Running Terraform for your own infrastructure remains permitted, but legal teams should read the licence terms, especially if you embed it in a product or service offered to others.
| Decision factor | Favours Terraform | Favours CloudFormation |
|---|---|---|
| Provider scope | AWS plus other clouds or SaaS | AWS only |
| State ownership | Team accepts storing and securing state | Prefer AWS to hold stack state |
| Language preference | HCL, reusable modules | YAML or JSON, or CDK in a general-purpose language |
| Preview of changes | Plan output in pull request tooling | Change sets reviewed in the AWS console or pipeline |
| Multi-account rollout | Pipelines and workspaces per account | StackSets with AWS Organizations |
| Vendor and licence stance | Comfortable with BSL, or choose OpenTofu | Part of AWS, no separate licence |
How do cost and licensing compare?
CloudFormation has no extra charge for managing native AWS resources, so you pay only for the resources it creates. Terraform has no licence fee for the command line tool, so the costs are the remote state storage, your CI runners, and optionally a commercial platform for remote execution, policy and collaboration.
The real expense on both sides is engineering time. Terraform tends to cost more in the early design of module structure, state layout and pipelines. CloudFormation tends to cost more when templates become large and teams need nested stacks, custom resources and careful handling of cross-stack references.
Third-party registry extensions on CloudFormation are billed differently from native resources, so check AWS pricing documentation if you plan to use them. For Terraform, review the current licence and any commercial terms for the platform you choose. We do not quote prices here because they change and depend on your usage.
What is involved in migrating or switching?
Migration between the two is a resource-by-resource adoption exercise, not a conversion of files. Existing infrastructure must be brought under the new tool without being recreated, so the work is mostly about importing real resources safely and proving that the first plan shows no unexpected changes.
From CloudFormation to Terraform, a sensible approach is to inventory stacks, write equivalent Terraform, import the live resources, and confirm that planning reports no differences. Only then retire the stack, using deletion policies such as retain so that removing the stack does not delete the resources it created. Terraform supports declarative import blocks, which makes the import step reviewable in a pull request.
From Terraform to CloudFormation is less common. AWS offers an IaC generator that can scan existing resources and produce templates, which helps adopt unmanaged infrastructure, but you should still review the output and test with change sets. If the starting point is console-built infrastructure, the same inventory-then-import pattern applies to either destination.
What mistakes do teams commonly make?
The usual mistakes are about process, not syntax. A single giant state or stack, shared credentials, and manual fixes in the console all lead to the same outcome: nobody trusts a plan or change set enough to apply it.
Splitting infrastructure into sensible layers early, such as networking, shared services and applications, keeps blast radius small and speeds up runs. Equally important is protecting production with reviewed pipelines instead of laptops.
- Terraform: state with no locking, no backup, or accessible to too many people.
- Terraform: unpinned provider and module versions, causing surprise changes on upgrade.
- CloudFormation: very large stacks that hit limits and make rollbacks slow and hard to read.
- CloudFormation: relying on drift detection results without a process to act on them.
- Both: manual console changes, missing policy scanning, and no tested rollback plan.
How would a neutral consultant approach the decision?
We begin with your provider footprint, team skills and audit requirements, then recommend an approach in writing, including where a mix of tools is sensible. If you already have working templates, we are as willing to recommend keeping them as to replace them.
Delivery uses fixed scope, a named senior engineer, and code placed in your own accounts and repositories, with documentation, scanning in the pipeline and a handover so your engineers own the result.
Frequently asked questions
Is Terraform still open source?
Can we use Terraform and CloudFormation together?
Does CloudFormation really support new AWS services on launch day?
How do we move existing resources without downtime?
Related pages
Need help with Terraform or CloudFormation?
Whether you are starting fresh or migrating existing CloudFormation stacks to Terraform, we can help design and implement your IaC strategy.