Terraform vs CDK — Infrastructure as Code or Infrastructure as Software?
Terraform's declarative simplicity beats CDK's code-first complexity for most teams, unless you're already drowning in AWS.
The short answer
Terraform over terraform for most cases. Terraform's state management and multi-cloud support are non-negotiable for serious infrastructure.
- Pick terraform if need multi-cloud support or want reliable change planning without deploying first
- Pick cdk if an AWS-only shop with developers who prefer writing code over config files
- Also consider: Pulumi—if you want CDK's code-first approach but with multi-cloud support and better state management.
— Nice Pick, opinionated tool recommendations
Two Philosophies, One Goal: Declarative vs. Imperative
Terraform and CDK aren't just competing tools—they're competing ideologies. Terraform says, "Tell me what you want, I'll figure out how to get there." CDK says, "Write code to describe what you want, and I'll turn it into CloudFormation." Terraform's HashiCorp Configuration Language (HCL) is purpose-built for infrastructure, while CDK lets you use TypeScript, Python, or other languages to generate AWS CloudFormation templates. This isn't a minor difference—it's the core of why one will save you time and the other might cost you sanity.
Where Terraform Wins
Terraform's state file is its killer feature. It knows exactly what you've deployed and can plan changes before applying them, preventing accidental deletions. It supports over 3,000 providers, including AWS, Azure, Google Cloud, and even GitHub or Datadog. Pricing? Free for the open-source version, with Terraform Cloud starting at $20/user/month for teams. Compare that to CDK, which is free but locks you into AWS—good luck using it for that Azure VM or Google Kubernetes cluster. Terraform's plan command shows you a diff of changes, something CDK can't do without deploying and hoping CloudFormation doesn't fail.
Where CDK Holds Its Own
If you're an AWS shop with developers who live in IDEs, CDK's code-first approach feels natural. You can use loops, conditionals, and object-oriented patterns that HCL struggles with. The AWS Construct Library provides high-level abstractions—like new ec2.Instance—that reduce boilerplate. For teams already using CloudFormation, CDK is a logical upgrade because it generates CloudFormation templates you can audit. It's also free, with no per-user fees, making it attractive for startups drowning in AWS bills but not yet ready for multi-cloud.
The Gotcha: Debugging and Lock-In
CDK's biggest surprise? You're not writing infrastructure—you're writing code that generates CloudFormation. When something breaks, you're debugging a generated JSON/YAML file that's thousands of lines long. Terraform's state file can be a single point of failure, but at least it's yours to manage. CDK locks you into AWS; try using it for that on-premises Kubernetes cluster and you'll be rewriting everything. Switching from CDK to Terraform means redefining all your resources in HCL—a migration project no one wants.
If You're Starting Today...
Pick Terraform unless you meet all these criteria: 1) You're 100% committed to AWS for the next 3 years, 2) Your team prefers writing TypeScript over YAML/HCL, and 3) You're okay with CloudFormation's 90-minute rollback failures. For everyone else, Terraform's multi-cloud flexibility and planning capability are worth the slight learning curve of HCL. Start with the free tier, use remote state in S3, and upgrade to Terraform Cloud when you hit team collaboration issues.
What Most Comparisons Get Wrong
They treat this as a features checklist, ignoring the operational overhead. CDK's "it's just code" sounds great until you're managing CDK constructs that change with every AWS SDK update. Terraform's providers are versioned independently, so you can pin that AWS provider to avoid breaking changes. Also, everyone mentions CDK's "abstraction" but forgets that CloudFormation's limits (like 500 resources per stack) still apply. Terraform doesn't have that problem—it's just managing resources, not generating stacks within stacks.
Quick Comparison
| Factor | terraform | cdk |
|---|---|---|
| Pricing | Free open-source; Terraform Cloud from $20/user/month | Free (AWS account required) |
| Cloud Support | 3,000+ providers (AWS, Azure, GCP, etc.) | AWS only |
| Language | HashiCorp Configuration Language (HCL) | TypeScript, Python, Java, etc. |
| State Management | Built-in state file with planning | Relies on AWS CloudFormation |
| Learning Curve | Moderate (HCL syntax) | Steep (requires programming + AWS knowledge) |
| Change Preview | `terraform plan` shows exact changes | No built-in preview; deploy to see |
| Resource Limits | None (handles large deployments) | Inherits CloudFormation limits (e.g., 500 resources/stack) |
| Community Modules | Terraform Registry with 1,000+ modules | AWS Construct Library (AWS-specific) |
The Verdict
Use terraform if: You need multi-cloud support or want reliable change planning without deploying first.
Use cdk if: You're an AWS-only shop with developers who prefer writing code over config files.
Consider: Pulumi—if you want CDK's code-first approach but with multi-cloud support and better state management.
Terraform's state management and multi-cloud support are non-negotiable for serious infrastructure. CDK's abstraction layers often leak, leaving you debugging generated CloudFormation instead of building.
Related Comparisons
Disagree? nice@nicepick.dev