AWS CDK vs Terraform vs SST: Picking IaC for Serverless in 2026

Infrastructure-as-code for serverless has three serious contenders in 2026: AWS CDK, Terraform, and SST. They look similar from a distance and feel very different in daily use. Here’s how they actually differ where it counts.

The short version

• AWS CDK — real TypeScript (or Python/Java/Go) compiled to CloudFormation. Strong typing across stacks, AWS-managed deployments, AWS-only.
• Terraform — declarative HCL with the broadest provider ecosystem and a multi-cloud story. You manage state; drift detection is a first-class feature.
• SST — a higher-level framework (now on the Pulumi/Terraform engine) focused on developer experience for full-stack serverless, with live local Lambda development.

Language and typing

CDK’s headline feature is that infrastructure is ordinary code in a real language. A Cognito user pool is an object; passing its ARN to your Lambda’s environment is a normal property reference the compiler checks. Loops, conditionals, and shared constructs are just programming. The cost is a layer of indirection — your code synthesizes CloudFormation, and occasionally you debug the generated template, not 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 you can’t hide a surprising side effect in a for-loop. For pure-AWS serverless, though, you’ll write more boilerplate than CDK’s L2 constructs require.

SST sits highest. Its components encode opinions — an Api or a Next.js site is a few lines — so you write the least code of the three, at the price of leaning on those opinions when your needs diverge.

State and drift

This is the sharpest practical divide. Terraform and SST manage their own state file, which you store and lock (typically in S3 + DynamoDB or a managed backend). State is powerful — it’s how Terraform plans precise diffs — but it’s also a thing that can get out of sync, locked, or corrupted, and it needs care in a team.

CDK has no state file you manage. CloudFormation is the state, held by AWS. Deployments are transactional and roll back on failure, and drift detection is a CloudFormation feature. You trade some flexibility for not owning a state backend at all — fewer moving parts, fewer 2 a.m. “state is locked” incidents.

Template-driven vs. API-driven: can you see what it deployed?

This is a difference that doesn’t show up in a feature matrix but matters the first time something goes wrong. CDK is template-driven: it synthesizes CloudFormation, and AWS records every resource as a stack you can open in the console — what exists, what changed, the event log, drift, rollback history. The deployment leaves a first-class, AWS-native artifact you can inspect straight from the account.

SST v3 went the other way. It dropped CloudFormation for an API-driven model built on Pulumi (with Terraform providers underneath), creating resources via direct AWS SDK calls. Terraform works the same way — its state file and provider API calls, not a CloudFormation stack. SST made an explicit case for this: CloudFormation can be slow, imposes per-stack resource limits, and has painful failure modes — sluggish rollbacks and the occasional stuck resource. API-driven deploys sidestep all of that and are often genuinely faster, running operations in parallel and skipping no-ops.

The catch is visibility. With an API-driven tool there’s no CloudFormation stack to open — what got deployed lives in the tool’s own state and representation, not as an AWS-native record you can browse from the console. When you’re debugging, auditing, or just asking “what did this actually create,” that native, account-side view is worth a lot. CDK’s bet is that the template is the artifact: occasionally slower, but you — and AWS — can always see exactly what’s there.

Blast radius and deploys

CDK organizes resources into stacks, and a stack is the unit of deployment and rollback. Get your stack boundaries right — DNS, auth, data, and each app in their own stack — and a bad change to one surface can’t take down another. Terraform offers similar isolation via workspaces and modules, but the boundaries are a convention you enforce rather than a deployment primitive.

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

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

Multi-cloud

If you need AWS plus Cloudflare plus a SaaS provider in one graph, Terraform’s provider ecosystem is unmatched and the deciding factor. CDK is AWS-only by design (CDK for Terraform exists but is a different tool). SST can reach other providers through its Pulumi/Terraform engine but is happiest on AWS. For a single-cloud serverless SaaS, multi-cloud breadth is a feature you’re paying for and not using.

The new tiebreaker: AI-agent ergonomics

A consideration that barely existed two years ago: how well can a coding agent operate your infrastructure? CDK has a real edge here. Because it’s typed TypeScript, an agent gets compiler feedback, autocomplete-quality 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 the typed cross-stack references in CDK catch a class of mistakes before any deploy runs.

Stewardship and longevity

Infrastructure code is a multi-year commitment — you’re choosing a tool you’ll still be running long after the initial deploy. So it’s worth asking who’s steering each project and how well their incentives line up with keeping it healthy. As of early 2026, the three tell different stories here.

• CDK is AWS’s own project. It’s first-party, and AWS has a direct, durable incentive to keep it current: CDK exists to make building on AWS easier, so new services arrive with CDK support as a matter of course. For a team committed to AWS, that incentive alignment is the strongest longevity signal of the three — the maintainer is the same company running your infrastructure.
• Terraform’s stewardship has shifted. HashiCorp relicensed Terraform under the Business Source License in 2023 — which prompted the community to fork it as OpenTofu under the Linux Foundation — and HashiCorp has since been acquired by IBM, while founder Mitchell Hashimoto moved on to projects of his own. Terraform itself is still heavily maintained, but its licensing and governance are more complicated than they were, and “Terraform or OpenTofu?” is now a question you have to answer.
• SST’s core team has a new focus. SST is open source and still shipping, but much of its core team’s attention appears to have moved to a separate product — opencode, an AI coding agent. That doesn’t mean SST is going away, but a small core team splitting focus is a genuine risk to weigh before you build your entire infrastructure layer on it.

None of this is a knock on the engineering — all three are excellent tools, and these situations can change. It’s about incentive alignment over a long horizon, and on that axis a first-party AWS tool is hard to beat for a team that’s already all-in on AWS.

How to choose

• Single-cloud AWS, TypeScript team, want types end to end: CDK — and you also get the strongest stewardship story for an AWS shop.
• Multi-cloud, or you want explicit plans and the broadest ecosystem: Terraform (or OpenTofu) — its provider breadth is still unmatched and worth the governance footnotes.
• Optimizing purely for full-stack serverless DX and speed of iteration: SST — best DX of the three, with the maintenance-focus caveat above.

For a TypeScript SaaS on AWS that you intend to build alongside an AI agent, CDK’s typing, AWS-managed state, one-command deploys, and first-party longevity are why we standardized on it — it’s the foundation of the cdkbase template.