AWS CDK vs Terraform: Key Differences and How to Choose

The AWS Cloud Development Kit (CDK) lets you define AWS infrastructure in TypeScript, JavaScript, Python, Java, C#, or Go. It converts (synthesizes) that code into CloudFormation templates, and CloudFormation deploys them. Terraform uses HCL, calls provider APIs directly, and covers AWS plus many other clouds and services. The core difference: CDK gives you a programming language and AWS-managed state for AWS only, while Terraform gives you one configuration language and a state file you manage, across providers.

One point of confusion first. CDK for Terraform (CDKTF) was a separate HashiCorp project that let you write Terraform in programming languages. HashiCorp sunset it and archived the repository on December 10, 2025. For new work, the real choice is between the AWS CDK and Terraform or OpenTofu.

AWS CDK vs Terraform at a Glance

• Scope: CDK deploys AWS resources through CloudFormation. Terraform deploys to any platform that has a provider, such as Azure or Kubernetes, as well as AWS.

• Language: CDK uses general-purpose languages. Terraform uses HCL.

• How changes deploy: CDK runs cdk synth to produce a template and cdk deploy to hand it to CloudFormation. Terraform runs terraform plan and terraform apply against provider APIs.

• State: CloudFormation tracks every stack's resources for you. Terraform writes a state file that you store and protect.

• Failure handling: A failed CloudFormation update rolls back to the last stable state by default. Terraform stops and you fix forward.

• Reuse: CDK has constructs, from low-level resources to opinionated patterns. Terraform has modules and the public registry.

• Previewing changes: cdk diff compares your app with the deployed stack. Terraform shows a plan.

• Licensing: CDK is open source under Apache 2.0. Terraform has been under the Business Source License since 2023, and OpenTofu is its MPL 2.0 fork.

How the AWS CDK Works

A CDK app is a program. You compose constructs into stacks, and running the app produces a CloudFormation template for each stack. Constructs come in three levels: L1 constructs map one to one to CloudFormation resources, L2 constructs add sensible defaults and helper methods, such as granting a Lambda function read access to a bucket in one line, and L3 constructs, or patterns, wire several resources together.

Before the first deploy, each account and region is bootstrapped with a CDK toolkit stack that holds an S3 bucket for file assets such as Lambda code, an ECR repository for container images, and IAM roles for deployment. After that, cdk deploy uploads assets and asks CloudFormation to create or update the stack.

State and Rollback

Because CDK deploys through CloudFormation, there is no state file to store or lock. CloudFormation knows what each stack contains and rolls back a failed update automatically, which suits teams that deploy straight from a pipeline.

The trade-off is CloudFormation's limits and pace. A stack can hold up to 500 resources, large stacks deploy slowly, and moving resources between stacks needs CloudFormation stack refactoring or cdk refactor. Terraform state is more work to run safely, but it is flexible: you can move resources between configurations with moved and removed blocks and see each change in a plan.

Abstractions: Constructs vs Modules

CDK's strength is abstraction. An L2 construct can create a bucket, its encryption key, and the right IAM policy from a few lines, and teams can publish their own constructs as packages in npm or PyPI. Type checking and editor autocomplete catch mistakes before synthesis. The risk is that one line of code can create many resources, so reviewers need to read the synthesized template or the cdk diff, not only the source.

Terraform modules are less expressive but more transparent. A reviewer can read the HCL and the plan and see each resource. For platform teams reviewing changes across many accounts, that predictability often matters more than expressiveness.

Which Should You Choose?

Choose the AWS CDK when your infrastructure is AWS-only, your team writes TypeScript or Python every day, and you want CloudFormation to hold state and roll back failed deployments.

Choose Terraform or OpenTofu when you run more than one cloud, manage SaaS and Kubernetes alongside AWS, want one plan-and-review workflow across all of it, or prefer a configuration language reviewers can read without knowing a programming language.

If you are on CDK for Terraform today, HashiCorp's sunset notice recommends cdktf synth --hcl to generate standard Terraform configuration, or moving to the AWS CDK if your stack is already tightly tied to it.

Seeing Everything, Whichever Tool Deployed It

Many AWS estates end up with CDK stacks, Terraform projects, and resources created in the console, all in the same accounts. ops0 discovery is read-only and works from the cloud APIs, so it shows what is running across AWS, Google Cloud, Azure, Oracle Cloud, and Kubernetes regardless of which tool created it. See multi-cloud discovery.

For the infrastructure code itself, ops0 runs Terraform, OpenTofu, and CloudFormation projects through one review flow: plan review, policy checks for CIS, SOC 2, HIPAA, ISO 27001, ISO 27002, and GDPR, with CloudFormation-specific policy versions, and an approval step where the person who starts a deployment cannot approve it.