Terraform vs CloudFormation: Choosing the Right IaC on AWS

Definition

Terraform (HashiCorp) is an open-source Infrastructure as Code tool that uses a declarative configuration language called HCL to provision resources across many cloud and SaaS providers via a plugin ecosystem. AWS CloudFormation is AWS's native IaC service that uses JSON or YAML templates to provision and manage AWS resources as stacks. Both tools let you describe desired infrastructure, version it in Git, and have the tool reconcile reality to match — but they differ significantly in scope, execution model, state management, and ecosystem. This article compares them on the dimensions that matter when you're choosing an IaC tool (or both) for an AWS environment.

How It Works

Terraform

You write .tf files in HCL describing resources, data sources, variables, outputs, and modules. You configure one or more providers (aws, random, tls, github, kubernetes, datadog, and many more). terraform init downloads providers; terraform plan shows a diff between code and a state file plus actual cloud; terraform apply executes changes. The state file (terraform.tfstate) is the source of truth — typically stored remotely in an S3 bucket with DynamoDB locking, Terraform Cloud, or an enterprise backend.

CloudFormation

You write a JSON/YAML template describing Resources (required), Parameters, Outputs, Conditions, Mappings, and Transforms. You submit it to the CloudFormation service, which creates a stack — a managed unit AWS tracks server-side. There is no local state file: AWS maintains state internally. On failure, CloudFormation automatically rolls back; on success, you can inspect stack events, drift, and outputs. Change Sets preview exact changes before applying.

Key Features and Limits

Scope

• Terraform is multi-cloud: AWS, Azure, GCP, Kubernetes, plus SaaS (GitHub, Cloudflare, Datadog). It's the default choice for multi-cloud shops and for teams that want one tool across IaaS and SaaS.
• CloudFormation is AWS-only. It's first-party, so new AWS service features typically land in CloudFormation on or near GA.

Language

• Terraform uses HCL, designed for readability and IaC: terse, with built-in loops (for_each, count), conditionals, and rich expressions.
• CloudFormation uses JSON or YAML. YAML has short-form !Ref, !Sub, !GetAtt intrinsic functions. Neither has true loops — CDK or SAM macros fill this gap.

State management

• Terraform keeps a local/remote state file. You must configure remote state (S3 + DynamoDB lock, Terraform Cloud) to collaborate. State drift, state corruption, and state surgery (terraform state rm, terraform import) are real operational concerns.
• CloudFormation has no user-visible state — AWS tracks stack state server-side. No state file to secure or lose; no drift-induced state surgery. Drift detection is built in and reports without mutating anything.

Module / module ecosystem

• Terraform has a huge public module registry (registry.terraform.io) and a mature private registry model; reuse is straightforward.
• CloudFormation has nested stacks, StackSets, and the CloudFormation Registry for third-party resource types, but the public module ecosystem is smaller. CDK has a much larger reusable construct ecosystem.

AWS feature support speed

• CloudFormation usually supports new AWS features on day one (some launch with CFN support, some a few weeks later).
• Terraform AWS provider is maintained by HashiCorp and community; major new services often appear within days to a few weeks after launch, but occasional gaps exist (particularly obscure properties or new-new services).

Rollback behavior

• CloudFormation automatically rolls back on failure — a huge operational win. Failed updates leave the stack in UPDATE_ROLLBACK_COMPLETE or ROLLBACK_FAILED states that may require manual intervention.
• Terraform does not auto-rollback. If terraform apply fails mid-way, partially-created resources stay; you fix forward. This is more flexible but demands discipline and is a common source of production incidents.

Import existing resources

• Terraform has terraform import (per resource) and block-level import {} (Terraform 1.5+) that generates HCL automatically — mature and widely used.
• CloudFormation supports Resource Import to bring existing resources under a stack; historically less ergonomic, but has improved with the IaC Generator that scans an account and produces a template + import list.

Multi-account / multi-Region

• Terraform uses multiple provider aliases and tools like Terragrunt to orchestrate across accounts.
• CloudFormation StackSets are first-party and integrate tightly with AWS Organizations for organization-wide rollouts (CloudTrail, Config, guardrails). This is a strength of CloudFormation.

Common Use Cases

1. Multi-cloud or SaaS-heavy org → Terraform.
2. AWS-only org with Organizations landing zone → CloudFormation StackSets (plus CDK for developer ergonomics).
3. Managing GitHub repos, Datadog monitors, and AWS together → Terraform (one tool).
4. Strict governance and automatic rollback → CloudFormation.
5. Kubernetes + AWS IaaS → Terraform (Helm / Kubernetes providers) or CDK + CDK8s.
6. Hybrid usage — many orgs use both: Terraform for account-level bootstrap, CI, GitHub, Datadog; CloudFormation/CDK for application stacks and AWS-specific features.

Pricing Model

• Terraform CLI (OSS) — free. Terraform Cloud / Terraform Enterprise charge for state hosting, runs, policy (Sentinel/OPA), and collaboration features.
• CloudFormation — free for AWS-native resource types; small per-operation fee for third-party Registry resources. You pay only for the underlying resources in both cases.

Pros and Cons

Terraform pros: multi-cloud, huge module ecosystem, richer language, first-class import, flexible workflows, massive community.

Terraform cons: state file is an operational concern, no automatic rollback, provider version drift across teams, proprietary license changes (BSL since 2023) plus the OpenTofu fork created ecosystem uncertainty.

CloudFormation pros: native, free, no state to manage, automatic rollback, StackSets for multi-account, drift detection, deep integration with AWS services and IAM.

CloudFormation cons: verbose YAML/JSON, AWS-only, limited looping without CDK/SAM transforms, some ROLLBACK_FAILED recovery paths are painful, slower to adopt very new SaaS integrations.

Comparison with Alternatives

| | Terraform | CloudFormation | AWS CDK | Pulumi | | --- | --- | --- | --- | --- | | Language | HCL | JSON/YAML | TS/Py/Java/Go/.NET | TS/Py/Go/.NET | | Scope | Multi-cloud | AWS-only | AWS-only (CDKTF bridges) | Multi-cloud | | State | Self-managed | Service-managed | Service-managed (CFN) | Pulumi or self-hosted | | Rollback | No | Automatic | Automatic (CFN) | Limited | | Modules | Huge registry | Nested stacks + Registry | Construct Hub | Components | | Best for | Multi-cloud, SaaS | AWS-native, governance | AWS teams wanting real code | Multi-cloud + real code |

Exam Relevance

• DevOps Professional (DOP-C02) — CloudFormation and StackSets are heavily tested; Terraform is not AWS-native and rarely appears directly, but "best tool for multi-cloud" answers lean Terraform.
• Solutions Architect Professional (SAP-C02) — trade-off questions: landing zones, multi-account governance, drift detection.
• Developer Associate (DVA-C02) — CloudFormation / SAM / CDK basics.
• SysOps Administrator (SOA-C02) — drift detection, stack rollback states, Change Sets.

Exam trap: "multi-Region, multi-account deploy of a baseline template" → StackSets, not Terraform, on AWS exams.

Frequently Asked Questions

Q: Can I use both Terraform and CloudFormation in the same organization?

A: Yes, and many large AWS shops do. A common split is: Terraform manages cross-cutting concerns (AWS account factory, IAM baselines, GitHub org, Datadog, Okta apps) while CloudFormation or CDK manages per-application stacks (ECS service, Lambda, API Gateway, RDS). The key discipline is ensuring a given resource is managed by only one tool — otherwise each run will try to "correct" the other. Use clear ownership boundaries (e.g., Terraform owns network, CDK owns workloads on top).

Q: What happens if the Terraform state file is lost or corrupted?

A: Losing state is serious but recoverable. Terraform relies on state to map resource blocks to actual cloud resources; without it, terraform plan thinks every resource must be created from scratch. Mitigations: store state in S3 with versioning and MFA-delete, with DynamoDB locking; back up state regularly; rotate state with terraform state pull. If state is truly lost, use terraform import (or block-level import {} in 1.5+) to rebuild state resource by resource. CloudFormation avoids this class of risk entirely because AWS manages state server-side.

Q: Which tool adopts new AWS features faster?

A: CloudFormation almost always — many AWS service launches include day-one CloudFormation support, and the CloudFormation Resource Specification is published by AWS. The Terraform AWS provider is maintained by HashiCorp and a large community; major new services typically get coverage within days to a few weeks, but edge properties and less-popular services can lag. If you need day-one access to a brand-new AWS feature, CloudFormation (or CDK L1 constructs, which are CFN-generated) is the safer bet.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS CloudFormation documentation and the Terraform AWS provider docs before making production decisions.