How to convert Terraform to AWS CDK in TypeScript
- Add your codePaste it into the Terraform (HCL) editor, drag in a file, or keep the sample to see how it works.
- Convert to CDKClick the button or press Ctrl + Enter. The result streams into the right-hand editor.
- Review and use itCopy or download the result, then test it before you rely on it. AI output is a strong first draft, not a guarantee.
How Terraform maps to AWS CDK
Terraform describes infrastructure in HCL and tracks it in its own state file. AWS CDK describes it in a programming language and synthesizes a CloudFormation template that CloudFormation deploys. The converter maps each resource block to a matching CDK construct, turns references such as aws_s3_bucket.uploads.id into object properties, and rewrites jsonencode() policies as TypeScript objects.
The result is rarely a line-for-line copy. CDK's higher-level L2 constructs bundle related settings: new s3.Bucket(this, "Uploads", { versioned: true }) replaces a bucket plus a separate aws_s3_bucket_versioning resource, and bucket.grantRead(fn) writes the IAM policy for you. L2 constructs also apply their own defaults, so compare the synthesized template (cdk synth) with what Terraform manages today.
Converting the code doesn't move your infrastructure. Resources Terraform created stay in Terraform state until you move them, and the CDK stack starts empty.
Deploying the converted stack as-is tries to create new copies of your resources, and fails for anything with a fixed name, such as an S3 bucket. Bring existing resources in with cdk import, remove them from Terraform state, and check cdk diff before every deploy.
Tips for better results
- Include the provider and variable blocks. The region and variable defaults tell the converter which values to hard-code and which to expose as stack props.
- Convert one module at a time. Each Terraform module usually maps well to its own CDK construct or stack.
- Registry modules can't be expanded. The converter only sees the code you paste, so a
module "vpc" { source = "terraform-aws-modules/vpc/aws" }call won't become a full VPC. Replace it with the equivalent CDK construct, such asec2.Vpc. - Swap zip files for assets. Lambda
filenamearchives becomelambda.Code.fromAsset()pointing at your source folder, and CDK zips it at deploy time. - Check the IAM output. Where the converter uses
grant*methods, runcdk synthto see the exact actions they allow.
Frequently asked questions
Does the converter migrate my Terraform state?
No. It converts code only. Your resources stay in Terraform state, and a new CDK stack would try to create them again. Import existing resources into the CDK stack with cdk import or CloudFormation resource import, then remove them from Terraform state with terraform state rm.
Will the CDK stack create exactly the same resources?
Close, but not always identical. L2 constructs add sensible extras: a lambda.Function creates its own execution role unless you pass one, and enforceSSL: true on a bucket adds a bucket policy. Compare cdk synth output with your Terraform resources before switching over.
Which version of AWS CDK does the output use?
It should use AWS CDK v2, where everything is imported from aws-cdk-lib and Construct comes from the constructs package. If the output imports from @aws-cdk/core or other @aws-cdk/aws-* packages, that's CDK v1 syntax. CDK v1 reached end-of-support on June 1, 2023, so switch those imports to aws-cdk-lib.
Can I keep using Terraform for some resources?
Yes. Many teams migrate stack by stack. Pass values between the two with SSM parameters or stack outputs until everything has moved.