Same issue: migrating to Control Tower requires CloudFormation. Existing infrastructure is Terraform. I've built a command-line tool that converts Terraform configurations to native AWS CDK code.Same issue: migrating to Control Tower requires CloudFormation. Existing infrastructure is Terraform. I've built a command-line tool that converts Terraform configurations to native AWS CDK code.

Tf2cdk – Convert Terraform to AWS CDK (Not Cdktf)

2025/11/06 13:05

Hey HN! I built tf2cdk - a CLI that converts Terraform configurations to native AWS CDK code.

GitHub: https://github.com/jtaylortech/tf2cdk

Important: This is NOT cdktf

cdktf (CDK for Terraform):

  • Write CDK code that generates Terraform
  • Outputs HCL, uses Terraform state
  • For teams who want CDK's programming model with Terraform's engine

tf2cdk (this project):

  • Converts existing Terraform TO native CDK
  • Outputs CDK code, uses CloudFormation stacks
  • For teams migrating OFF Terraform entirely

Different problems. Not competitors.

The Problem

I've worked with multiple organizations migrating to AWS Control Tower. Every time, same issue:

Control Tower requires CloudFormation. Existing infrastructure is Terraform. Manual conversion takes 2-4 months for large codebases.

This also happens with:

  • Landing Zone Accelerator (LZA) - CloudFormation only
  • AWS Service Catalog - Native CloudFormation integration
  • Terraform licensing concerns - Teams want to eliminate Terraform entirely

How It Works

tf2cdk is a Python CLI that:

  1. Parses HCL - Uses python-hcl2 to parse Terraform files
  2. Maps resources - 30+ Terraform resources → CDK constructs
  3. Generates code - Idiomatic TypeScript or Python
  4. Validates - Type-safe with comprehensive error handling

tf2cdk convert ./terraform --output ./cdk-app --language typescript

All generated code lives in the output directory. You can inspect/modify it.

Example

Input (Terraform):

resource "aws_s3_bucket" "data" { bucket = "my-data-bucket" tags = { Environment = "production" } } resource "aws_s3_bucket_versioning" "data" { bucket = aws_s3_bucket.data.id versioning_configuration { status = "Enabled" } }

Output (CDK TypeScript):

import * as cdk from 'aws-cdk-lib'; import * as s3 from 'aws-cdk-lib/aws-s3'; export class InfrastructureStack extends cdk.Stack { constructor(scope: cdk.App, id: string, props?: cdk.StackProps) { super(scope, id, props); const data = new s3.Bucket(this, 'Data', { bucketName: 'my-data-bucket', versioned: true, tags: { Environment: 'production' }, }); } }

Notice how it:

  • Merges aws_s3_bucket_versioning into the bucket (CDK pattern)
  • Converts snake_case to camelCase
  • Generates clean, idiomatic code

Technical Details

Architecture:

Terraform HCL ↓ (python-hcl2) Parsed Config ↓ (Resource Mapper) CDK Model ↓ (Code Generator) TypeScript/Python

Resource Mappings:

RESOURCE_MAPPINGS = { 'aws_s3_bucket': { 'cdk_class': 's3.Bucket', 'module': 'aws-cdk-lib/aws-s3', 'props': {'bucket': 'bucketName', 'tags': 'tags'} }, # 30+ more... }

Error Handling:

  • Validates source files exist
  • Catches HCL parse errors with helpful tips
  • Warns about unsupported resources
  • Shows conversion progress
  • Proper exit codes for automation

Testing:

  • 28 tests (parser, converter, generator, CLI, edge cases)
  • Tests empty configs, unsupported resources, complex props
  • CLI integration tests for all commands
  • All tests passing

Supported Resources (30+)

Compute: EC2, Lambda, ECS, Auto Scaling Storage: S3, EBS, EFS Database: RDS, DynamoDB, ElastiCache Network: VPC, Subnet, Security Groups, Route53, ALB/NLB Security: IAM, KMS, Secrets Manager Monitoring: CloudWatch, SNS, SQS

Community contributions welcome for additional resources.

Special Patterns

# Control Tower account factory structure tf2cdk convert ./terraform --pattern control-tower # Landing Zone Accelerator format tf2cdk convert ./terraform --pattern lza # GovCloud compliance annotations tf2cdk convert ./terraform --pattern govcloud

Why Open Source?

Terraform→CDK conversion is a one-time migration problem. You need it once, then you're done.

Making it free and open source:

  • Maximizes adoption
  • Gets community contributions (more resource mappings)
  • Helps the entire AWS community
  • Builds credibility

For large migrations needing implementation services, those are available separately. But the tool itself is free forever (MIT License).

Limitations

  • Complex Terraform expressions may need manual adjustment
  • Custom providers need manual mapping configuration
  • State migration is guided, not fully automated
  • Some Terraform-specific features (provisioners) have no CDK equivalent

Roadmap

v0.1.0 (current): 30+ resources, TypeScript/Python, basic patterns v0.2.0: 50+ resources, state import planning, more patterns v0.3.0: 100+ resources, module conversion, advanced expressions v1.0.0: Comprehensive resource coverage, GUI (optional)

Try It

# Homebrew brew tap jtaylortech/tf2cdk brew install tf2cdk # pip pip install tf2cdk # Convert tf2cdk convert ./terraform --output ./cdk-app --dry-run

Feedback Wanted

  • What Terraform resources are you using that aren't supported?
  • What patterns would help (multi-account, multi-region, etc.)?
  • What's your Terraform→CDK migration pain point?
  • Documentation gaps?

All code is on GitHub, MIT licensed. Issues and PRs welcome.


Related: If you're looking for CDK→Terraform (opposite direction), check out cdktf from HashiCorp. Different use case, both tools are useful.

Disclaimer: The articles reposted on this site are sourced from public platforms and are provided for informational purposes only. They do not necessarily reflect the views of MEXC. All rights remain with the original authors. If you believe any content infringes on third-party rights, please contact [email protected] for removal. MEXC makes no guarantees regarding the accuracy, completeness, or timeliness of the content and is not responsible for any actions taken based on the information provided. The content does not constitute financial, legal, or other professional advice, nor should it be considered a recommendation or endorsement by MEXC.

You May Also Like

Mt. Gox moves $936M in Bitcoin after eight-month dormancy

Mt. Gox moves $936M in Bitcoin after eight-month dormancy

The post Mt. Gox moves $936M in Bitcoin after eight-month dormancy appeared on BitcoinEthereumNews.com. Key Takeaways Mt. Gox moved $936 million in Bitcoin after eight months of inactivity. The movement relates to the exchange’s ongoing court-supervised creditor repayment process. Mt. Gox, the defunct crypto exchange, moved $936 million worth of Bitcoin today after remaining dormant for eight months. The transfer involved shifting Bitcoin to a new wallet address, marking the first significant activity from the exchange’s holdings since March. The movement comes as Mt. Gox continues its court-supervised creditor repayment process. The rehabilitation trustee has extended the deadline for creditor reimbursements to allow more time for managing Bitcoin distributions. Mt. Gox has been gradually shifting Bitcoin to new addresses as part of its ongoing efforts to repay creditors. The exchange collapsed in 2014 following a massive hack that resulted in the loss of around 850,000 Bitcoin. The latest wallet activity suggests preparations may be underway for additional creditor payments, though the exchange has not disclosed specific timelines for distributions. Mt. Gox began returning funds to creditors in 2024 after years of legal proceedings. This is a developing story. Source: https://cryptobriefing.com/mt-gox-moves-936m-in-bitcoin-after-eight-month-dormancy/
Share
BitcoinEthereumNews2025/11/18 12:58