Terraform vs CloudFormation: which should you use on AWS?
Both give you infrastructure-as-code on AWS. The right choice depends on multi-cloud plans, team skills, and how much ecosystem you want. Here's the honest breakdown.
The short answer
Choose Terraform (or OpenTofu) if you value multi-cloud portability, a huge module ecosystem, and readable HCL. Choose CloudFormation if you're all-in on AWS, want native drift detection and zero extra tooling, and value tight AWS service coverage on day one.
Side by side
| Dimension | Terraform | CloudFormation |
|---|---|---|
| Scope | Multi-cloud + 3,000+ providers | AWS-only (plus limited extensions) |
| Language | HCL — concise, readable | JSON/YAML — verbose |
| State | You manage remote state (S3+lock) | Managed by AWS |
| New AWS services | Provider lag (usually days–weeks) | Often available at launch |
| Modules/ecosystem | Massive registry | Smaller; StackSets, modules |
| Drift | terraform plan | Native drift detection |
Where teams get it wrong
- Running Terraform without remote state + locking — a recipe for corrupted state and race conditions.
- Treating CloudFormation YAML as "simple" until a 2,000-line template becomes unmaintainable without nested stacks.
- Skipping policy-as-code (OPA/Conftest for Terraform, Guard for CloudFormation) so unsafe infra reaches apply.
My take after 16 years
For most teams I default to Terraform — the module ecosystem and portability outweigh the provider lag, and OpenTofu keeps it open. I reach for CloudFormation when a client is deeply AWS-native, wants AWS-managed state, or needs a service the day it launches. Either way, the wins come from modular structure, remote state discipline, and security guardrails in the pipeline — not the tool itself.
Need Terraform done right?
Modular IaC, remote state, policy-as-code and clean migrations on AWS.
Terraform consulting →Book a free call