Choose Terraform / OpenTofu if: You manage infrastructure across multiple clouds or SaaS providers You want the largest engineering talent pool — more engineers know HCL than Pulumi or CDK You need the most battle-tested state management and rollback behavior You're migrating from Terraform and need drop-in compatibility (choose OpenTofu) Choose Pulumi if: Your team strongly prefers writing TypeScript or Python over HCL You want unit-testable infrastructure with proper mocking You need to import

Terraform vs Pulumi vs AWS CDK 2026

TL;DR

Terraform wins for multi-cloud teams and the largest ecosystem — 3,000+ providers, a decade of battle-testing, and the most available engineers on the market. Pulumi wins for teams that want to write real programming languages — TypeScript, Python, Go, and C# with full type safety, loops, functions, and unit tests. AWS CDK wins for AWS-only shops — it compiles to CloudFormation, uses TypeScript/Python natively, and integrates deeply with AWS L2/L3 constructs that abstract away boilerplate. For greenfield AWS-only projects: CDK. For multi-cloud: Terraform. For teams that hate HCL: Pulumi.

Key Takeaways

Terraform language: HCL (HashiCorp Configuration Language) — declarative, not Turing-complete
Pulumi language: TypeScript, Python, Go, C#, Java — full programming languages
AWS CDK language: TypeScript, Python, Java, C#, Go — compiles to CloudFormation
State management: Terraform Cloud ($20/user/month); Pulumi Cloud (free/paid); CDK uses CloudFormation stacks (free)
Best multi-cloud: Terraform — 3,000+ providers covering every major cloud and SaaS
Best testing: Pulumi — native unit testing with jest/pytest/go test

Pricing Comparison

	Terraform (OpenTofu)	Pulumi	AWS CDK
Core Tool	Free (open source)	Free (open source)	Free (open source)
State Backend	Self-managed or Terraform Cloud	Self-managed or Pulumi Cloud	CloudFormation (free)
Team Plan	$20/user/month (TF Cloud)	$50/month (org plan)	N/A (use AWS console)
Enterprise	Custom	Custom	N/A
Providers/Registry	Free	Free	AWS constructs library (free)

An important note: HashiCorp changed Terraform's license from Mozilla Public License to BSL 1.1 in 2023, which triggered the creation of OpenTofu — a fully open-source, MPL-licensed fork maintained by the Linux Foundation. OpenTofu is API-compatible with Terraform and has become the default choice for organizations concerned about license restrictions. In 2026, most discussions about "Terraform" implicitly include OpenTofu as an option.

Language and Configuration

Terraform/OpenTofu uses HCL — a declarative language designed for expressing infrastructure state. HCL is readable, diffable, and purpose-built for infrastructure. Its constraints are also its strengths: you can't write loops with side effects, you can't call external APIs mid-apply, and you can't accidentally write imperative code that leaves infrastructure in a partial state.

The friction comes when you need dynamic infrastructure — generating 50 S3 buckets based on a list, building conditional resources based on environment variables, or modularizing complex patterns. HCL's for_each, count, and dynamic blocks handle these cases, but the syntax becomes verbose. Engineers who write Python or TypeScript all day find HCL's constraints frustrating.

Pulumi uses real programming languages. Your infrastructure is TypeScript, Python, Go, or C#. This means:

Import and use any npm/PyPI package in your infrastructure code
Write unit tests with jest, pytest, or go test
Use classes, inheritance, and functions to DRY up infrastructure patterns
Leverage your IDE's full type checking and autocomplete

The tradeoff: real languages mean real bugs. You can write imperative code that modifies external state, introduces race conditions, or produces different outputs on different runs. Pulumi's model requires more discipline to keep infrastructure code truly declarative.

AWS CDK uses the same languages as Pulumi (TypeScript is most popular) but compiles down to CloudFormation JSON/YAML. This means you write TypeScript to define infrastructure, but the actual deployment mechanism is CloudFormation — giving you CloudFormation's change sets, drift detection, and stack-level rollback. CDK's L2 and L3 constructs encode AWS best practices — new aws_ec2.Vpc(this, 'VPC', { maxAzs: 3 }) creates a complete multi-AZ VPC with subnets, route tables, and NAT gateways.

Ecosystem and Providers

Terraform's provider ecosystem is unmatched. The Terraform Registry hosts 3,000+ providers covering AWS, GCP, Azure, Kubernetes, Datadog, GitHub, Cloudflare, MongoDB Atlas, Snowflake, and hundreds of SaaS tools. If a platform has an API, there's likely a Terraform provider for it. This breadth is a decisive advantage for teams managing a heterogeneous stack.

Pulumi can consume any Terraform provider via the pulumi-terraform-bridge — every Terraform provider is automatically available as a Pulumi provider. This means Pulumi's effective ecosystem is roughly equivalent to Terraform's, plus native Pulumi providers that expose richer abstractions. Pulumi's AI Infrastructure platform (Pulumi AI) can generate IaC from natural language prompts, which is a genuinely useful capability for unfamiliar services.

AWS CDK is AWS-only. The CDK Constructs Library has L1 (direct CloudFormation mapping), L2 (higher-level abstractions with sensible defaults), and L3 (patterns for complete architectures). For AWS-native infrastructure, L2/L3 constructs eliminate enormous amounts of boilerplate — things that take 200 lines of Terraform HCL take 20 lines of CDK TypeScript. But the moment you need to touch GCP, Azure, or a SaaS provider, CDK has no answer.

State Management

Terraform and OpenTofu require a state backend to track what infrastructure has been deployed. Options: local file (dev only), S3 + DynamoDB (self-managed), or Terraform Cloud/Enterprise. State locking, drift detection, and plan storage are built into Terraform Cloud. For teams using OpenTofu, Spacelift, Scalr, and env0 all offer compatible state backends.

Pulumi stores state in Pulumi Cloud (default) or any backend compatible with their state API (AWS S3, Azure Blob, GCP GCS, or local). Pulumi Cloud's free tier is generous: unlimited stacks for individual use, and the dashboard shows deployment history, drift, and policy violations.

AWS CDK + CloudFormation uses CloudFormation stacks as state — no separate state backend required. CloudFormation tracks what's deployed and handles rollbacks automatically on stack update failures. This is arguably the simplest state model: AWS manages it entirely, it's free, and it integrates with AWS Organizations, CloudTrail, and Config for compliance.

Testing Infrastructure

Pulumi has the best testing story. Because your infrastructure is real code, you can write unit tests that mock cloud provider calls and assert on the resource tree — no cloud credentials required. Integration tests can deploy to a real (throwaway) environment and assert on outputs. The same test frameworks developers already know (jest, pytest) apply directly.

CDK supports unit testing via the aws-cdk-lib/assertions module. You can test that a synthesized CloudFormation template contains expected resources and properties. Since CDK compiles to CloudFormation JSON, assertions are deterministic and fast. This is more limited than Pulumi's mocking approach but sufficient for most teams.

Terraform has terraform validate (syntax), terraform plan (dry-run), and third-party tools like Terratest (Go-based integration testing) and tftest (Python). Testing is an afterthought in Terraform's design — Terratest requires writing Go even if your team doesn't use Go, and the tests actually deploy infrastructure rather than mocking it.

When to Use Which

Choose Terraform / OpenTofu if:

You manage infrastructure across multiple clouds or SaaS providers
You want the largest engineering talent pool — more engineers know HCL than Pulumi or CDK
You need the most battle-tested state management and rollback behavior
You're migrating from Terraform and need drop-in compatibility (choose OpenTofu)

Choose Pulumi if:

Your team strongly prefers writing TypeScript or Python over HCL
You want unit-testable infrastructure with proper mocking
You need to import npm/PyPI libraries directly in your infra code
You're comfortable managing the imperative-vs-declarative discipline tradeoff

Choose AWS CDK if:

You deploy exclusively to AWS and want the highest-level abstractions
You want CloudFormation's change sets, drift detection, and rollback without writing CF YAML
Your team uses TypeScript and wants first-class L2/L3 constructs for ECS, Lambda, RDS, etc.
You want state management handled entirely by AWS at no additional cost

The SaaS Tool Evaluation Guide (Free PDF)