Terraform vs CloudFormation on AWS

The short answer

Both tools provision AWS resources from files. Terraform is a general infrastructure as code tool that talks to AWS through a provider. CloudFormation is the AWS native service that runs templates as stacks. The choice comes down to scope, state ownership, review style, and how much you want the AWS console and IAM model to carry.

For an AWS-only team, CloudFormation has real advantages: stack events, change sets, drift detection, StackSets for many accounts, and close ties to IAM, Service Catalog, and AWS Config. Terraform has real advantages too: one workflow for AWS and non-AWS systems, a plan output that many engineers find easier to review, and a large module ecosystem.

You can use both, but do not let them manage the same resource. Split by account, environment, or layer, and write down which tool owns each layer. Mixing without ownership rules creates drift that neither tool can fix cleanly.

How Terraform works

Terraform reads HCL files, builds a dependency graph, and compares desired resources with a state file. The state file is the source of truth for what Terraform believes it created. Store it in a remote backend such as S3 with DynamoDB locking, or in a managed service, and give each account and environment its own state.

The core commands are init, plan, apply, and destroy. Plan shows the diff before changes. Terraform refreshes resource attributes during plan unless you disable it. Drift shows up as a diff, but you must run the plan to see it. Import blocks and terraform import bring existing resources under management. Use moved blocks and prevent_destroy where deletion would hurt.

For AWS, pin the AWS provider version and the Terraform version. Use assume_role in provider blocks for cross-account work. Put modules in a registry or a Git repo with version tags. Keep state access narrow because state can contain sensitive values. A CI pipeline should run fmt, validate, plan, policy checks, and then apply after approval. Locking prevents two applies from racing.

How CloudFormation works

CloudFormation reads YAML or JSON templates and creates a stack. A stack is the unit of change and the unit of rollback. Change sets show proposed changes, though some resource updates produce noisy output. If a stack update fails, CloudFormation rolls back to the last good stack state by default. Drift detection compares actual resources with the template.

StackSets extend a stack across accounts and regions from an administrator account. Nested stacks and modules break large templates into pieces. The CloudFormation Registry lets you define private resource types, and Hooks can check resources before create, update, or delete. Service roles control what CloudFormation can do on your behalf.

CloudFormation is AWS only. New AWS features can appear in the console before the template support lands, so check resource coverage early. Custom resources with Lambda fill gaps, but they add code you must test and own. The AWS CDK and SAM generate CloudFormation, which gives you a programming language without leaving the native stack model.

When to choose Terraform

Choose Terraform when your platform touches AWS plus other systems. DNS, monitoring, identity, data tools, and SaaS settings can sit in the same workflow and plan. That matters when a release needs an AWS role, a DNS record, and a third-party alert rule changed together.

Choose Terraform when plan review is central to your change process. The plan output gives reviewers a resource-level diff, and policy tools can block risky changes before apply. Module versioning helps a platform team ship repeatable patterns to product teams. If your engineers already know HCL, the ramp is short.

Terraform needs discipline. You must protect state, lock it, back it up, and avoid manual edits. You need a pipeline that stores plan artifacts and applies the exact plan that was approved. Without that, Terraform is just a faster way to make unreviewed changes.

When to choose CloudFormation

Choose CloudFormation when AWS is the whole platform and you want the native control plane. Stack events give a clear audit trail in the console and in CloudTrail. Change sets, drift detection, and rollback are built in. IAM service roles make it clear what the provisioning service can touch.

Choose CloudFormation when you run many AWS accounts. StackSets push a baseline of roles, logging, guards, and network settings across an organization. Service Catalog can publish approved products that product teams launch without writing templates. AWS Config and CloudFormation Guard can reinforce policy.

CloudFormation is weaker when you need one workflow across non-AWS services. Custom resources can close the gap, but they are code with their own failure modes. Template debugging can also be slower because stack events are the main error surface. If your team values a local plan file and a wide provider set, Terraform will feel more direct.

Costs and effort to consider

Terraform effort sits in state operations and provider upgrades. You run the backend, backups, locking, and access controls. Provider releases change behavior, so pin versions and test upgrades in a lower account. Modules need owners, examples, and version tags, or they rot.

CloudFormation effort sits in template design and stack troubleshooting. Large templates need nested stacks or modules. Cross-account work needs StackSets roles and trust. Custom resources need Lambda code, logs, and retries. Change sets help, but reviewers still need to understand AWS resource update behavior.

Both tools need a pipeline, policy checks, drift review, and a rollback plan. The tool is not the hard part. The hard part is ownership of state or stacks, clear account boundaries, and a release process engineers trust. The Cloudverg Delivery platform setup package is one option among others at $14,500 fixed, with pipelines, environments, secrets, infrastructure as code for the core platform, monitoring, and rollback set up in four weeks.

Frequently asked questions