← Back to blog

2026-09-03 · 8 min read

CloudFormation vs Terraform: A DevOps Engineer's Guide

An honest comparison of AWS CloudFormation and Terraform, state, drift, multi-cloud, modules, and ecosystem, to help you pick the right IaC tool for your team.

#aws#terraform#cloudformation#iac#devops
CloudFormation vs Terraform: A DevOps Engineer's Guide

CloudFormation vs Terraform: A DevOps Engineer's Guide

If you're on AWS, both CloudFormation and Terraform can provision your infrastructure as code. They solve the same core problem but make different trade-offs. Here's an honest comparison from someone who ships both, no tribalism, just where each one earns its place.

The fundamental difference: state

This is the split everything else flows from.

  • CloudFormation is a managed AWS service. AWS holds the state for you: there's no state file to manage, lock, or lose. The stack lives in the CloudFormation service.
  • Terraform keeps state in a file (locally, or remotely in S3 + DynamoDB lock, Terraform Cloud, etc.). You own and manage that state. It's more to operate, but also more transparent and portable.

CloudFormation's managed state means one less thing to break. Terraform's explicit state means more control and visibility, and one more thing to secure and back up.

Multi-cloud and beyond

This is Terraform's biggest structural advantage:

  • Terraform has thousands of providers: AWS, GCP, Azure, Cloudflare, Datadog, GitHub, Kubernetes, and more. One tool, one language, for your whole stack. If you run AWS and Cloudflare (like the Cloud Run + Cloudflare platform I've built), Terraform manages both in one workflow.
  • CloudFormation is AWS-only. There's a "CloudFormation Registry" for third-party resources, but it's nowhere near Terraform's ecosystem.

If your world is 100% AWS forever, this doesn't matter. The moment you have a second provider, it does.

Language and readability

  • CloudFormation uses YAML or JSON. It's declarative and verbose. AWS SAM and especially the AWS CDK (write it in TypeScript/Python, synthesizes to CloudFormation) make it far more pleasant, CDK is genuinely good if you want real programming-language ergonomics.
  • Terraform uses HCL, which is purpose-built for infra and very readable. Modules, variables, and expressions feel natural. for_each and dynamic blocks cover most logic needs.

Drift and day-2 operations

  • Terraform shows you a clear plan diff before every apply: this is one of its best features. terraform plan is the thing teams fall in love with. Drift detection is built into the workflow.
  • CloudFormation has drift detection too, but it's a separate action you trigger, not a natural part of every change. Change sets give you a preview, but the plan experience is less central.

Ecosystem and modules

  • Terraform has the public Registry: battle-tested modules for VPCs, EKS, RDS, and more. You can stand up a solid VPC from a community module in minutes (see my own reference architecture and module testing with Terratest).
  • CloudFormation has nested stacks and modules, but the sharing/reuse culture is thinner.

Where CloudFormation genuinely wins

It's not all Terraform. CloudFormation has real advantages:

  • No state to manage: fewer moving parts, nothing to lock or corrupt.
  • Native AWS integration: new AWS features sometimes land in CloudFormation first.
  • StackSets for deploying across many accounts/regions is clean and AWS-native.
  • Tighter IAM/service integration: it's a first-party service, so permissions and rollback behave predictably within AWS.
  • Automatic rollback on failed stack updates is built in.

My take

  • All-in on AWS, want zero state management, value AWS-native tooling and CDK ergonomics → CloudFormation (especially via CDK).
  • Multi-cloud, want the best plan/diff experience, the biggest module ecosystem, and one tool for everything → Terraform.

In practice I reach for Terraform most of the time because almost no real environment is purely one cloud, and the plan workflow plus the provider ecosystem are hard to give up. But on a strictly-AWS shop that values managed state, CloudFormation (or CDK) is a perfectly professional choice. The wrong move is arguing about the tool instead of getting your infrastructure into some version-controlled, reviewed, repeatable IaC. Either tool beats clicking in the console.

The short version

  • The core difference is state: CloudFormation manages it, Terraform makes you own it.
  • Terraform wins on multi-cloud, ecosystem, and the plan/diff workflow.
  • CloudFormation wins on no-state-management, native AWS integration, and StackSets.
  • CDK makes CloudFormation pleasant with real programming languages.
  • Pick one and commit, version-controlled IaC matters more than which tool.

Designing IaC that scales with your team is core to my consulting work, reach out.

Share:LinkedInXWhatsApp

Related articles

Reactions & comments