Terraform vs. Pulumi vs. CloudFormation: Which Infrastructure as Code Tool Should You Learn?

Terraform vs. Pulumi vs. CloudFormation: Which Infrastructure as Code Tool Should You Learn?

Once you move past clicking through a cloud console, you hit the next question every cloud and DevOps learner faces: which Infrastructure as Code (IaC) tool should you actually learn? Terraform, Pulumi, and AWS CloudFormation all solve the same core problem, describing infrastructure in files so it can be reviewed, versioned, repeated, and rebuilt. But they solve it in genuinely different ways, and those differences affect your job prospects, your day-to-day workflow, and how easily your skills transfer between employers.

This guide compares all three honestly: how each one works, who it suits, where it struggles, and how to decide without falling for tool tribalism. If you're still weighing IaC against manual setup, start with our guide on why Terraform beats clicking through a console, then come back here to pick a tool.

This post originally appeared on the Ciphemic Academia blog.

The Short Version

• Terraform is the most widely used multi-cloud IaC tool, with its own declarative language (HCL) and the largest ecosystem of providers and learning material.
• Pulumi lets you write infrastructure in real programming languages (TypeScript, Python, Go, C#, Java), which appeals strongly to developers.
• CloudFormation is AWS's native IaC service: deeply integrated with AWS, no separate state to manage, but AWS-only.

If you want one default recommendation for most learners: learn Terraform first, because its concepts (providers, state, plan/apply, modules) transfer to the other two, and it shows up most often in job descriptions. The rest of this guide explains when that default is wrong for you.

What All Three Have in Common

Before the differences, the shared foundation, because this is what you're really learning:

• Declarative thinking: you describe the desired end state, and the tool works out how to get there
• Version control: infrastructure definitions live in Git, get reviewed in pull requests, and have a history
• Repeatability: the same definition can build identical dev, staging, and production environments
• Dependency handling: the tool understands that a database must exist before an app that connects to it
• Drift and change awareness: you can preview what will change before it changes

Learn these ideas well in any one tool and roughly 70% of the skill carries over to the others. The remaining 30% is syntax, workflow, and ecosystem, which is what the rest of this comparison covers.

Terraform

What it actually is: an open-ecosystem IaC tool from HashiCorp (now part of IBM) that uses its own declarative configuration language, HCL. You write resource definitions, run terraform plan to preview changes, and terraform apply to make them. Terraform tracks what it has created in a state file, and talks to cloud platforms through providers, plugins that exist for AWS, Azure, Google Cloud, Kubernetes, GitHub, Cloudflare, Datadog, and hundreds of other services.

A small example (an S3 bucket with versioning):

resource "aws_s3_bucket" "assets" {
  bucket = "ciphemic-demo-assets"
}

resource "aws_s3_bucket_versioning" "assets" {
  bucket = aws_s3_bucket.assets.id

  versioning_configuration {
    status = "Enabled"
  }
}

Where it shines:

• Multi-cloud and multi-service: one workflow for AWS, Azure, GCP, and non-cloud services like DNS and monitoring
• Ecosystem size: the largest pool of providers, community modules, tutorials, and Stack Overflow answers
• Job market visibility: the tool most commonly named in DevOps and cloud engineering job postings
• Readable by non-programmers: HCL is deliberately simple, so ops-oriented engineers pick it up quickly

Where it struggles:

• State management is a real skill: the state file must be stored remotely, locked, and protected, and mistakes with it are one of the most common sources of Terraform pain
• HCL has limits: complex logic (loops, conditionals, transformations) is possible but can get awkward compared to a general-purpose language
• Licensing and forks: in 2023 HashiCorp moved Terraform from an open-source license to the Business Source License, which led to the community-driven OpenTofu fork. The two remain very similar for learners, but it's worth knowing the landscape, and worth checking current details when you evaluate them for an employer

Who this suits: learners who want the broadest job-market coverage, people working across more than one cloud, and anyone building a DevOps or Cloud Engineer profile.

Pulumi

What it actually is: an IaC platform that lets you define infrastructure using general-purpose programming languages: TypeScript, Python, Go, C#, Java, and also YAML. Instead of learning a separate configuration language, you use loops, functions, classes, and package managers you already know. Like Terraform, it's multi-cloud, and it tracks state, by default in Pulumi Cloud, with self-managed backend options available.

A small example (the same bucket, in TypeScript):

import * as aws from "@pulumi/aws";

const assets = new aws.s3.BucketV2("assets", {
  bucket: "ciphemic-demo-assets",
});

new aws.s3.BucketVersioningV2("assets-versioning", {
  bucket: assets.id,
  versioningConfiguration: { status: "Enabled" },
});

Where it shines:

• Real programming constructs: creating ten similar resources is a loop, not a workaround
• Developer familiarity: if you already write TypeScript or Python, there's no new language to learn
• Testing and reuse: infrastructure code can use the same testing frameworks and package sharing as application code
• Good fit for platform teams: teams building internal tooling around infrastructure often prefer a full language

Where it struggles:

• Smaller ecosystem and job footprint: fewer job postings name Pulumi, and fewer community examples exist than for Terraform
• Flexibility cuts both ways: because it's real code, it's easier to write clever, hard-to-review infrastructure than with a deliberately limited language like HCL
• Extra concepts for ops-first learners: if you're not yet comfortable with programming, you're learning two things at once

Who this suits: developers who want infrastructure to feel like the rest of their codebase, teams with strong software engineering practices, and learners who already know TypeScript or Python well.

AWS CloudFormation

What it actually is: AWS's native IaC service. You describe resources in YAML or JSON templates, and AWS itself creates and manages them as stacks. There's no separate tool to install for state: AWS tracks the stack for you. Many teams also use the AWS CDK, which lets you write infrastructure in programming languages and compiles it down to CloudFormation templates.

A small example (the same bucket, in YAML):

Resources:
  AssetsBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: ciphemic-demo-assets
      VersioningConfiguration:
        Status: Enabled

Where it shines:

• Deep AWS integration: new AWS features are typically supported natively, and it plugs into AWS services and permissions directly
• No state file to manage: AWS holds the state, which removes a whole category of setup and risk
• Rollback behavior: failed stack updates can automatically roll back to the previous working state
• Common in AWS-only organizations: many companies committed to AWS use it, or the CDK, as their standard

Where it struggles:

• AWS only: the skill doesn't transfer to Azure, GCP, or non-cloud services
• Verbose templates: large YAML or JSON templates get long and hard to read
• Error messages and debugging: troubleshooting failed stacks can be frustrating, especially for beginners

Who this suits: learners targeting AWS-focused roles, people at companies already standardized on AWS, and anyone planning to use the AWS CDK.

Side-by-Side Comparison

	Terraform	Pulumi	CloudFormation
Language	HCL (declarative DSL)	TypeScript, Python, Go, C#, Java, YAML	YAML / JSON (or CDK)
Cloud support	Multi-cloud and many services	Multi-cloud and many services	AWS only
State management	You manage state (remote backend)	Pulumi Cloud by default, self-managed option	Managed by AWS
Learning curve	Moderate, one new language	Easy if you code, harder if you don't	Moderate, verbose templates
Ecosystem and community	Largest	Growing, smaller	Large within AWS
Job-market visibility	Highest	Lower, growing	High for AWS-specific roles
Best for	Broad DevOps and cloud roles	Developer-led and platform teams	AWS-committed teams

How Each Tool Fits a Career Path

Tools matter less than the role you're aiming for, so here's the practical mapping:

• Cloud Engineer or DevOps Engineer (general): Terraform first. It's the most commonly listed and the most transferable
• AWS-focused engineer or solutions architect: learn the AWS fundamentals, then CloudFormation or the CDK alongside Terraform
• Software engineer moving into platform or infrastructure work: Pulumi can feel natural, but learn Terraform's concepts too, since you'll meet it in existing codebases
• Multi-cloud or consulting roles: Terraform, because clients use a mix of platforms
• DevSecOps: Terraform plus policy and scanning tools; see our DevSecOps career path guide for how IaC fits into security work

How to Choose Without Overthinking It

A simple decision framework:

1. Check job descriptions for the roles you want. Search a dozen postings and count which tool appears. That's your market signal.
2. Consider your current strength. Strong programmer? Pulumi's learning curve is gentlest. Ops or networking background? Terraform's HCL will feel more natural.
3. Consider your employer or target employer's cloud. All-in on AWS? CloudFormation or CDK belongs on your list. Mixed environment? Terraform.
4. Don't wait for the perfect choice. The core ideas transfer, so starting with any one is far better than delaying while you compare.

A note on honesty: no single tool is objectively best. Terraform's wide adoption makes it the safest default, not a universal winner, and tooling in this space keeps shifting, so check current versions, licensing, and features before committing a team to any of them.

Common Mistakes When Learning IaC

• Learning the tool without learning the cloud. IaC only automates what you understand. If you don't know what a VPC or IAM role is, your Terraform will be copy-paste guesswork. Build cloud fundamentals first.
• Ignoring state. Whether it's a Terraform state file or a Pulumi backend, understand where state lives, how it's locked, and what happens if it's lost.
• Never destroying anything. Practice destroy on test environments so you're comfortable tearing down and rebuilding, and so you don't leave billable resources running.
• Skipping version control and review. The point of IaC is that infrastructure changes are reviewed like code. Practice with Git and pull requests from day one.
• Treating tool choice as identity. Engineers who can work in more than one tool are more valuable than tool loyalists.

Frequently Asked Questions

Should a complete beginner learn Terraform, Pulumi, or CloudFormation first?

For most beginners, Terraform. It has the most learning material, the widest job-market presence, and concepts that transfer. Learn basic cloud fundamentals first, so the code you write means something.

Is Terraform still worth learning after the licensing change?

Yes. The licensing change affected how the tool can be used commercially, not how you learn it. The concepts are the same, and the OpenTofu fork stays closely compatible for learners. Check current details if your employer has a policy on it.

Is Pulumi better than Terraform for developers?

It's better suited to some developers, particularly those who prefer writing infrastructure in a language they already know. It isn't universally better: Terraform's larger ecosystem and job visibility still make it the safer default for career purposes.

If I only work on AWS, do I still need Terraform?

Not strictly. CloudFormation or the AWS CDK can cover an AWS-only career well. But many AWS engineers still learn Terraform because employers and future roles often span more than one platform.

How long does it take to learn an IaC tool?

You can write basic infrastructure within a few weeks of consistent practice. Getting comfortable with modules, remote state, environments, and team workflows takes several months of real project work.

Do I need to learn programming before Pulumi?

Yes, at least one supported language to a working level. If you don't code yet, Terraform or CloudFormation is a gentler starting point.

Pick a Tool and Start Building

The best IaC tool is the one you actually practice with on real projects. Pick based on the role you're targeting, build something small and real (a VPC, a virtual machine, a storage bucket), then rebuild it from code until it feels routine. Explore the courses to build the cloud and DevOps foundation that makes your infrastructure code meaningful, and choose your tool with your eyes open about where each one stands today.