The short answer is: Terraform is still the default in many organizations, but Pulumi and cloud-native CDKs have grown significantly, especially among software teams that prefer writing infrastructure in general-purpose languages. Many teams also combine infrastructure tools with serverless deployment frameworks rather than choosing only one.
Here's how the landscape generally looks in 2026:
| Tool | Best for | Tradeoffs |
|---|
| Terraform | Multi-cloud infrastructure, large teams, mature ecosystems | HCL is another language to learn; abstractions can get verbose |
| Pulumi | Developers who want TypeScript, Python, Go, C#, Java | More programming flexibility can also mean more complexity |
| AWS CDK | AWS-heavy organizations | Excellent AWS support, but AWS-specific |
| Azure Bicep | Azure-focused deployments | Tight Azure integration, not multi-cloud |
| Google Cloud Infrastructure Manager / Terraform | GCP environments | Terraform still dominates on GCP |
Terraform
Still arguably the industry standard because:
- Huge provider ecosystem
- Mature state management
- Works across AWS, Azure, GCP, Kubernetes, Datadog, GitHub, Cloudflare, etc.
- Most DevOps and platform engineers already know it
If you're hiring platform engineers, Terraform is still the safest assumption.
Pulumi
Pulumi has become much more common, especially with application teams.
Advantages:
- Real programming languages (TypeScript, Python, Go, C#, Java)
- Better abstraction capabilities
- Easier to share infrastructure libraries
- Great for engineers already writing application code
Instead of:
resource "aws_s3_bucket" ...
you write normal TypeScript:
const bucket = new aws.s3.Bucket("uploads");
This feels much more natural for many software engineers.
AWS CDK
AWS CDK is extremely popular inside AWS-only companies.
It shines when:
- Everything is AWS
- You want access to new AWS services quickly
- You want reusable constructs
Many startups deploying only on AWS use CDK instead of Terraform.
Serverless Frameworks
People often mean one of several things:
- Serverless Framework
- AWS SAM
- SST
- AWS CDK with Lambda
- Frameworks like Next.js deploying to serverless platforms
The trend has shifted toward separating concerns:
- Infrastructure → Terraform, Pulumi, or CDK
- Application deployment → framework-specific tooling
For example:
-
Terraform creates:
- VPC
- IAM
- RDS
- S3
- Lambda permissions
-
Then:
- SST deploys Lambdas
- Next.js deploys the frontend
- CI/CD deploys containers
That's a common split.
Common combinations
You'll often see setups like:
Enterprise AWS
- Terraform
- Helm
- Kubernetes
Modern startup
- Pulumi
- GitHub Actions
- Docker
- Cloud Run or ECS
AWS serverless startup
- CDK
- Lambda
- API Gateway
- DynamoDB
Platform engineering
- Terraform
- Helm
- Argo CD
- Kubernetes
What's becoming less common?
Some older patterns have lost popularity:
- Large CloudFormation templates (outside CDK-generated ones)
- Hand-written ARM templates on Azure (largely replaced by Bicep)
- Monolithic Serverless Framework projects managing every piece of infrastructure
If you're starting fresh
A reasonable decision guide is:
- Multi-cloud or Kubernetes-heavy: Terraform is still the safest, most portable choice.
- Application developers who want to stay in TypeScript, Python, Go, C#, or Java: Pulumi is an excellent fit.
- AWS-only projects: AWS CDK offers a strong developer experience and close integration with AWS services.
- Small serverless applications: A serverless-focused framework (such as SST for AWS) paired with one of the above infrastructure tools can provide a productive workflow.
Overall, the industry is moving away from a single "one tool does everything" approach. It's increasingly common to use one tool for provisioning foundational infrastructure and another that's optimized for deploying application code, particularly in serverless and cloud-native environments.