Pulumi vs CDK vs CDKTF: how to choose
All three let you define infrastructure in a general-purpose programming language instead of a domain-specific one, and they differ in what they produce underneath. AWS CDK synthesises CloudFormation and is AWS-only. CDKTF synthesises Terraform JSON and uses Terraform providers. Pulumi has its own engine and provider model with its own state backend.
The shared appeal is real: loops, conditionals, functions, types and your existing test framework, instead of expressing logic in HCL or YAML. For teams with genuine abstraction needs — a platform team shipping reusable components to many application teams — that is worth a lot.
The shared risk is also real. A general-purpose language makes it easy to build abstractions no one else can read, and infrastructure code that requires understanding three layers of inheritance to answer "what will this create" is worse than verbose HCL. The tools do not cause this; they remove the constraint that was preventing it.
What each one actually produces
| AWS CDK | CDKTF | Pulumi | |
|---|---|---|---|
| Synthesises to | CloudFormation | Terraform JSON | Its own engine's plan |
| Cloud coverage | AWS only | Anything with a Terraform provider | Multi-cloud, own provider ecosystem |
| State | CloudFormation manages it | Terraform state | Pulumi Cloud or self-managed backend |
| Languages | TypeScript, Python, Java, C#, Go | TypeScript, Python, Java, C#, Go | TypeScript, Python, Go, C#, Java, YAML |
| Escape hatch | Raw CloudFormation resources | Existing Terraform modules and providers | Terraform provider bridge |
| Best fit | All-in on AWS | Terraform estate wanting real code | Multi-cloud, no prior Terraform investment |
The state backend is the commitment
With AWS CDK, state is CloudFormation and therefore AWS's problem — no state file to store, lock or lose, which is a genuine operational advantage. The trade is CloudFormation's behaviour, including slow updates and rollbacks that can leave a stack in a state needing manual intervention.
CDKTF inherits Terraform state with all its familiar handling. Pulumi defaults to its hosted backend, which is convenient and a dependency — self-managed backends exist and are well supported, so decide deliberately rather than by default. This choice is harder to reverse than the language, so weigh it more heavily.
Frequently asked questions
Is writing infrastructure in a programming language a good idea?
It is a good idea when you have genuine abstraction needs and the discipline to keep them shallow. A platform team building components for many teams benefits enormously. A single team managing a handful of resources usually finds HCL's explicitness easier to read at 3am. The failure mode is not the tool — it is over-abstraction that the tool no longer prevents.
Can I use CDK constructs with Terraform?
Not directly — AWS CDK constructs synthesise CloudFormation. CDKTF is the project for using CDK-style programming against Terraform providers, and its construct ecosystem is separate and smaller. If your investment is in AWS CDK constructs, moving to CDKTF is a rewrite rather than a port.
How do these handle drift?
Through their underlying engines. CDK relies on CloudFormation drift detection, which is limited in what it can see. CDKTF gets Terraform's plan, which is thorough. Pulumi's refresh compares state against reality and is comparable. If drift detection matters to you, this is a stronger differentiator than the language.
Which is best for a team already on Terraform?
CDKTF, if you want programming-language ergonomics without abandoning your providers and modules — you keep the ecosystem and change the authoring layer. Be honest about whether you need it though: many teams find their pain was module structure and naming rather than HCL itself, and adding a synthesis step does not fix that.
