Infrastructure as Code: Terraform vs Pulumi vs OpenTofu vs CDK

Manually clicking through cloud consoles to create infrastructure is unsustainable. It is slow, error-prone, undocumented, and impossible to reproduce. Infrastructure as Code (IaC) tools solve this by defining infrastructure in configuration files that can be version-controlled, reviewed, tested, and applied consistently.

The IaC landscape has shifted significantly in the past two years. HashiCorp changed Terraform's license from open source to BSL, spawning OpenTofu as a fork. Pulumi has matured into a serious alternative. AWS CDK has evolved beyond an AWS-only tool. Choosing the right IaC tool now requires understanding not just features but also licensing and community dynamics.

Terraform

Terraform remains the most widely adopted IaC tool. According to HashiCorp, Terraform manages infrastructure across 3,000+ providers using a declarative configuration language called HCL (HashiCorp Configuration Language).

Strengths

• Massive provider ecosystem: Providers for every major cloud (AWS, GCP, Azure), plus hundreds of SaaS platforms (Datadog, PagerDuty, GitHub, Cloudflare)
• Mature and battle-tested: Years of production use across thousands of organizations
• Plan before apply: terraform plan shows exactly what changes will be made before execution
• State management: Clear model for tracking what infrastructure exists and computing diffs
• Module system: Reusable modules for common infrastructure patterns, with a public registry
• Extensive documentation: Both official docs and community content are comprehensive
• Terraform Cloud: Managed state, remote execution, policy enforcement, and collaboration features

Limitations

• BSL license: As of Terraform 1.6, Terraform uses the Business Source License. You can use it freely, but competitors cannot offer a competing hosted service based on it
• HCL limitations: HCL is not a general-purpose language. Complex logic (loops, conditionals, dynamic configurations) can become awkward
• State file management: The state file is a single point of failure. Corruption or drift requires careful recovery
• No built-in testing: Testing Terraform configurations requires external tools (Terratest, tftest)
• Drift detection is manual: Terraform does not automatically detect when someone changes infrastructure outside of Terraform

Best for: Teams wanting the largest provider ecosystem and the most community resources.

Pricing: Open source (BSL). Terraform Cloud free tier available. Team plans from $20/user/month.

OpenTofu

OpenTofu is a community fork of Terraform created in response to the BSL license change. Managed by the Linux Foundation, OpenTofu aims to maintain an MPL-licensed (truly open source) alternative that is compatible with Terraform.

Strengths

• Open source (MPL): Genuinely open source with community governance
• Terraform compatibility: Drop-in replacement for Terraform. Existing configurations work with minimal or no changes
• State encryption: OpenTofu added state encryption, a feature Terraform lacks in the open-source version. This encrypts sensitive data in state files at rest
• Active development: The community has added features beyond Terraform, including early-variable evaluation and provider-defined functions
• Linux Foundation governance: Vendor-neutral governance reduces the risk of future license changes

Limitations

• Diverging from Terraform: As both tools evolve independently, compatibility gaps will grow
• Younger ecosystem: Fewer tutorials, blog posts, and Stack Overflow answers compared to Terraform
• Provider compatibility: While most Terraform providers work, some HashiCorp-specific features may not be supported long-term
• Commercial ecosystem: Fewer managed services and enterprise support options than Terraform

Best for: Teams that want Terraform's capabilities without the BSL license, and organizations with open-source policies.

Pricing: Free and open source.

Pulumi

Pulumi takes a different approach — instead of a domain-specific language like HCL, you define infrastructure using general-purpose programming languages: TypeScript, Python, Go, C#, Java, or YAML.

Strengths

• Real programming languages: Use loops, functions, classes, conditionals, and abstractions from languages you already know
• Type safety: TypeScript and other typed languages provide compile-time error checking for your infrastructure code
• Testing: Write unit tests for your infrastructure using standard testing frameworks (Jest, pytest, Go testing)
• Component model: Create reusable infrastructure components using the same abstraction mechanisms as your application code (classes, packages)
• Multi-cloud support: Providers for AWS, GCP, Azure, Kubernetes, and many SaaS platforms
• Pulumi AI: Generate infrastructure code from natural language descriptions
• State management: Managed state backend (Pulumi Cloud) or self-managed backends (S3, Azure Blob, GCS)

Limitations

• Imperative feel: Writing infrastructure in a programming language can lead to imperative patterns that are harder to reason about than declarative HCL
• Smaller provider ecosystem: While growing, the provider catalog is smaller than Terraform's. Many Pulumi providers are auto-generated from Terraform providers (via the Pulumi-Terraform bridge)
• Learning curve for IaC newcomers: If you are new to IaC, learning infrastructure concepts while using a full programming language can be overwhelming
• State conversion: Migrating from Terraform to Pulumi requires converting state, which is nontrivial for large infrastructure

Best for: Development teams that want infrastructure code in the same languages as their application code, with testing and type safety.

Pricing: Free tier (individual). Team at $50/month. Business at $225/month. Enterprise pricing available.

AWS CDK

AWS CDK (Cloud Development Kit) lets you define AWS infrastructure using TypeScript, Python, Java, C#, or Go. It synthesizes CloudFormation templates from your code.

Strengths

• Deep AWS integration: CDK constructs are purpose-built for AWS services with sensible defaults and best practices baked in
• L1, L2, L3 constructs: Low-level (1:1 CloudFormation mapping), high-level (opinionated defaults), and pattern-level (complete architectures) abstractions
• Construct Hub: Public library of community-contributed constructs for common patterns
• CloudFormation foundation: CDK synthesizes to CloudFormation, which handles state management, rollback, and drift detection
• No separate state file: CloudFormation manages state server-side, eliminating state file management headaches

Limitations

• AWS only: CDK is designed for AWS. CDK for Terraform (CDKTF) extends the concept to other providers but is a separate tool
• CloudFormation limitations: CDK inherits CloudFormation's limitations — 500 resource limit per stack, sometimes slow deployments, and CloudFormation-specific error messages
• Synthesis step: The extra cdk synth step between your code and deployment adds complexity
• Drift between CDK and CloudFormation: Sometimes understanding what CDK generates requires reading CloudFormation, adding cognitive overhead

Best for: Teams fully committed to AWS that want high-level abstractions with managed state.

Pricing: Free. CloudFormation itself is free (you pay for the resources it creates).

Other Notable Options

Crossplane

Crossplane manages infrastructure using Kubernetes custom resources. If your team already thinks in Kubernetes, Crossplane lets you manage cloud resources using kubectl and Kubernetes manifests.

Best for: Platform teams building internal developer platforms on Kubernetes.

SST (Serverless Stack)

SST provides a modern framework for building serverless applications on AWS, with infrastructure defined in TypeScript. It focuses on the developer experience of building and deploying serverless apps rather than general-purpose infrastructure.

Best for: Teams building serverless applications on AWS.

Ansible

Ansible handles configuration management and application deployment rather than infrastructure provisioning. While it can create cloud resources, it is better suited for configuring servers, deploying applications, and managing operational tasks.

Best for: Server configuration and application deployment (often used alongside Terraform for provisioning).

Decision Framework

Choose Terraform if:

• You need the largest provider ecosystem
• Your team is comfortable with HCL
• You want the most community resources and hiring pool
• The BSL license is acceptable for your use case

Choose OpenTofu if:

• You need Terraform compatibility with a truly open-source license
• State encryption is important
• Your organization has open-source policies that preclude BSL software

Choose Pulumi if:

• Your team prefers writing infrastructure in a general-purpose language
• Type safety and unit testing for infrastructure are priorities
• You want to use the same language for application and infrastructure code

Choose AWS CDK if:

• You are exclusively on AWS
• You want high-level constructs with best practices built in
• You prefer managed state (via CloudFormation) over self-managed state files

Migration Considerations

Switching IaC tools is not trivial. Key considerations:

• State migration: Moving infrastructure state between tools requires careful planning. Tools like pulumi import and terraform import help but are not seamless for large estates
• Team retraining: Each tool has its own concepts, patterns, and best practices
• CI/CD pipeline changes: Your deployment pipelines need updating for the new tool
• Module/component migration: Rewriting reusable modules in the new tool's format

For most teams, the pragmatic choice is to use the new tool for new infrastructure and migrate existing infrastructure gradually rather than attempting a big-bang migration.

The IaC tool you choose matters less than the practice of defining infrastructure as code. Any of these tools is vastly better than manual cloud console operations. Pick the one that matches your team's skills and constraints, and invest in the practice.