Terraform has the ecosystem. CloudFormation has zero licensing risk, managed state, and your cloud provider's full support. For AWS teams, that trade-off has flipped.
For the better part of a decade, the advice was simple: use Terraform. It was open source, it worked across clouds, it had the biggest ecosystem of modules and providers. CloudFormation was the thing AWS die-hards used because they didn't know better.
That advice needs updating. Terraform is no longer open source — it's under the Business Source License since August 2023. It's no longer independent — IBM completed the $6.4 billion HashiCorp acquisition in February 2025. And the ecosystem advantage is eroding as alternatives mature.
If your infrastructure is primarily AWS — and for most companies it is — CloudFormation is now the stronger long-term bet. Not because it's better in every dimension. Because the dimensions where Terraform was better have narrowed, and the dimensions where CloudFormation wins have become more important.
The Business Source License is not open source. It grants broad usage rights with one exception: you cannot use Terraform to build a product or service that competes with HashiCorp's commercial offerings. For most end users, this exception doesn't apply day-to-day. But it creates a category of legal risk that didn't exist before.
If you build internal developer platforms, managed services, or automation products that wrap Terraform, you need a lawyer to evaluate whether you're creating a "competitive offering." The BSL deliberately leaves this term vague. Maybe your internal platform doesn't compete with HCP Terraform. Maybe it does. Do you want your infrastructure tool choice to depend on that analysis?
CloudFormation has no license to evaluate. It's an AWS service included with your account. CDK is Apache 2.0. There is no scenario where using CloudFormation creates licensing risk.
This is CloudFormation's most underrated advantage, and it's become more important as teams scale.
Terraform requires you to manage a state file. That state file contains the mapping between your Terraform code and your actual infrastructure. Lose the state file and Terraform doesn't know what it manages. Corrupt the state file and Terraform can destroy resources it shouldn't. Let two people run terraform apply simultaneously without locking and you get state corruption.
The standard solution is an S3 backend with DynamoDB locking:
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "prod/vpc/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-locks"
encrypt = true
}
}
That's infrastructure to manage your infrastructure tool. You need the S3 bucket, the DynamoDB table, IAM policies for both, versioning and encryption on the bucket, and a backup strategy. Every team discovers this the hard way the first time someone force-unlocks state during an apply.
CloudFormation manages state internally. AWS tracks which resources belong to which stack. There's no state file to lose, corrupt, or lock. There's no backend to configure. The state is as durable as AWS itself.
aws cloudformation deploy \
--template-file vpc.yaml \
--stack-name production-vpc \
--capabilities CAPABILITY_IAM
That's it. No backend. No locking table. No state bucket. The state is managed by the service.
When AWS launches a new service, CloudFormation support typically arrives on launch day or within days. Terraform providers are maintained by a mix of HashiCorp employees and community contributors, and new service support can lag by weeks or months.
This matters when you want to adopt new services quickly. Lambda Durable Functions launched at re:Invent 2025 with CloudFormation support on day one. If you're building with Terraform, you're either waiting for the provider to catch up or writing raw API calls as a workaround.
The pattern repeats with every launch. CloudFormation is maintained by the same organization that builds the services. The provider and the service ship together. With Terraform, there's always a gap.
Being honest about the trade-offs matters. Terraform has genuine advantages:
If your infrastructure spans AWS, GCP, and Azure, CloudFormation is not an option. Terraform (or OpenTofu, or Pulumi) is the right tool. CloudFormation is AWS-only by design, and that's a real limitation for organizations with multi-cloud requirements.
But be honest about whether you actually need multi-cloud. Most startups and mid-size companies run entirely on AWS. If your "multi-cloud strategy" is a checkbox on a slide deck rather than a deployed reality, you're paying the Terraform complexity tax for a capability you don't use.
Terraform's HCL is more readable than CloudFormation's YAML for most infrastructure definitions. HCL was designed for infrastructure; YAML was designed for serialization. Variables, loops, and conditionals are cleaner in HCL than in CloudFormation's intrinsic functions.
This is a real advantage for raw templates. It's less relevant if you use CDK, which gives you real programming languages on top of CloudFormation's engine.
terraform plan shows exactly what will change before you apply. CloudFormation has change sets, which serve the same purpose, but the Terraform plan output is more detailed and easier to read. For teams that review infrastructure changes in PRs, the Terraform plan is a better experience.
The Terraform module registry is large and well-maintained. Community modules for common patterns (VPCs, EKS clusters, RDS instances) save significant time. CloudFormation has the AWS Solutions Library and third-party templates, but the ecosystem is smaller.
If the YAML verbosity is what keeps you on Terraform, CDK removes that objection entirely. CDK generates CloudFormation templates from TypeScript, Python, Go, Java, or C#. You get the deployment engine reliability of CloudFormation with the expressiveness of a real programming language.
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as rds from 'aws-cdk-lib/aws-rds';
const vpc = new ec2.Vpc(this, 'Vpc', { maxAzs: 3, natGateways: 1 });
const db = new rds.DatabaseInstance(this, 'Database', {
engine: rds.DatabaseInstanceEngine.postgres({ version: rds.PostgresEngineVersion.VER_16 }),
instanceType: ec2.InstanceType.of(ec2.InstanceClass.T4G, ec2.InstanceSize.MEDIUM),
vpc,
multiAz: true,
allocatedStorage: 100,
storageEncrypted: true,
deletionProtection: true,
});
That's a VPC with three AZs, a NAT gateway, a multi-AZ Postgres RDS instance with encryption and deletion protection. CDK generates the CloudFormation template with all the security group rules, subnet groups, and parameter groups. You get loops, conditionals, type checking, and IDE autocomplete — the things Terraform users cite as advantages over raw YAML.
If you're considering moving from Terraform to CloudFormation, the migration path is incremental. You don't need to rewrite everything at once.
| If you... | Use this |
|---|---|
| Run 100% AWS and want zero licensing risk | CloudFormation or CDK |
| Run 100% AWS and prefer real programming languages | CDK |
| Have existing Terraform and want open source | OpenTofu |
| Need multi-cloud with real programming languages | Pulumi |
| Need multi-cloud and prefer HCL | OpenTofu |
| Are starting a new project on AWS in 2026 | CDK |
Terraform's dominance was built on three pillars: open-source trust, multi-cloud capability, and ecosystem breadth. The BSL removed the first pillar. The IBM acquisition cracked it further. The second pillar only matters if you're actually multi-cloud. And the third pillar is eroding as CDK, OpenTofu, and Pulumi mature.
For AWS-focused teams, CloudFormation and CDK now offer the better set of trade-offs: zero licensing risk, managed state, day-one service support, and AWS backing the tool forever. The YAML verbosity that kept people on Terraform is solved by CDK. The state management burden that people tolerated is eliminated entirely.
You don't have to migrate tomorrow. But if you're making the tool choice for a new project in 2026, Terraform shouldn't be the default anymore. Not when the alternative has no license to worry about, no state file to manage, and no corporate acquisition to wonder about.
Published by Yaw Labs.
Interested in AI tools and developer workflows? Token Limit News is our weekly newsletter.