Terraform vs Other IaC Tools

Terraform is a provisioning tool, and the most common confusion for newcomers is treating it as a rival to Ansible, Kubernetes, or shell scripts when those occupy entirely different layers. Knowing which problem each tool actually solves — and how they compose — is the difference between a clean pipeline and a tangle of tools fighting over the same job.

This topic places Terraform on the map. The map has three regions, and most "Terraform versus X" arguments dissolve once you see which region X lives in.

The Three Layers

Infrastructure tooling splits into three layers. Provisioning creates the resources: the virtual machine, the network, the load balancer, the database. Configuration management sets up what runs on those resources: installs packages, writes config files, manages services. Orchestration schedules and runs long-lived workloads across a fleet — what Kubernetes does for containers.

Terraform lives squarely in provisioning. A tool from a different layer is not a competitor; it is a neighbor that picks up where Terraform leaves off. The arguments worth having are between tools in the same layer — Terraform versus CloudFormation versus Pulumi — and those come down to scope, language, and ecosystem.

Terraform vs CloudFormation and Bicep

CloudFormation (AWS) and Bicep (Azure) are single-cloud declarative provisioning tools, built and fully supported by the cloud vendor, with no state file for you to manage — the cloud keeps it server-side. Terraform spans every cloud through one language and brings a far larger module ecosystem, at the cost of owning your own state.

The honest call: on a committed single-cloud, AWS-only shop, CloudFormation removes the entire state-management burden and is tightly integrated. Choose Terraform when you span more than one cloud, want the module ecosystem, or value a single workflow across every platform your team touches.

Terraform vs Pulumi

Pulumi provisions infrastructure too, but you write it in a general-purpose language — TypeScript, Python, Go — instead of HCL. That buys real loops, classes, unit tests, and the IDE support of a mature language. It also buys every way a real language has to be too clever: a Pulumi program can encode logic that is far harder to review than a Terraform plan diff.

HCL is deliberately constrained, and that constraint is a feature when the artifact's job is to be reviewed and reasoned about. Choose Pulumi when your infrastructure genuinely needs a programming language; choose Terraform when a declarative, reviewable description is the point.

Terraform vs Ansible

This is the comparison people get most wrong, because the two are not competitors at all. Terraform declares and tracks the existence of infrastructure — it knows what it created, so it can plan a precise diff and tear things down cleanly. Ansible configures whatever already exists and keeps no state, so it cannot tell you what it would destroy; each run pushes a desired configuration onto hosts.

Put plainly: Terraform creates the server, Ansible sets up what runs on it. Reaching for Terraform provisioners to install and configure software is recreating Ansible badly — untracked, run-once, with no drift detection. The right design hands off from one to the other.

Using Them Together

The clean pattern is a handoff. Terraform provisions the EC2 instances, the VPC, and the load balancer, and exposes what the next stage needs through outputs — instance IPs, tags, an Auto Scaling group name. A configuration tool like Ansible then reads that inventory and configures the operating system and application. Each tool stays in its layer and neither reinvents the other.

The snippet below is the Terraform side of that handoff: an output that publishes the instances' addresses for Ansible (or any downstream tool) to consume. The full pattern — dynamic inventory by tag, sequencing the two in a pipeline — gets its own topic in the advanced chapter.

output "web_private_ips" {
  value = aws_instance.web[*].private_ip   # Ansible reads these as its inventory
}