Why Infrastructure as Code Matters More Than Ever
Infrastructure as Code is no longer optional. According to HashiCorp's 2025 State of Cloud Strategy Survey, 78% of organisations with mature cloud practices now manage infrastructure entirely through code. The remaining 22% report 3.5x more configuration drift incidents, 2x longer mean-time-to-recovery, and significantly higher audit costs.
The question is no longer whether to adopt IaC — it is which tool to choose. Terraform, Pulumi, and AWS CDK have emerged as the three dominant options, each with distinct design philosophies. This comparison is based on our hands-on experience deploying all three across European enterprises.
The Three Contenders at a Glance
| Feature | Terraform | Pulumi | AWS CDK |
|---|---|---|---|
| Language | HCL (domain-specific) | TypeScript, Python, Go, C#, Java | TypeScript, Python, Java, C#, Go |
| Multi-Cloud | Excellent (3,000+ providers) | Good (100+ providers) | AWS only (+ limited multi via CDKTF) |
| State Management | Remote backends (S3, Terraform Cloud) | Pulumi Cloud or self-managed | CloudFormation stacks |
| Licence | BSL 1.1 (since Aug 2023) / OpenTofu fork | Apache 2.0 | Apache 2.0 |
| Learning Curve | Moderate (new language) | Low for developers | Low for AWS-focused teams |
| Testing Support | Terratest, terraform test | Native unit testing in all languages | CDK Assertions, jest |
| Community Size | Largest (40,000+ GitHub stars) | Growing (21,000+ GitHub stars) | Moderate (12,000+ GitHub stars) |
Terraform: The Industry Standard
Terraform remains the most widely adopted IaC tool. Stack Overflow's 2024 Developer Survey ranked it the most-used IaC tool for the fourth consecutive year, with 37% of infrastructure professionals using it regularly.
Strengths
- Unmatched provider ecosystem — Over 3,000 providers covering every major cloud, SaaS, and on-premise platform. If it has an API, there is probably a Terraform provider for it.
- Declarative by design — HCL forces a declarative approach, which prevents teams from writing imperative spaghetti infrastructure code. The plan/apply workflow gives clear visibility into what will change.
- Massive hiring pool — More engineers know Terraform than any other IaC tool, reducing recruitment friction significantly.
- Module ecosystem — The Terraform Registry has 15,000+ published modules, giving teams production-ready building blocks.
Weaknesses
- HCL limitations — HCL is deliberately constrained. Complex logic — conditional resources, dynamic blocks, type transformations — can become unreadable. Loops and conditionals feel bolted on.
- State file management — The state file is a single point of failure. State locking, remote backends, and state file corruption are ongoing operational concerns.
- Licence change — HashiCorp's 2023 switch from MPL 2.0 to BSL 1.1 prompted the OpenTofu fork. Organisations must now choose between Terraform (HashiCorp) and OpenTofu (Linux Foundation). This adds strategic risk.
- Testing is an afterthought — While
terraform test(introduced in v1.6) improved the situation, unit testing Terraform modules is still harder than testing general-purpose code.
Pulumi: General-Purpose Languages for Infrastructure
Pulumi's core thesis is simple: use the same languages your application developers already know. According to Pulumi's own metrics, adoption grew 85% year-over-year in 2024, driven primarily by teams frustrated with HCL's limitations.
Strengths
- Real programming languages — Write infrastructure in TypeScript, Python, Go, C#, or Java. Full IDE support, autocompletion, type checking, and the ability to write proper abstractions.
- Native testing — Unit test your infrastructure with pytest, jest, or Go test. Mock cloud resources and validate behaviour before deployment. This is genuinely transformative for large codebases.
- Pulumi AI — Pulumi's AI-powered code generation works surprisingly well because it leverages LLMs' existing knowledge of TypeScript/Python rather than the more niche HCL.
- Automation API — Embed Pulumi inside other applications. Build self-service platforms, internal developer portals, and custom deployment workflows programmatically.
Weaknesses
- Smaller provider ecosystem — While Pulumi can bridge to any Terraform provider (via the pulumi-terraform-bridge), native providers lag behind in coverage and documentation.
- Imperative temptation — The flexibility of general-purpose languages can lead to over-engineering. We have seen teams build infrastructure code that looks like application code with layers of abstraction that hurt readability.
- Fewer engineers with experience — While the learning curve for developers is low, finding engineers with production Pulumi experience is harder than finding Terraform engineers.
AWS CDK: Deep AWS Integration
AWS CDK generates CloudFormation templates from higher-level constructs. For teams that are 100% AWS, CDK offers the deepest integration and fastest path to production.
Strengths
- L2 and L3 constructs — CDK's higher-level constructs encode AWS best practices. An L2
ApplicationLoadBalancedFargateServicesets up a Fargate cluster, ALB, target groups, security groups, and IAM roles in 15 lines of code. - Day-zero support — New AWS services are available in CDK on launch day because it generates CloudFormation, which always has full coverage.
- CDK Pipelines — Built-in CI/CD pipeline construct that handles multi-account, multi-region deployments with approval gates.
- CDK Migrate — Import existing CloudFormation stacks or live AWS resources into CDK code. Useful for brownfield environments.
Weaknesses
- AWS lock-in — CDK generates CloudFormation, which is AWS-only. CDKTF (CDK for Terraform) exists but is a separate project with different semantics.
- CloudFormation limits — You inherit all CloudFormation constraints: 500 resource limit per stack, slow rollbacks, and cryptic error messages.
- Drift detection gaps — CloudFormation drift detection is not comprehensive. Some resource properties cannot be checked for drift, which can cause silent configuration divergence.
Decision Framework: How to Choose
After deploying all three tools across dozens of client environments, here is the decision framework we use at Cloudrix:
Choose Terraform when:
- You operate across multiple cloud providers and need consistent tooling
- Your infrastructure team is separate from your development team
- You need the largest possible ecosystem of community modules and providers
- Hiring Terraform engineers is a priority (largest talent pool)
Choose Pulumi when:
- Your developers own their infrastructure (you-build-it-you-run-it culture)
- You need complex logic, abstractions, or reusable libraries
- Testing infrastructure code is a hard requirement (regulated industries)
- You want to build internal developer platforms with the Automation API
Choose AWS CDK when:
- You are 100% AWS with no plans to go multi-cloud
- You want the fastest path from code to deployed AWS resources
- Your team already maintains CloudFormation templates and wants to level up
- You need day-zero support for every new AWS service
What About OpenTofu?
OpenTofu, the Linux Foundation's fork of Terraform, is worth tracking. As of early 2026, it maintains full compatibility with Terraform 1.6.x providers and modules while adding features like client-side state encryption. However, provider ecosystem divergence is beginning: some HashiCorp-authored providers now ship Terraform-only features. For new projects, evaluate OpenTofu alongside Terraform — the risk profile depends on how many HashiCorp-authored providers you depend on.
Our Recommendation for European Enterprises
For most European enterprises we work with, we recommend Terraform for platform teams and Pulumi for product teams. Platform teams benefit from Terraform's provider breadth and the large hiring pool. Product teams — who already think in TypeScript or Python — are more productive with Pulumi because they can apply their existing skills directly.
Whichever tool you choose, the critical success factor is the same: treat infrastructure code with the same rigour as application code. That means code review, automated testing, CI/CD pipelines, and version control. If you need help establishing these practices, our DevOps consulting team can set up your IaC pipeline in as little as two weeks.
