HomeBlogTerraform vs CloudFormation in 2026: An Engineer's Perspective
TerraformAWSIaCCloudFormation

Terraform vs CloudFormation in 2026: An Engineer's Perspective

April 2, 2026·10 min read·Omphora Engineering

The short answer

Most teams should use Terraform. CloudFormation is the right choice in a narrow set of cases. Here's why.

What CloudFormation does well

CloudFormation is AWS-native and has two genuine advantages:

  1. Tight AWS integration — CloudFormation is maintained by AWS and typically gets new service support before Terraform
  2. StackSets — deploying the same stack across multiple AWS accounts and regions in one operation
  3. No state management — state is managed by CloudFormation, not in an S3 bucket you're responsible for

Where Terraform wins

Multi-cloud: Terraform supports 3,000+ providers. If you ever need Azure, GCP, Cloudflare, Datadog, or a Kubernetes cluster alongside your AWS infrastructure — Terraform handles it in one workflow.

Better language: HCL is significantly easier to read, write, and refactor than YAML/JSON CloudFormation templates. Terraform's for_each, dynamic blocks, and locals make DRY infrastructure achievable.

Module ecosystem: The Terraform Registry has battle-tested community modules for every common AWS pattern. CloudFormation's equivalent (Service Catalog) is much more limited.

Error messages: CloudFormation's "UPDATE_ROLLBACK_COMPLETE" error messages are notoriously opaque. Terraform's plan output tells you exactly what will change before you apply.

Plan before apply: terraform plan shows you the exact diff of what will change. CloudFormation has change sets, but they're much less readable and slower to generate.

When to choose CloudFormation

  • AWS Organizations / Control Tower deployments — CloudFormation StackSets and Service Control Policies are deeply integrated
  • Teams already invested in CDK — if you're using AWS CDK (which compiles to CloudFormation), there's no reason to switch
  • AWS Config conformance packs — these are CloudFormation-based
  • Strict AWS-only environments — if you're in an environment that prohibits third-party tools

When to choose Terraform

  • Every other case

What about OpenTofu?

OpenTofu is the open-source fork of Terraform created after HashiCorp changed Terraform's license to BSL in 2023. It's CLI-compatible with Terraform and is a viable drop-in replacement if license concerns matter to your organization.

For new projects, consider whether you want the HashiCorp ecosystem (HCP Terraform for remote runs, Vault for secrets) or the fully open-source OpenTofu path. Both are excellent choices.

The migration path

If you're on CloudFormation and want to move to Terraform, the path is:

  1. Import existing resources with terraform import
  2. Write Terraform configs that match the current state
  3. Use terraform plan to verify zero diff
  4. Migrate new resources to Terraform
  5. Gradually replace CloudFormation stacks

Don't try to migrate everything at once. Incremental migration, stack by stack, is much safer.

Not sure where to start?
Let's talk.

One conversation, no commitment. We listen to what your team is struggling with and give you an honest picture of what needs to change — and what doesn't.

  • What's slowing down your team's deployment process
  • Where your cloud spend is going — and what's being wasted
  • Security vulnerabilities in your current setup
  • Reliability gaps that could cause downtime
  • Blind spots in your monitoring and alerting
Available for new projectsResponse within 1 business dayNo long-term commitment required
your-infra ~ after-omphora
$ terraform apply
✓ 23 resources. Apply complete in 4m 12s
$ kubectl get nodes
NAME STATUS ROLES AGE
ip-10-0-1 Ready worker 2d
ip-10-0-2 Ready worker 2d
ip-10-0-3 Ready worker 2d
$ argocd app list
production Synced Healthy
staging Synced Healthy
$ # Commit → production: 3m 42s
✓ Zero downtime · p99: 82ms · cost ↓ 38%
$ # Example output — results vary by workload.
3m 42s
Deploy time
38%
Cost saved
99.9%
Uptime