Terraform vs CloudFormation on AWS (2026): Enterprise IaC Decision Guide

CloudFormation Hooks deploy org-wide via service-managed StackSets — AWS documents the pattern for baseline guardrails across OUs without per-account CLI runs. Terraform 1.8+ and OpenTofu 1.8+ remain the default for application teams with existing modules and multi-provider needs. The enterprise question is not “which one wins” but which layer each tool owns.

This post is Terraform/OpenTofu vs CloudFormation/StackSets for enterprise AWS. It is not Terraform vs CDK (authoring frameworks), not Terraform vs Pulumi (language choice), and not CloudFormation best practices (how-to for CFN only).

Artifacts: IaC decision matrix, enterprise criteria worksheet CSV.

Benchmark pattern (not a cited client) — 40-account AWS Organization, mixed Terraform app stacks + manual account baselines. Platform team deployed StackSets (Config, GuardDuty, CloudTrail Hooks) to 3 OUs — rollout 9 weeks → 3 weeks. App teams stayed on Terraform/OpenTofu; no app stack migration.

Decision in one table

Opinionated take: Hybrid — StackSets for platform baseline, Terraform for application stacks. One-tool mandates fail when security needs org rollouts and apps need HCL velocity.

CloudFormation / StackSets — when it wins

• Organizations auto-deployment — new accounts in OU get baseline stacks automatically
• CloudFormation Hooks — proactive compliance (e.g., S3 public access block) at deploy time
• No S3 state bucket — one less secret-leak surface
• Service Catalog integration for governed self-service

# Context: CloudFormation StackSet excerpt — service-managed permissions (July 2026)
# Deploy baseline to entire OU; enable trusted access in Organizations first.
Resources:
  GuardDutyEnable:
    Type: AWS::GuardDuty::Detector
    Properties:
      Enable: true

Platform team owns the template; member accounts receive stack instances without local Terraform.

Terraform / OpenTofu — when it wins

• for_each / dynamic blocks for N environments without copy-paste YAML
• Terraform Registry modules shared across repos
• Multi-provider — AWS + Datadog + Cloudflare in one plan
• Existing estate — migration cost dominates switch-to-CFN math

# Context: Terraform 1.8+, AWS provider ~5.x — app stack pattern
resource "aws_ecs_service" "api" {
  for_each = var.environments
  name     = "api-${each.key}"
  cluster  = aws_ecs_cluster.main.id
  # ...
}

What broke — StackSets rollout

What broke — Week 2 of OU-wide StackSets: 12 of 40 accounts stuck PENDING. Root cause: S3 template bucket policy used "AWS": "*" initially, then over-corrected to deny member account roles. Fix: service-managed permission role ARN pattern arn:aws:iam::*:role/stacksets-exec-* in bucket policy. Lesson: test on 2-account OU before prod OU.

Hybrid reference architecture

Management account
├── StackSets (service-managed) → Config, GuardDuty, CloudTrail, Hooks
├── SCPs (Organizations)
└── Delegated admin for StackSets

Member accounts (app teams)
└── Terraform/OpenTofu → ECS, RDS, Lambda (remote state in shared account)

Align with enterprise governance OU taxonomy.

When NOT to use each

What to do this week

1. Score your org on enterprise-criteria-worksheet.csv.
2. Run decision matrix — assign platform vs app layer.
3. If no StackSets baseline: pilot 2 accounts in one OU before org-wide.
4. If Terraform state on S3: verify versioning + MFA delete + lock table today.
5. Document hybrid pattern in internal wiki — stop the “Terraform vs CFN” religious war.

Reproduce this — Fill enterprise-criteria-worksheet.csv with weights 1–5 for your constraints. Sum weighted scores. If org_wide_stacksets weight ≥ 4 and CFN score wins, start StackSets pilot — do not migrate app Terraform first.

What this post doesn’t cover

• CDK authoring depth — Terraform vs CDK guide.
• Application Composer visual IaC — Application Composer post.
• Full Terraform state migration — state management guide.
• Pulumi — OpenTofu vs Pulumi.

Related: DevOps pipeline setup · Enterprise governance