Infrastructure as Code comparison
Terraform vs CloudFormation
The two most common Infrastructure as Code tools for AWS workloads. Whether to use the AWS-native option or the cloud-agnostic one is a recurring architecture decision — and one that comes up constantly in DevOps and platform engineering conversations.
TL;DR
- Terraform is cloud-agnostic IaC from HashiCorp (now OpenTofu for the open-source fork). Uses HCL, stores state in a file, has providers for AWS, Azure, GCP, and hundreds of SaaS products.
- CloudFormation is AWS's native IaC service. Uses YAML or JSON templates, manages state internally (no state file to manage), with deep AWS integration and automatic rollback.
- AWS-only shops often prefer CloudFormation's zero-friction state management. Multi-cloud or multi-provider teams prefer Terraform's consistent workflow across everything.
Side-by-side comparison
| Aspect | Terraform | CloudFormation |
|---|---|---|
| Cloud support | Multi-cloud + SaaS (AWS, Azure, GCP, Cloudflare, etc.) | AWS only (plus limited CloudFormation Extensions) |
| Language | HCL (HashiCorp Configuration Language) | YAML or JSON |
| State management | External state file — must be stored and locked remotely | Managed internally by AWS — no state file |
| Rollback on failure | No automatic rollback — fix and re-apply | Automatic — reverts to previous stable state |
| AWS feature coverage | Very good — providers updated frequently | Comprehensive — new AWS services land in CF first |
| Community / modules | Large — Terraform Registry with thousands of modules | Smaller — some community modules via CDK constructs |
| Drift detection | terraform plan — compares state file to live infra | Built-in drift detection per stack |
| Higher-level abstraction | Terraform CDK (CDKTF) — TypeScript/Python/etc. | AWS CDK — synthesises to CloudFormation |
When to use Terraform
- Multi-cloud or multi-provider infrastructure. Managing AWS plus Cloudflare DNS, GitHub, and Datadog alerts in one codebase is Terraform's natural home.
- Team portability. Engineers who know Terraform can work across AWS, Azure, and GCP without relearning tools.
- Rich module ecosystem. The Terraform Registry has well-maintained community modules for common patterns (VPCs, EKS clusters, RDS) that accelerate provisioning.
- Greenfield projects. New infrastructure projects often choose Terraform for its flexibility and avoid vendor lock-in to AWS tooling.
When to use CloudFormation
- AWS-only workloads where simplicity matters. No state file to manage, no remote backend to configure — CloudFormation's state lives in AWS.
- Automatic rollback is non-negotiable. For regulated environments where failed deployments must revert automatically, CloudFormation's built-in rollback is a significant advantage.
- Deep AWS service integration. New AWS services and features appear in CloudFormation on day one; Terraform providers sometimes lag.
- AWS CDK users. If your team uses CDK for infrastructure abstraction, the synthesised output is CloudFormation — you get CDK's developer experience with CF's state management.
English phrases engineers use
Terraform conversations
- "We're provisioning infrastructure with Terraform — run
terraform applyto create the VPC." - "The state file is locked — someone else is running an apply."
- "We're migrating from CloudFormation to Terraform for multi-cloud support."
- "Run terraform plan first — never apply blindly."
- "The module is in the Terraform Registry — just reference the source."
CloudFormation conversations
- "The stack failed to create — CloudFormation is rolling back automatically."
- "We detected drift on the security group — someone changed it manually."
- "The change set shows what will be created, updated, or deleted before we execute."
- "We use nested stacks to keep templates under the 500-resource limit."
- "The stack output exports the VPC ID for other stacks to import."
Key vocabulary
- HCL — HashiCorp Configuration Language; Terraform's declarative configuration syntax.
- State file — Terraform's record of the real-world infrastructure; must be stored remotely for team use.
- Provider — a Terraform plugin that manages a specific platform's resources (aws, google, azurerm, cloudflare).
- Stack (CloudFormation) — a collection of AWS resources managed as a unit by a CloudFormation template.
- Change set — a CloudFormation preview of what will change before executing an update; equivalent to
terraform plan. - Drift — a divergence between the declared infrastructure state and the actual live resources (caused by out-of-band changes).
- CDK — Cloud Development Kit; generates CloudFormation (AWS CDK) or Terraform (CDKTF) from TypeScript/Python code.
Quick decision tree
- AWS only, want zero state file management → CloudFormation
- Multi-cloud or managing SaaS providers alongside AWS → Terraform
- Need automatic rollback on stack failure → CloudFormation
- Want a module ecosystem and community patterns → Terraform
- Team uses AWS CDK → CloudFormation (CDK synthesises to it)
- New AWS features on day one → CloudFormation
- Portability across cloud providers matters → Terraform
Frequently asked questions
Is Terraform better than CloudFormation?
Neither is universally better — they serve different needs. Terraform wins on multi-cloud and multi-provider support, a rich module ecosystem, and a consistent workflow across any infrastructure. CloudFormation wins on AWS-native depth, tight IAM integration, automatic rollback, and no external state file to manage. AWS-only shops often prefer CloudFormation for its zero-configuration state management; teams with multi-cloud ambitions use Terraform.
What is a Terraform state file?
The state file (terraform.tfstate) is a JSON file that records the current real-world state of your infrastructure — what resources exist, their IDs, and their properties. Terraform uses it to compute the difference between desired state (your .tf files) and actual state before applying changes. In teams, the state file must be stored remotely (S3 + DynamoDB, Terraform Cloud, etc.) so everyone operates on the same view of infrastructure.
Does CloudFormation support rollback?
Yes, and this is one of CloudFormation's strengths. If a stack update fails, CloudFormation automatically rolls back to the previous stable state by default. You can also enable rollback on creation failure. CloudFormation tracks all resource changes within a stack operation and can undo them atomically. Terraform does not roll back automatically on failure; you must run terraform apply again after fixing the error.
What is Terraform drift detection?
Drift occurs when the real infrastructure diverges from what is defined in Terraform code — for example, someone manually changes a security group rule in the AWS console. Terraform detects drift by running terraform plan, which compares the state file and live infrastructure. CloudFormation has a dedicated drift detection feature that checks each resource against the template and reports which properties have changed outside of CloudFormation.
What is the CDK and how does it relate to CloudFormation?
AWS CDK (Cloud Development Kit) is a higher-level abstraction on top of CloudFormation. You write infrastructure in a real programming language (TypeScript, Python, Java, etc.) and CDK synthesises it to a CloudFormation template. CDK gives you the full power of a programming language (loops, conditionals, abstractions) while still deploying via CloudFormation stacks and benefiting from CloudFormation's rollback and state management.
Can Terraform manage non-AWS resources?
Yes — this is Terraform's key differentiator. The provider ecosystem covers AWS, Azure, GCP, Kubernetes, Cloudflare, GitHub, Datadog, PagerDuty, and hundreds more. A single Terraform workspace can provision an AWS VPC, create a Cloudflare DNS record, and add a GitHub Actions secret — all in one apply. CloudFormation is limited to AWS resources (plus some via CloudFormation Extensions).