CloudFormation vs Terraform on AWS, Here’s the Real Difference Nobody Talks About
Every DevOps job posting demands one of these two. Every team building on AWS has the debate. Yet most comparisons read like a vendor FAQ, feature tables with no actual stakes attached. Cloud security architect azuax, with over ten years of AWS experience, breaks down the CloudFormation vs Terraform on AWS debate in a way that actually matters for teams in production.
Both CloudFormation and Terraform let you define AWS infrastructure as code, declarative, versioned, and repeatable. That, however, is where most similarities end.
CloudFormation was built by AWS, specifically for AWS. It plugs directly into the AWS control plane. Terraform, built by HashiCorp, talks to the same AWS APIs but operates entirely outside the AWS ecosystem. It stores infrastructure state in a file, locally or in a remote backend you configure yourself. That difference in philosophy drives every real tradeoff.
CloudFormation handles state on AWS’s side. Deployments come with automatic rollbacks when something fails. There’s no bootstrapping problem. Terraform, on the other hand, introduces what’s called the chicken-and-egg problem, you need infrastructure to store the state of your infrastructure. For consultants onboarding into a client’s environment, that operational overhead adds up fast. CloudFormation also ships with Change Sets, previews showing exactly what will be modified before a deployment runs, and Stack Policies that block specific resources from being updated or deleted.
Terraform’s strength, however, lies in how it handles scale and code reuse. Its HCL language is more expressive. The loop creates multiple similar resources without repetition. Its module system lets teams write once and reuse across every environment. Terraform’s registry also ships thousands of community-maintained modules. CloudFormation has Nested Stacks, but they require S3-hosted child templates that must be re-uploaded on every change.
Then there’s the part most comparisons skip entirely: security. Terraform state files store everything Terraform knows about provisioned resources. That includes database passwords, private keys, and access tokens. By default, that’s a local .tfstate file. If it ends up in a Git repository, credentials are exposed. Even when stored in S3, teams must ensure the bucket is encrypted, has versioning enabled, blocks public access, and uses DynamoDB for state locking. None of that is automatic. CloudFormation never exposes a state file at all. AWS manages it internally. There is nothing to leak.
Terraform also pulls providers from the HashiCorp Registry. The major providers are well-maintained, but unverified community providers introduce supply chain risk. Additionally, HashiCorp changed Terraform’s license from MPL to BUSL in 2023, restricting its use inside competing cloud services.
On multi-account AWS environments, CloudFormation StackSets is a standout. It deploys a single template across dozens or hundreds of accounts from a central management account. In Service-Managed mode, the necessary IAM roles are created automatically. With automatic deployment enabled, any new account added to a target organizational unit gets the stack without further intervention. The Terraform equivalent requires a separate provider block per account, iteration via for each, and a third-party tool like Terragrunt to stay manageable.
The author’s verdict on the CloudFormation vs Terraform on AWS question: use both, with clear boundaries. Use CloudFormation StackSets for org-level governance, security baselines, compliance controls, and centralized logging. Use Terraform for application infrastructure within those accounts: VPCs, compute, databases, and IAM roles for workloads. For engineers actively job hunting, Terraform is still the stronger investment. It appears far more frequently in cloud engineer and DevOps job listings, and its skills transfer across cloud providers.
