AWS CDK vs Terraform

Programmatic IaC.

Overview

AWS CDK and Terraform sit at opposite ends of the IaC philosophical spectrum. CDK is programmatic: write TypeScript, Python, or Go that synthesises CloudFormation under the covers. Terraform is declarative: write HCL that describes desired state and let the planner reconcile reality. The choice depends on whether your team prefers code or config and whether you stay AWS-only or run multiple clouds.

• AWS CDK. Real programming languages, AWS-only synthesis to CloudFormation, deep type safety, abstractions through L2/L3 constructs, AWS-controlled cadence.
• Terraform. HCL declarative model, multi-cloud, mature provider ecosystem, plan-and-apply state model, module registry, OpenTofu fork option.
• Operational fit. CDK wins when the team is AWS-only and prefers TypeScript or Python; Terraform wins for multi-cloud or teams that prefer declarative config and reviewable plans.
• Per-team decision and exit cost. CDK output is CloudFormation, which locks you to AWS deeper; Terraform stays portable across clouds.

The approach

Match the tool to the team's language fluency, the cloud surface, and the change-review culture. Both ship working infrastructure; the engineering experience differs sharply.

• Cloud-surface check. AWS-only with no plans to expand leans CDK; multi-cloud or hybrid leans Terraform.
• Language fluency check. Teams that already write TypeScript or Python ship faster in CDK; teams that prefer config-as-text ship faster in Terraform.
• Plan-on-PR review culture. Terraform's plan output is reviewable in PRs; CDK's diff is harder to read at scale, especially with synthesised CloudFormation churn.
• Document the choice and the trigger to revisit. Capture rationale and the conditions (multi-cloud move, language fluency change) that would flip it.

Why this compounds

The right IaC tool keeps paying back: every new environment inherits the same modules, the same plan-and-apply gate, and on-call always knows where the source of truth lives.

• Operational fit. Matching tool to team language fluency removes weekly friction.
• Engineering velocity. Reusable modules or constructs compound across services.
• Release safety. Plan-on-PR turns infrastructure changes into reviewable artefacts.
• Decision trail for the next environment. Each documented choice teaches the next team which questions to ask, not which tool to default to.