Terraform vs CloudFormation vs CDK vs Pulumi: Which IaC Tool for AWS?
Choosing an Infrastructure as Code tool for AWS #
All of these tools do the same job: they create and update cloud resources from code (Infrastructure as Code). They differ in language, how they keep state, and how well they work beyond AWS.
Quick comparison #
| Terraform / OpenTofu | CloudFormation | AWS CDK | Pulumi | |
|---|---|---|---|---|
| Language | HCL (declarative) | JSON or YAML | TypeScript, Python, Java, C#, Go | TypeScript, Python, Go, C#, Java, YAML |
| Clouds | Any, via providers | AWS only | AWS (CDK for Terraform for others) | Any |
| State | State file you manage in a backend | Managed by AWS (stacks) | Managed by CloudFormation | Pulumi Cloud or self-managed backend |
| Preview of changes | plan |
Change sets | cdk diff and change sets |
pulumi preview |
| Rollback on failure | No automatic rollback, you fix and re-apply | Automatic rollback | Same as CloudFormation | No automatic rollback |
| Drift detection | plan |
Drift detection feature | Same as CloudFormation | refresh |
| New AWS features | Provider release, usually days to weeks | Often on day one | Day one at L1 level, later at higher levels | Based on Terraform providers or native |
| License | OpenTofu MPL 2.0, Terraform BSL | Proprietary service | Apache 2.0 | Apache 2.0 |
| Cost | Free tool, optional platforms | Free | Free | Free tool, paid cloud features |
Terraform and OpenTofu #
Strengths: a huge provider ecosystem (AWS, Azure, GCP, Kubernetes, Cloudflare, Datadog, GitHub), one language for everything, a large community, and a clear plan. Good for teams that use more than one platform or service. See Terraform vs OpenTofu.
Weaknesses: you operate the state, and there is no automatic rollback. HCL is limited when you need complex logic.
CloudFormation #
Strengths: native to AWS, state and locking managed for you, rollbacks, deep integration with AWS Organizations StackSets, Service Catalog and Control Tower, and support for new services early. No extra tool or state bucket. See CloudFormation.
Weaknesses: verbose YAML or JSON, AWS only, and stack operations can be slow and sometimes get stuck in a failed state.
AWS CDK #
Strengths: write infrastructure in a general-purpose language with loops, classes and tests, and get high-level constructs that create sensible defaults (an entire VPC or an ECS service in a few lines). It synthesizes CloudFormation templates.
Weaknesses: AWS only, you still debug CloudFormation underneath, and the abstraction can hide what is created. Developers like it, platform teams are sometimes more cautious.
Pulumi #
Strengths: real programming languages across clouds, with a state model like Terraform. A good fit when developers own the infrastructure and want to share code with applications.
Weaknesses: a smaller ecosystem and community than Terraform, and a language runtime in your pipeline.
How to choose #
| Situation | Suggestion |
|---|---|
| Multi-cloud or many SaaS providers | Terraform or OpenTofu |
| AWS only and you want the least tooling | CloudFormation |
| AWS only and developers prefer code | CDK |
| You need an open-source license | OpenTofu, CDK or Pulumi |
| Large Terraform skill base and hiring market | Terraform or OpenTofu |
| Complex logic and unit testing with a normal language | CDK or Pulumi |
Combining tools #
They are not exclusive. A common setup: Terraform for the cloud foundation (accounts, network, IAM) and CDK or CloudFormation for applications, or Terraform managing CloudFormation stacks with aws_cloudformation_stack during a migration. Choose one per layer and avoid two tools managing the same resource.
Learning path #
If you start from scratch and expect to work in more than one cloud, learn HCL: it is the most requested skill. Follow the AWS with Terraform series, the Terraform cheat sheet and the best practices. For job preparation see the interview questions.
To move an existing setup, see import (adopt resources created by CloudFormation or by hand) and migrating to OpenTofu.