I’ve been learning about CDK at work, using it for Infrastructure as Code (IaC).
What is CDK?
These “Cloud Development Kits” are used for defining and provisioning cloud infrastructure resources using familiar programming languages including TypeScript, Python, Java and Go. In AWS, CDK is offered in addition to AWS SDK for various languages.
What they share: all three use the constructs programming model (object-oriented code → declarative infra).
What they target:
- AWS CDK → CloudFormation templates (JSON/YAML) + asset packaging.
- cdk8s → Kubernetes manifests (YAML).
- CDKTF → Terraform configuration (Terraform JSON), then Terraform does the planning/applying/state.
CDK Family
- AWS CDK: AWS Cloud Development Kit Documentation
- cdk8s: cdk8s (Website)
- CDKTF: CDK for Terraform | Terraform | HashiCorp Developer
As far as history goes, it seems AWS CDK was first, then cdk8s, and finally CDKTF. I remember the hype about CDKTF a few years ago.
cdk synth
The different CDK tools each have their own CLI, however some commands are similar and related. For example cdk synth.
“synthesize”
Turn constructs-based code → declarative output for the downstream engine.
| Tool | Command | Produces | Next step |
|---|---|---|---|
| AWS CDK | cdk synth (alias: cdk synthesize) | CloudFormation template(s) | cdk deploy |
| cdk8s | cdk8s synth | Kubernetes Manifests | kubectl apply -f dist/ |
| CDKTF | cdktf synth | Terraform JSON | cdktf plan / cdktf deploy |
Quick CLI
| Stage | AWS CDK | cdk8s | CDKTF |
|---|---|---|---|
| Init | cdk init app --language ts | cdk8s init typescript-app | cdktf init --template=typescript |
| Bootstrap / State | cdk bootstrap | (none) | Configure TF backend (state) |
| Synthesize | cdk synth | cdk8s synth | cdktf synth |
| Preview | cdk diff | kubectl diff -f dist/ | cdktf plan |
| Deploy | cdk deploy | kubectl apply -f dist/ | cdktf deploy |
| Destroy | cdk destroy | kubectl delete -f dist/ | cdktf destroy |
Construct Hub
Construct Hub helps developers find open-source construct libraries for use with AWS CDK, CDK8s, CDKTF and other construct-based tools.
Supported Programming Languages
- The AWS CDK supports TypeScript, JavaScript, Python, Java, C#/.Net, and Go.
- CDKTF supports TypeScript, Python, Java, C#, and Go.
- cdk8s lets you define applications using Typescript, JavaScript, Python, Java, and Go.
| Language | AWS CDK | CDKTF | cdk8s |
|---|---|---|---|
| TypeScript | ✓ | ✓ | ✓ |
| JavaScript | ✓ | ✓ | |
| Python | ✓ | ✓ | ✓ |
| Java | ✓ | ✓ | ✓ |
| C# | ✓ | ✓ | |
| Go | ✓ | ✓ | ✓ |
Most Used Programming Languages
- Reddit Poll for AWS CDK shows “JavaScript or TypeScript” as the most used: Poll: Which programming language do you use for AWS CDK? : r/aws
- Reddit Poll for CDKTF shows “Python” as the most used: Poll: Which programming language do you use for CDKTF? : r/Terraform
Comparison to HCL
The most used IaC language remains HCL, using Terraform or OpenTofu.
HCL syntax is designed to be easily read and written by humans, and allows declarative logic to permit its use in more complex applications.
HCL is declarative, compared to traditional programming languages which are imperative. HCL is a good fit for provisioning IaC, however some find it limiting. While solutions like Terragrunt address some of Terraform’s limitations, some wished for the flexibility of a full programming language. This was what led to the birth of HCL.
CDKTF still uses Terraform providers under the hood, and synthesizes to valid Teraform JSON.
My Usage At Work
At my client, I wanted to use OpenTofu for IaC. However, I was told that AWS CloudFormation is what’s already used internally at the client.
For my current use-case, my IaC mainly consists of an EC2 instance configured for use as a Bitbucket Runner. I decided to use AWS CDK for this use case, as it works with AWS CloudFormation but is more flexible than the JSON syntax that CFN uses.
Converting my working OpenTofu HCL code to AWS CDK TypeScript code was frustrating and made me curse AWS multiple times. However, I eventually got it working and functionally equivalent to what I already had working with OpenTofu.
My Opinion
Declarative vs Imperative IaC
I personally don’t find much value in using a “real” programming language for IaC. I believe Terraform owes a lot of success to the simple, imperative nature of HCL, and in some ways succeeded because of its limitations and not despite them.
My experiences with Pulumi and AWS CDK show me that if not being careful, the IaC could turn into spaghetti code. Of course, the potential for spaghetti code exists for HCL as well, especially when attempting to overcome some of its limitations. However, I believe for many of the common use-cases of IaC, the imperative design fits better and should be used unless there is a specific need for a “real” programming language.
AWS CDK
Assuming I get the choice, I wouldn’t willingly use AWS CDK again. I have tried many IaC tools. Terraform, Ansible, OpenTofu, Terragrunt and Pulumi. Out of all ones I tried, AWS CDK was by far the most confusing.
CDKTF
I was initially interested in CDKTF, but it seems it has gained very little traction compared to Terraform or OpenTofu:
- Why CDKTF has such little adoption? : r/Terraform
- Is CDKTF becoming abandonware? : r/Terraform
- CDKTF .Net vs Normal Terraform? : r/Terraform
I was also concerned that CDKTF might not work well with OpenTofu. It seems it does currently work even if it’s not officially supported, but might break in the future: Port cdktf to OpenTofu · Issue #601 · opentofu/opentofu · GitHub
I believe that CDKTF is now an afterthought for HashiCorp, compared to Terraform. Development for CDKTF is not completely abandoned, but based on recent activity development seems slow and mainly focuses on fixes and dependency updates, rather than major new features.
cdk8s
I haven’t found a compelling reason to use this either. I’m not sure where exactly it fits into the Kubernetes manifest landscape between KYAML, Helm Charts, Kustomizations, CUE/HCL and GitOps solutions (mainly Argo CD and Flux CD).
Pulumi IaC
Not technically CDK but is similar in many ways. Supports TypeScript, JavaScript, Python, Go, C#, Java and YAML. Last year, Pulumi introduced support for any Terraform Provider, With that, I believe Pulumi can serve as a solid replacement for CDKTF (not a drop-in replacement, but can be functionally equivalent). Unlike HashiCorp, which seems to treat CDKTF as an afterthought, Pulumi (the company) is primarily focused on Pulumi IaC. pulumi/pulumi is open-source under the Apache-2.0 license, though Pulumi as a company also offers paid solutions (such as Pulumi Cloud).
If I had to choose between CDKTF and Pulumi, I would lean towards Pulumi.
Photo by Abraham Barrera on Unsplash.





