I've Used All Three, and Here's What I Actually Recommend (It's Not What You Think)

I remember the exact moment our infrastructure decision became a problem. We were three months into a greenfield AWS project, our CloudFormation templates were pushing 2,000 lines of YAML, and I was debugging a cryptic error message that looked like it was generated by aliens. A teammate casually mentioned CDK, and suddenly I was torn between three competing standards that all claimed to be the "right" choice. That conversation sent me down a rabbit hole I've been crawling out of ever since.

The thing is, every developer I know eventually hits this wall. Your first AWS project starts simple enough with CloudFormation or a quick CDK script, but then you inherit a legacy stack, or your company decides to go multi-cloud, or you realize your team actually knows Python better than TypeScript. The question "which IaC tool should we use?" sounds simple until you realize the answer genuinely depends on things nobody tells you about in tutorials.

The Three Players (And What They Actually Are)

Let me cut through the marketing speak. CloudFormation is AWS's native tool, think of it as the canonical source of truth that AWS themselves use. CDK is an abstraction layer that compiles down to CloudFormation. Terraform is the independent player that works everywhere but manages its own state.

This distinction matters more than people realize. I've seen teams pick Terraform because "it's more portable" when they're building a pure AWS stack and will never touch another cloud. I've also seen teams stuck with CloudFormation because they thought it would be simpler, then spent weeks wrestling with intrinsic functions and Conditions blocks.

CloudFormation: The Comfort Zone (With Teeth)

I still use CloudFormation when I'm building something that's going to live entirely in AWS and stay there. Zero state management headaches. AWS gives you rollback, drift detection, and stack operations out of the box. The day a new AWS service launches, it's available in CloudFormation the same day.

But honest feedback: the developer experience is painful. Writing YAML that scales past 1,000 lines is miserable. You can't create proper abstractions. You're writing the same patterns over and over. For small, self-contained stacks (like a networking foundation or a single service), CloudFormation is fine. For anything complex, I'd rather use something else.

CDK: Where I Do My Real Work

This is where I spend most of my time now, and it's because of one word: abstraction. Once I wrote a reusable construct for a "hardened ECS service," I never wanted to go back to writing the same 200 lines of infrastructure configuration by hand again.

CDK lets me use actual programming languages. I can write loops. I can unit test my infrastructure. I can create a library of constructs that my team uses consistently. The developer experience is genuinely better if your team knows TypeScript or Python.

The downside I keep running into: CDK is still just CloudFormation with extra steps. If CloudFormation can't do something, neither can CDK. And when you're debugging at 2 AM, you're often reading CloudFormation docs anyway.

Terraform: The Pragmatist's Choice

Here's the uncomfortable truth about Terraform: I use it when my infrastructure crosses cloud boundaries, or when I'm managing things that aren't AWS (like Kubernetes, DataDog, GitHub repos). The state management is genuinely annoying, S3 + DynamoDB locking is industry standard for a reason, but it works.

What I like: the provider ecosystem is massive, HCL is cleaner than YAML, and terraform plan actually shows you what will happen before you apply it. What I dislike: state drift is a real problem, failed applies can leave things half-deployed, and the community solutions to common problems (like referencing outputs across projects) feel hacky.

My Take: Context Is Everything

Here's what I'd actually recommend based on real scenarios:

Pure AWS, small team, wants to move fast? CDK with TypeScript. The learning curve pays dividends.

Enterprise AWS with multiple accounts, governance requirements? CloudFormation, probably managed through Service Catalog or Landing Zone Accelerator.

Multi-cloud or managing non-AWS infrastructure? Terraform. Accept the state management burden.

Team already knows Terraform? Use Terraform even for AWS-only projects. Consistency matters more than optimization.

A Question for You

What's your current pain point with infrastructure as code? Are you managing state, writing verbose templates, or dealing with multiple clouds? I'm genuinely curious whether my assumptions hold for teams in Islamabad working on different problem domains than what I typically see.

Source: This post was inspired by "Terraform vs AWS CDK vs CloudFormation: The Definitive IaC Decision Guide for 2026" by Dev.to. Read the original article