ChatWithCloud
Get started

Terraform to AWS CDK (Python) Converter

Rewrite Terraform HCL as an AWS CDK v2 stack in Python, with aws_cdk constructs and Python-style snake_case properties.

Reverse: AWS CDK → TerraformAll tools
Your codeTerraform (HCL)
Drop the file to load it
Tab indents · Esc, Tab exits
ResultAWS CDK (Python)
Your AWS CDK (Python) will appear hereClick Convert to CDK or press Ctrl Enter
stack.py
Don't paste secrets

How to convert Terraform to AWS CDK in Python

  1. Add your codePaste it into the Terraform (HCL) editor, drag in a file, or keep the sample to see how it works.
  2. Convert to CDKClick the button or press Ctrl + Enter. The result streams into the right-hand editor.
  3. 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.

From HCL blocks to Python constructs

In a Python CDK app, each Terraform resource becomes a construct instantiated with self as its scope, for example sqs.Queue(self, "Orders", visibility_timeout=Duration.seconds(60)). Attribute references like aws_sqs_queue.orders_dlq.arn become Python attributes such as dlq.queue_arn, and nested blocks become keyword arguments or small property objects.

Some Terraform patterns fold into a single construct option. An SQS redrive policy becomes dead_letter_queue=sqs.DeadLetterQueue(max_receive_count=5, queue=dlq), and a DynamoDB point_in_time_recovery block becomes a table property. Because CDK synthesizes to CloudFormation, the deployed resources can differ slightly from Terraform's. Check cdk synth before you rely on the result.

To run the output, create a CDK app with cdk init app --language python, install aws-cdk-lib and constructs in the virtual environment, and add the stack to app.py. AWS's guide to working with CDK in Python covers the setup.

The converted code manages new resources. It doesn't take over the ones Terraform already created. Use cdk import for resources you want to keep, and always run cdk diff before deploying.

Tips for better results

  • Watch the reserved words. lambda is a Python keyword, so CDK code imports the module as aws_lambda as lambda_.
  • Keep names stable. If you set explicit names like queue_name="orders", CloudFormation can't replace the resource without deleting it first. Leave names out where you can.
  • Convert related resources together. A queue and its dead-letter queue, or a table and its stream consumer, convert better in one paste than separately.
  • Use a virtual environment. Pin aws-cdk-lib in requirements.txt so the app synthesizes the same way on every machine.
  • Run cdk synth first. It catches wrong property names quickly, before anything is deployed.

Frequently asked questions

Does converting Terraform to CDK move my existing resources?

No. The converter changes code, not infrastructure. Existing resources stay in Terraform state. To manage them from CDK, import them with cdk import or CloudFormation resource import, then remove them from Terraform with terraform state rm.

Why does the Python code use snake_case?

The CDK is written in TypeScript and published to Python through jsii, which translates property names to Python conventions. visibilityTimeout in TypeScript is visibility_timeout in Python, and the classes are the same.

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.

How do I pass Terraform variables into the CDK app?

Common options are constructor arguments on your stack class, CDK context values in cdk.json, or environment variables read in app.py. The converter usually turns variables with defaults into stack parameters or constants you can adjust.