Infrastructure as code · 11 min read

Terraform vs Pulumi vs CloudFormation

Terraform, Pulumi, and CloudFormation all help teams define infrastructure in code, but they optimise for different workflows. The right choice is the one your team can review, test, secure, and operate reliably—not the one with the most exciting syntax.

A small Terraform configuration

This only illustrates Terraform’s declarative style. It is not evidence that Terraform is better than Pulumi or CloudFormation.

# Terraform uses declarative HCL
resource "aws_s3_bucket" "assets" {
  bucket = "training-assets"
}

Terraform: broad declarative ecosystem

Terraform’s provider ecosystem and declarative language make it a common cross-cloud standard. Its plan output, state model, modules, and workflow are widely understood across infrastructure teams.

The trade-off is that complex logic may feel less natural than in a general-purpose programming language. Good module design and clear configuration structure matter more than trying to force application-style abstractions into every Terraform project.

Pulumi: infrastructure in general-purpose languages

Pulumi lets teams define infrastructure using languages such as TypeScript, Python, Go, or C#. This can suit teams that already have strong software-engineering practices and want familiar testing and abstraction tools.

It does not remove infrastructure complexity. Cloud APIs, permissions, state, reviews, and lifecycle decisions still require platform knowledge.

CloudFormation: AWS-native integration

CloudFormation is AWS-specific and tightly aligned with AWS services. It can fit organisations committed to AWS that want native integration and do not need one language across multiple clouds.

Its AWS focus is an advantage when it matches the strategy and a limitation when portability or cross-cloud consistency is a requirement.

Put it into practice

Choose one tool for a single-cloud AWS team and one for a two-cloud platform team. Defend both choices using operations, skills, and governance—not only syntax.

  1. Decide whether you need one provider or several.
  2. Assess your team’s language and review habits.
  3. Check lifecycle, state, and testing requirements.
  4. Choose a small, supported standard and document it.