CloudFormation and Terraform both provision AWS infrastructure, and both work. The comparison articles you’ll find online usually conclude with something like “it depends on your team” without explaining what it actually depends on. As someone who has worked with both at production scale and been the person who had to explain the tradeoffs to teams making the decision, I learned which factors actually matter. Today I’ll share the honest version that most comparison articles skip.
This article includes affiliate links. We may earn a commission at no extra cost to you.
The Core Difference That Everything Else Flows From
CloudFormation is an AWS service. Terraform is a third-party tool that calls AWS APIs. This distinction is more consequential than it sounds.
When AWS releases a new service or feature, CloudFormation support usually lags by weeks to months. Terraform providers are maintained by the community and HashiCorp, and new AWS resource types appear in the Terraform AWS provider often faster than in CloudFormation — sometimes on the same day as release. If you’re building on the leading edge of AWS services, this gap matters.
CloudFormation’s advantage is that it’s native to AWS. The state is managed by AWS — you don’t have a state file to manage, back up, or accidentally corrupt. Drift detection is built in. If something goes wrong during a stack update, CloudFormation rolls back automatically.
When CloudFormation Makes Sense
Pure AWS shops with standard services. If your infrastructure is entirely on AWS and uses services that CloudFormation supports well (EC2, ECS, RDS, S3, Lambda, API Gateway), CloudFormation covers everything you need. The managed state is a genuine advantage — one less thing to operate.
Organizations already using CDK. AWS CDK (Cloud Development Kit) generates CloudFormation templates from code in TypeScript, Python, Go, or Java. If your team prefers writing infrastructure in a real programming language over YAML, CDK gives you that while staying on CloudFormation. That’s what makes CDK endearing to developers who find raw CloudFormation YAML difficult to read — you get the managed state benefits without writing 300-line YAML files by hand.
When Terraform Makes Sense
Multi-cloud or hybrid environments. Terraform manages AWS, Azure, GCP, and hundreds of other providers with the same tooling and workflow. If your infrastructure spans multiple clouds or includes non-AWS services (Datadog, PagerDuty, Cloudflare, GitHub), Terraform can manage all of it. CloudFormation only manages AWS resources.
Teams that need the latest AWS features immediately. The Terraform AWS provider routinely supports new AWS resources before CloudFormation does. For teams building on services that were recently released, this gap is often the deciding factor.
Better state inspection and manipulation. Terraform’s state file is a known format you can query, import resources into, and manipulate when needed. State operations like terraform import and terraform state mv are mature and well-documented. I’m apparently someone who has needed to import existing resources into state more times than I’d like to admit, and the Terraform workflow for this is genuinely smoother than CloudFormation’s equivalent.
The Honest Part That’s Usually Left Out
Terraform state management is real overhead. The state file needs to be stored in S3 with DynamoDB locking, and it needs to be treated as sensitive. Teams that are new to Terraform underestimate this until they hit a state conflict or a corrupted state file. CloudFormation’s managed state genuinely removes this class of problem.
CloudFormation’s YAML is genuinely verbose. A simple ECS service with a task definition, service, load balancer target group, and security group is 300+ lines of CloudFormation YAML. The same thing in Terraform HCL is roughly half that. Probably should have led with this observation, honestly — for large infrastructure codebases, this verbosity difference compounds into a significant maintenance burden that isn’t obvious until you’re staring at a 2,000-line CloudFormation template.
The practical conclusion: new AWS-only projects that don’t need cutting-edge services should evaluate CDK + CloudFormation seriously. Projects with multi-cloud requirements or teams that need the latest AWS features should use Terraform. Either way, pick one and be consistent — mixing both in the same organization creates more confusion than either choice would have caused independently.
Leave a Reply