Terraform vs. CloudFormation vs. Pulumi: Choosing the Right IaC Tool for Your Stack

I’ve spent most of the last 12 years standing up cloud environments for clients. They all ask a version of the same question during kickoff calls: “which infrastructure as code tool should we actually use?” It’s a fair question. It’s also the wrong first question. The honest answer is “it depends on what you’re building, who’s building it, and where it has to run.” Still, everyone wants a straight opinion, so I’m going to give one. It’s built from real migrations, a few painful rollbacks, and enough late-night terraform apply runs to earn a strong preference or two.

This isn’t a features checklist copied from a vendor page. It’s a working architect’s take on Terraform, AWS CloudFormation, Pulumi, and where Ansible fits into the picture. I wrote it for teams who need to pick a tool this quarter and live with the consequences for years.

Why Infrastructure as Code Stopped Being Optional

Ten years ago, provisioning a server meant clicking through a console or SSHing in and running commands by hand. That approach doesn’t survive contact with a team of more than two people. It certainly doesn’t survive a company running dozens of environments across regions. Infrastructure as code turns your servers, networks, databases, and permissions into version-controlled files. It’s the same discipline software engineers apply to application code, applied to the infrastructure underneath it.

The payoff isn’t abstract. When infrastructure lives in code, you get a reviewable history of every change. You get a repeatable way to spin up a new environment in minutes instead of days. Maybe most important, you get a rollback path when something breaks at 2 a.m. I’ve watched teams cut environment provisioning time from roughly two weeks to under an hour, just by adopting infrastructure as code properly. And that’s before counting the audit and compliance benefits.

One Category, Four Very Different Tools

“Infrastructure as code” isn’t one tool. It’s a category. Four names come up most in client conversations — Terraform, CloudFormation, Pulumi, and Ansible — and they solve overlapping but genuinely different problems. Picking the wrong one doesn’t just cost you a learning curve. It can lock you into a workflow that fights your team for years.

Terraform: The Default for a Reason, With New Baggage

Terraform earned its position as the closest thing this space has to a common language. It’s cloud-agnostic. Its HashiCorp Configuration Language, or HCL, is approachable enough for ops-minded engineers who aren’t full-time software developers. Its provider ecosystem covers AWS, Azure, Google Cloud, and hundreds of smaller platforms, from SaaS tools to on-prem hardware. Maybe your organization runs workloads across more than one cloud. Maybe it just wants that option someday. Either way, Terraform’s state-driven, declarative model is still the safest default.

What’s changed is the ground underneath it. HashiCorp switched Terraform’s license from open-source MPL to the Business Source License back in 2023. IBM completed its acquisition of HashiCorp in early 2025. For most users, nothing broke overnight. But the shift pushed a meaningful slice of the community toward OpenTofu — the Linux Foundation-backed open-source fork that stayed true to the original license terms. If you’re starting fresh today, evaluate both Terraform and OpenTofu side by side. Don’t just assume Terraform is the only path. The two are close cousins now, not identical twins, and they’re starting to diverge in tooling and governance.

Terraform’s other real weakness is state management. The state file is the single source of truth for what Terraform believes exists. When it drifts from reality, recovering can eat an entire afternoon. Someone changes a resource by hand in the console. An apply gets interrupted. A merge conflict corrupts the file. Terraform Cloud and remote state backends smooth this over. It’s still an operational tax you pay indefinitely, not a one-time setup cost.

AWS CloudFormation: Native, Free, and Boxed In

If your entire footprint lives inside AWS and you don’t see that changing, CloudFormation deserves serious consideration. It’s built by AWS, for AWS. New services usually get CloudFormation support on day one or close to it. There’s no separate tool to license, patch, or run — it’s a managed service baked into your AWS bill at no extra charge. Drift detection is native. Rollback behavior on failed deployments is automatic and well-tested. IAM permissions integrate without the extra glue code some third-party tools need.

The tradeoff is the one you’d expect: CloudFormation only speaks AWS. The moment your architecture needs a Cloudflare configuration, a Datadog monitor, or a resource in a second cloud provider, you’re stuck. You’re either bolting on a separate tool or fighting CloudFormation’s custom resource mechanism, which works but adds real complexity. Its YAML and JSON templates also get verbose fast — a moderately complex stack can run past a thousand lines. That verbosity makes code review slower and mistakes easier to miss. AWS’s own answer is the Cloud Development Kit. It lets you write CloudFormation logic in TypeScript, Python, or Java, then compiles it down to a template. It’s a meaningfully better authoring experience, though still tied to the same AWS-only ceiling.

I’d point a client toward CloudFormation, or CDK on top of it, when they’re AWS-committed for the foreseeable future. It’s a good fit when they want to minimize the moving parts in their toolchain. I’d steer them away the moment multi-cloud shows up on the roadmap, even as a maybe.

Pulumi: Real Programming Languages, Real Tradeoffs

Pulumi’s pitch is simple and genuinely compelling. Instead of learning a domain-specific language, you write your infrastructure in Python, TypeScript, Go, C#, or Java — languages your developers likely already know. That single decision changes more than it sounds like it would. You get real loops, real conditionals, and real unit testing frameworks. You can share logic through ordinary package managers like npm or pip instead of a separate module registry.

For engineering-heavy teams, this closes a gap that HCL and YAML never quite manage. It matters most on teams where the same people write application code and infrastructure code. On one platform team I worked with, new hires who already knew TypeScript shipped their first production Pulumi stack within a week. The same cohort took closer to 12 days to get comfortable writing HCL from scratch the previous year.

The honest tradeoff is that Pulumi’s flexibility cuts both ways. A programming language lets you write genuinely clever infrastructure code, and “clever” is not always a compliment here. Give a junior engineer real loops and conditionals, and they can build something far harder to reason about than an equivalent declarative Terraform module. Pulumi’s community and provider ecosystem are still smaller than Terraform’s, even though they’re growing fast. Pulumi also reuses Terraform’s own provider plugins under the hood for many resources. You’re not entirely escaping the ecosystem you might be trying to move away from. Check pricing closely, too: Pulumi’s free tier is generous for small teams, but costs scale with the number of managed resources. That matters once you’re running production at any real size.

Where Ansible Actually Fits

Ansible gets lumped into IaC comparisons constantly, and it belongs in the conversation. But it solves a different layer of the problem. Terraform, CloudFormation, and Pulumi are provisioning tools — they create and destroy the servers, networks, and managed services themselves. Ansible is a configuration management tool. It takes a server that already exists and keeps it in a known state. It installs packages, edits config files, and manages users over time.

In practice, the two categories complement each other more often than they compete. A common and genuinely effective pattern is Terraform, or Pulumi, provisioning the raw infrastructure — the VMs, the load balancers, the networking. Ansible then takes over to configure the software running on top of it. Ansible’s agentless design uses SSH rather than a resident daemon on every managed node, which keeps operational overhead low. Its YAML playbooks are approachable for sysadmins who aren’t coming from a software engineering background.

Where Ansible struggles is state awareness. It doesn’t maintain a persistent model of what should exist the way Terraform’s state file does. Idempotency depends heavily on how carefully each playbook is written. For pure resource provisioning at scale, especially across cloud providers, it’s not the right primary tool. As the configuration layer sitting on top of Terraform or Pulumi, though, it still earns its place in plenty of production stacks.

A Decision Framework That Actually Holds Up

Strip away the marketing, and the decision usually comes down to four questions, in roughly this order of importance.

First: how many clouds are you actually running today, not hypothetically? Single-cloud AWS shops with no near-term multi-cloud plans get real value from CloudFormation’s zero-cost, zero-extra-tooling integration. Anyone running two or more providers, or planning to, should default to Terraform or Pulumi.

Second: what languages does your team already know well? If your platform engineers came up through ops and like declarative configuration, Terraform’s HCL is a gentler ramp than a full programming language. If your infrastructure team overlaps heavily with your application developers, Pulumi removes a context switch they’d otherwise pay every day.

Third: how mature is your compliance and audit requirement? Regulated industries — financial services, healthcare, government contracting — tend to lean toward the tool with the largest, most battle-tested community. Today that’s still Terraform, closely followed by OpenTofu.

Fourth, and this one gets skipped constantly: who’s going to maintain this in three years, not who’s setting it up now? I’ve inherited more than one environment where the original architect chose a clever, capable tool and then left the company. The team that inherited it had never seen Pulumi’s SDK. Or they’d never seen a heavily customized CloudFormation macro setup. Either way, they had to reverse-engineer it under deadline pressure. Boring and well-documented beats clever and unfamiliar almost every time a handoff happens.

My Take, for What It’s Worth

If I’m starting a greenfield project today with no strong constraints either way, I reach for Terraform or OpenTofu first. Ecosystem size and the number of engineers who already know it matter more than people give them credit for. A feature list alone won’t tell you that. If the team is AWS-only and wants to keep the toolchain thin, CloudFormation or CDK is a legitimate choice. It’s lower-maintenance, not a consolation prize. If the organization is developer-heavy, and writes application code as often as HCL, Pulumi is worth a serious pilot before defaulting to habit.

None of these tools is wrong. The wrong move is picking one because it came up in a conference talk. Check it against your actual team, your actual cloud footprint, and who’s going to own it after you’ve moved on.

---

Frequently Asked Questions

Is Terraform still the best infrastructure as code tool after the IBM acquisition?

Terraform remains widely used and actively maintained. The license change and acquisition did push a real portion of the community toward OpenTofu, though. Teams starting new projects should evaluate both before committing. See HashiCorp’s own update on the transition and background on the closed IBM deal.

What’s the actual difference between Terraform and Ansible?

Terraform provisions infrastructure. It creates and tracks the existence of servers, networks, and managed cloud resources. Ansible configures machines that already exist, installing software, managing files, and enforcing settings. Most mature stacks use both together rather than choosing one. See Spacelift’s Ansible vs. Terraform comparison for a detailed breakdown.

Can CloudFormation manage resources outside of AWS?

Only through custom resources, which require you to write and maintain your own Lambda-backed logic for non-AWS services. It’s workable, but it adds meaningful complexity compared to a tool built for multi-cloud from the ground up. See the AWS re:Post thread on Terraform vs. CloudFormation: which is more preferable for developers.

Is Pulumi harder to learn than Terraform?

It depends entirely on your team’s background. Developers already fluent in Python, TypeScript, or Go often find Pulumi faster to pick up than a new domain-specific language. Ops-focused teams without a programming background usually find Terraform’s declarative HCL more approachable. Spacelift’s comparison of Terraform vs. AWS CloudFormation covers similar tradeoffs.

Does drift detection work the same way across these tools?

No. CloudFormation has native, built-in drift detection as part of the managed service. Terraform detects drift on the next plan or apply. It compares real infrastructure against its state file — effective, but not continuous by default. See how CloudFormation drift detection behaves in practice.

Should a small team just pick one tool and standardize on it?

Generally yes, for provisioning. Running two provisioning tools in parallel doubles your operational and training overhead for little benefit. It’s common, though, to pair one provisioning tool — Terraform, CloudFormation, or Pulumi — with Ansible for configuration management. They solve different layers of the problem. See env0’s take on when to use Ansible and Terraform together.

---

References

1. HashiCorp Help Center. “HashiCorp-IBM Product Renaming Update.” https://support.hashicorp.com/hc/en-us/articles/43559447807251-HashiCorp-IBM-Product-Renaming-Update
2. The Register. “IBM likes HashiCorp, finally puts a $6.4B ring on it.” https://www.theregister.com/2025/02/28/ibm_hashicorp_deal_closing/
3. Spacelift. “Terraform vs. Ansible: Differences and Comparison of Tools.” https://spacelift.io/blog/ansible-vs-terraform
4. Spacelift. “Terraform vs. AWS CloudFormation – Ultimate Comparison.” https://spacelift.io/blog/terraform-vs-cloudformation
5. AWS re:Post. “Terraform vs. CloudFormation – Which is more preferable for developers?” https://repost.aws/questions/QU3XqWCv1kQ-aDeoI2baVY-A/terraform-vs-cloud-formation-which-is-more-preferable-for-developers
6. env0. “OpenTofu in 2026: What Platform Teams Need to Know.” https://www.env0.com/insights/opentofu-in-2026-what-the-terraform-fork-became-after-three-years-of-independence
7. Better Stack Community. “Ansible vs Terraform: A Comprehensive Comparison.” https://betterstack.com/community/guides/linux/ansible-vs-terraform/
8. Xavor. “AWS CloudFormation Drift Detection – Infrastructure Compliance at Scale.” https://www.xavor.com/blog/aws-cloudformation-drift-detection-infrastructure-compliance-at-scale/
9. Scalr. “What Is OpenTofu? 2026 Guide to the Open-Source Terraform Fork.” https://scalr.com/learning-center/what-is-opentofu
10. env0. “Ansible vs Terraform: Choose One or Use Both?” https://www.envzero.com/blog/ansible-vs-terraform-when-to-choose-one-or-use-them-together