AWS CDK vs Terraform: Which to Use for AWS in 2026

For a single-cloud AWS app — especially in TypeScript — AWS CDK is usually the better fit: real typed code, no state file to babysit, and a first-party tool that keeps pace with AWS. Reach for Terraform when you’re multi-cloud or need the broadest provider ecosystem. Here’s the head-to-head behind that one-liner.

This is one slice of the larger AWS infrastructure-as-code landscape. If SST is also on your list, see the three-way CDK vs Terraform vs SST comparison.

At a glance

Language and typing

CDK’s defining feature is that infrastructure is ordinary code in a real language — most often TypeScript. A Cognito user pool is an object; passing its ARN into a Lambda’s environment is a normal property reference the compiler checks. Loops, conditionals, and shared constructs are just programming, and CDK’s higher-level constructs bake in sane defaults so you write far less than a raw template needs. The cost is one layer of indirection: your code synthesizes CloudFormation, and occasionally you debug the generated template rather than your source.

Terraform’s HCL is declarative and deliberately not a general-purpose language. That constraint is a feature — HCL is easy to read, diffs are legible, and nobody can hide a surprising side effect in a for-loop. For pure AWS work you’ll write more boilerplate than CDK’s constructs require, but what you write is unambiguous on the page.

State: the sharpest practical difference

Terraform manages its own state file, which you store and lock — typically in S3 with a DynamoDB lock, or a managed backend. State is what lets Terraform compute a precise plan, but it’s also a thing that can get out of sync, locked, or corrupted, and it needs real care on a team.

CDK has no state file you own. Because it synthesizes to CloudFormation, AWS holds the state as a stack: deploys are transactional and roll back on failure, drift detection is a built-in CloudFormation feature, and there’s an account-side record of every resource you can open in the console. You trade some flexibility for never owning a state backend — fewer moving parts, fewer 2 a.m. “state is locked” incidents.

Multi-cloud: usually the deciding factor

If you need AWS plus Cloudflare plus a SaaS provider in one dependency graph, Terraform’s provider ecosystem is unmatched and that’s the whole decision — CDK is AWS-only by design (CDK for Terraform exists, but it’s a different tool). The flip side: for a single-cloud AWS serverless app, multi-cloud breadth is power you’re paying for in extra boilerplate and a state backend, and not using.

Plans and drift

Terraform’s plan/apply loop is a genuine strength: you get an explicit, reviewable diff of exactly what will change before it happens. CDK leans on CloudFormation change sets and transactional deploys instead — less of an upfront diff ritual, more “deploy is safe and reversible.” Both detect drift; they just surface it differently.

# CDK: one command, dependency-ordered, transactional
cdk deploy --all

# Terraform: explicit plan, then apply against managed state
terraform plan -out tfplan
terraform apply tfplan

Licensing and stewardship

Infrastructure code is a multi-year commitment, so who steers the tool matters. CDK is AWS’s own project — first-party, with a direct incentive to keep it current, since new AWS services tend to ship with CDK support as a matter of course. Terraform’s governance has shifted: HashiCorp relicensed it under the Business Source License in 2023 — prompting the community to fork it as OpenTofu under the Linux Foundation — and HashiCorp has since been acquired by IBM. Terraform is still heavily maintained, but “Terraform or OpenTofu?” is now a question you have to answer.

The AI-agent tiebreaker

A consideration that barely existed two years ago: how well can a coding agent operate your infrastructure? CDK has an edge. Because it’s typed TypeScript, an agent gets compiler feedback, real type information, and the same mental model as the application code it’s already editing — refactors that span app and infra happen in one language. HCL is very legible to a model too, but CDK’s typed cross-stack references catch a class of mistakes before any deploy runs.

The bottom line

• Pick CDK if you’re single-cloud AWS, writing TypeScript, want types end to end and no state backend to manage — and especially if you’re building alongside an AI agent.
• Pick Terraform (or OpenTofu) if you’re multi-cloud, want the broadest provider ecosystem, or value an explicit plan step above all else.

For a TypeScript SaaS on AWS, CDK’s typing, AWS-managed state, and one-command deploys are why cdkbase defines its entire stack in it. Still weighing more than two tools? Start from the full IaC guide.