CloudFormation vs Terraform: Key Differences and How to Choose

CloudFormation is AWS's native infrastructure as code service. Terraform is HashiCorp's infrastructure as code tool for AWS and many other providers. The core difference: CloudFormation manages state for you and only deploys AWS resources, while Terraform deploys to AWS plus other clouds, Kubernetes, and SaaS tools, and leaves state storage and locking to you.

Both describe infrastructure in files, show proposed changes before they happen, and keep a record of what they manage. The differences show up in day-two work: how changes are previewed, what happens when one fails, how drift is found, and how many systems one workflow can cover.

CloudFormation vs Terraform at a Glance

• Scope: CloudFormation deploys AWS resources and registered extensions. Terraform deploys anything with a provider in its registry, including AWS, Azure, Google Cloud, Oracle Cloud, Kubernetes, and SaaS platforms.

• Language: CloudFormation templates are JSON or YAML. Terraform uses HCL, with expressions, functions, and modules built into the language.

• State: CloudFormation keeps state inside the stack, managed by AWS. Terraform writes a state file that you store, lock, protect, and back up.

• Preview: CloudFormation uses change sets. Terraform uses terraform plan.

• Failure handling: CloudFormation rolls a failed stack update back to its last stable state by default. Terraform stops, records what it already changed in state, and you fix forward.

• Drift: CloudFormation has built-in drift detection for supported resource types. Terraform shows drift through a refreshed plan, such as terraform plan -refresh-only.

• Licensing: CloudFormation is an AWS service with no extra charge for AWS resource types. Terraform has been under the Business Source License since 2023; OpenTofu is its open-source fork under MPL 2.0.

State: Managed for You or Managed by You

With CloudFormation there is no state file to lose. AWS tracks every resource in a stack, and deleting the stack deletes what it created unless you set a retention policy. The trade-off is that the stack is the unit of everything: refactoring resources between stacks takes care, and resources created outside a stack need an import before CloudFormation can manage them.

Terraform state is a file you own. Teams usually keep it in a remote backend such as S3, Azure Storage, Google Cloud Storage, or HCP Terraform, with locking so two runs cannot write at once. That gives you flexibility, including moving resources between configurations, but it also means state can be lost, leaked, or edited badly. State files can contain secrets, so access to them deserves the same care as access to production.

Previewing and Rolling Back Changes

A CloudFormation change set lists the resources a stack update will add, modify, or replace. If the update fails partway, CloudFormation rolls back automatically, which is a real safety net for teams that deploy straight from a pipeline.

A Terraform plan shows the same kind of diff, attribute by attribute, and is easy to post into a pull request for review. Terraform does not roll back a failed apply. Anything it created before the failure stays in state, and the next plan shows what is left to do. In practice teams rely on plan review, small changes, and approval gates rather than rollback.

Language and Reuse

YAML and JSON are familiar, but large CloudFormation templates get long. Reuse comes from nested stacks, CloudFormation modules, macros, and the AWS CDK, which lets you write TypeScript, Python, Java, or Go and synthesizes a CloudFormation template.

HCL was designed for infrastructure. Loops, conditionals, and functions are part of the language, and modules from the public registry cover common patterns for most providers. Terraform also reads CloudFormation outputs and can deploy stacks through the AWS provider, which helps in mixed estates.

Provider Coverage

If everything you run is on AWS, CloudFormation covers it, and AWS often adds support for new services early. Multi-account and multi-region rollouts are handled by StackSets.

If you also run Azure, Google Cloud, Oracle Cloud, Kubernetes, DNS, monitoring, or identity providers, Terraform or OpenTofu lets one workflow cover them. That is the most common reason teams pick Terraform: one review process for infrastructure that is not all in one cloud.

Drift Detection

CloudFormation drift detection compares a stack's live resources with the template and reports differences per property, for supported resource types. You run it on demand or on a schedule through AWS Config.

Terraform finds drift when it refreshes state during a plan. A refresh-only plan shows what changed outside Terraform without proposing configuration changes. Neither approach sees resources that were never in a stack or a configuration, which is where discovery of unmanaged resources comes in.

Which Should You Choose?

Choose CloudFormation when your infrastructure is AWS-only, you want AWS to hold state and roll back failed updates, or you build with the AWS CDK, Service Catalog, or Control Tower.

Choose Terraform or OpenTofu when you run more than one cloud or provider, want one plan-and-review workflow across all of it, or want the module ecosystem. Choose OpenTofu over Terraform if an open-source license or OpenTofu-specific features matter to you.

Many organizations end up with both: older CloudFormation stacks that still work, and newer Terraform projects. That is fine as long as both follow the same review, policy, and approval rules.

Running Both Without Two Sets of Rules

ops0 treats CloudFormation, Terraform, and OpenTofu as project types in one model, so the same plan review, approval, and audit trail apply whichever engine a project uses. The person who starts a deployment cannot approve it, and that rule is enforced on the server.

Built-in policy sets for CIS, SOC 2, HIPAA, ISO 27001, ISO 27002, and GDPR include CloudFormation-specific versions, so a template is checked against the same controls as a Terraform plan. During a CloudFormation deployment, ops0 resolves template parameters from a parameters file and stored inputs, and stops with a clear error before applying if a required parameter is missing. It can also render an architecture diagram from the template for review.

Moving From CloudFormation to Terraform or OpenTofu

If you decide to consolidate, migrate one stack at a time. Translate the template, import the existing resources into Terraform state instead of recreating them, compare plans until they show no unexpected changes, and only then retire the stack with its resources retained. ops0 can migrate supported CloudFormation content into a Terraform or OpenTofu project; the CloudFormation to Terraform migration guide covers what translates cleanly and what still needs review.