Every team starting a cloud infrastructure project today asks the same question: Terraform, Pulumi, or CDK?
The answer is not about which tool is technically superior. It is about which one your team will actually maintain six months from now. Here is the practical breakdown.
What All Three Do
All three tools let you describe cloud infrastructure in code, store that code in a version control system, review changes before applying them, and detect drift between what is deployed and what is in code.
That shared baseline matters. Any of the three is a better choice than clicking through the AWS console.
The differences are in syntax, language, and workflow.
Terraform
Language: HCL (HashiCorp Configuration Language) State: Remote state in S3, GCS, or Terraform Cloud Provider coverage: Widest of any IaC tool - 3,000+ providers
Terraform is the industry default for a reason. The HCL syntax is declarative and readable. The provider ecosystem covers every cloud service, every SaaS API, every DNS provider. If you need to provision it, there is a Terraform provider for it.
When to use Terraform:
- •Multi-cloud environments (AWS + GCP + Cloudflare + Datadog in one codebase)
- •Teams where not everyone writes Python or TypeScript
- •Infrastructure managed separately from application code
- •When you want maximum hiring flexibility - Terraform experience is common
Real limitations:
- •HCL is not a real programming language. No loops with complex logic, no type safety, limited reuse patterns
- •State file management is a source of real operational friction, especially for large teams
- •Testing infrastructure changes requires
terraform planreading skills - not intuitive for developers who do not work in infra daily
Our take: Terraform is the right default for most teams under 50 engineers. The hiring pool is deep, the documentation is excellent, and the provider coverage is unmatched.
Pulumi
Language: TypeScript, Python, Go, C#, Java - your choice State: Pulumi Cloud (free tier available) or self-hosted Provider coverage: Built on top of Terraform providers - nearly identical coverage
Pulumi lets you write infrastructure in the same language your application uses. A TypeScript shop writes infrastructure in TypeScript. Real for loops. Real type safety. Real functions and classes. No HCL.
When to use Pulumi:
- •Teams with strong TypeScript or Python skills who find HCL limiting
- •Complex infrastructure with conditional logic, loops, or dynamic resource generation
- •When you want infrastructure and application code in the same repo with shared utilities
- •Startups where developers own infrastructure - not dedicated ops teams
Real limitations:
- •The Pulumi Cloud state backend has a cost at scale ($2/resource/month above the free tier)
- •Hiring is harder - Pulumi experience is less common than Terraform experience
- •Debugging failures requires understanding both your language runtime and Pulumi internals
Our take: Pulumi is the right choice for teams that find Terraform's expressiveness limiting. TypeScript infrastructure code that imports from your shared utilities library is genuinely more maintainable than HCL with workarounds.
AWS CDK
Language: TypeScript, Python, Java, C# State: Managed by CloudFormation - no separate state file Provider coverage: AWS only (there is CDK for Terraform, but that is a different product)
CDK generates CloudFormation templates. You write TypeScript or Python, CDK compiles it to CloudFormation JSON, and CloudFormation handles the deployment. The state is managed by CloudFormation stacks - no Terraform Cloud or Pulumi Cloud required.
When to use CDK:
- •AWS-only infrastructure (no multi-cloud, no Cloudflare, no third-party providers)
- •Teams deeply familiar with CloudFormation who want a better authoring experience
- •When CloudFormation's rollback behavior is important to you
Real limitations:
- •AWS-only. The moment you need to manage a Cloudflare DNS record or a Datadog monitor, you are out of scope
- •CloudFormation stack limits (500 resources per stack) create architectural constraints
- •CDK's abstractions (Constructs) are powerful but have a steep learning curve
- •Deployment speed is limited by CloudFormation - slower than Pulumi or Terraform for large stacks
Our take: CDK makes sense for teams already invested in CloudFormation who want to stop writing YAML by hand. For new infrastructure projects on AWS, Terraform or Pulumi is usually the better long-term choice due to flexibility.
The Decision Framework
| Terraform | Pulumi | CDK | |
|---|---|---|---|
| Multi-cloud | Yes | Yes | No |
| Real language | No (HCL) | Yes | Yes |
| Hiring pool | Large | Smaller | Medium |
| State management | Manual | Pulumi Cloud | CloudFormation |
| Best for | Most teams | Dev-heavy teams | AWS-only shops |
Start with Terraform if you are building your first production infrastructure and do not have strong IaC opinions on your team.
Switch to Pulumi if you find yourself fighting HCL's limitations - complex conditionals, repeated patterns that need real abstractions, or a team where everyone already writes TypeScript.
Use CDK if you are AWS-only, already have CloudFormation investment, and want your developers to write infrastructure in TypeScript without learning a new tool.
One Practical Recommendation
Whatever tool you pick: use remote state from day one. Terraform state in a local file, checked into git, is a team scaling problem waiting to happen.
For Terraform, that means S3 + DynamoDB for state and locking. For Pulumi, that means Pulumi Cloud or a self-hosted backend. For CDK, CloudFormation handles this automatically.
We work with all three tools depending on what a client already has in place. If you are unsure which to start with, book a free 30-minute call and we will give you a straight answer based on your team and stack.