AWS CDK for Terraform

Definition

AWS CDK for Terraform, commonly called CDKTF, is a HashiCorp framework that lets developers define Terraform-managed infrastructure using general-purpose programming languages such as TypeScript, Python, Java, C#, and Go instead of HCL. It adapts the constructs and object-oriented patterns popularized by AWS's own Cloud Development Kit to target Terraform's provider ecosystem, so the same imperative code style can provision resources across any cloud that has a Terraform provider, not only AWS.

Overview

Terraform's native configuration language, HCL, is declarative and purpose-built, but some teams prefer to express infrastructure logic using loops, conditionals, classes, and package managers native to a language they already use for application code. CDK for Terraform exists to close that gap: it lets a Python or TypeScript codebase generate Terraform's underlying JSON configuration, so the resulting plan and apply steps still run through the standard Terraform engine, state files, and provider plugins. Under the hood, CDKTF uses a code-generation step that reads a Terraform provider's schema and produces typed classes and constructs for each resource in the target language. A developer instantiates these constructs inside a stack, and at synthesis time CDKTF converts that object graph into the same JSON syntax Terraform natively understands, then hands off to the Terraform CLI for planning and applying. This means CDKTF inherits everything about Terraform's state management, locking, and provider compatibility rather than replacing it; it is a front-end language layer, not a new execution engine. CDKTF is often compared to AWS's own CDK, which it borrows its construct model from, but the two target different backends: AWS CDK synthesizes CloudFormation templates and is AWS-only, while CDKTF synthesizes Terraform configuration and can target any of Terraform's hundreds of providers, including multi-cloud and third-party services. It also differs from Pulumi, a separate infrastructure-as-code product that likewise uses general-purpose languages but runs its own execution engine and state backend rather than delegating to Terraform underneath. Teams choose CDKTF when they want to keep Terraform as their execution and state backbone, perhaps because of existing modules, provider coverage, or organizational buy-in, but want to author that configuration with the abstraction, testing, and reuse patterns of a general-purpose language, such as generating repetitive resource blocks in a loop or sharing logic through normal package imports. Constructs can be packaged and published like any software library, letting a platform team distribute pre-built infrastructure patterns to application teams. The added language layer is also a cost: debugging requires understanding both the generated Terraform plan and the source code that produced it, and the framework's synthesis step can obscure exactly which Terraform resource a piece of application code maps to. Provider coverage and construct maturity can also lag behind hand-written HCL modules for newer or less common providers. Teams that are comfortable with HCL and do not need general-purpose language features often find plain Terraform or Terraform modules simpler to reason about and maintain.

Key Features

• Defines Terraform infrastructure in TypeScript, Python, Java, C#, or Go
• Generates standard Terraform JSON configuration that runs through the normal Terraform CLI
• Auto-generates typed provider constructs from a provider's schema
• Reuses Terraform state, locking, and provider ecosystem unchanged
• Constructs can be packaged and shared as ordinary software libraries
• Supports loops, conditionals, and classes for expressing infrastructure logic
• Works with any provider Terraform itself supports

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps