Terraform vs CloudFormation vs CDK: which one to learn

Short answer: learn Terraform first. It is the most requested infrastructure-as-code skill in job postings, it works across clouds, and its concepts transfer everywhere. Use CloudFormation when you are all-in on AWS and want no state file to manage. Use the CDK when your team would rather write TypeScript or Python than a configuration language.

All three tools do the same job: describe infrastructure in files, keep those files in Git, and let a machine make reality match them. What separates them is who holds the state, how they behave on day two, and what the market pays for.

What infrastructure as code actually buys you

Before comparing, it is worth being precise about the value, because "no more clicking in the console" undersells it.

Clicking produces infrastructure nobody can reproduce. Six months later, nobody knows why that security group has that rule, whether the staging environment matches production, or how to rebuild after a region fails. Code makes infrastructure reviewable in a pull request, diffable, revertable, and repeatable across environments — and it turns tribal memory into a file somebody can read.

The second benefit is subtler and larger: a plan step. Terraform and CloudFormation both tell you what they are about to change before they change it. Reading a plan that says "will destroy: aws_db_instance.main" is the moment infrastructure as code pays for itself, and everyone gets that moment exactly once.

The comparison

	Terraform	CloudFormation	AWS CDK
Language	HCL, declarative	YAML or JSON, declarative	TypeScript, Python, Java, Go
Clouds	Any, plus hundreds of providers	AWS only	AWS only (synthesises CloudFormation)
State	A state file you own and must protect	Managed by AWS in the stack	Managed by AWS, via CloudFormation
New AWS services	Days to weeks after launch	Available immediately	Follows CloudFormation
Drift handling	plan shows differences, refresh reconciles	Drift detection, less immediate	Inherited from CloudFormation
Rollback on failure	Partial apply, you fix forward	Automatic stack rollback	Automatic, via CloudFormation
Learning curve	Moderate — HCL plus state concepts	Moderate — verbose but simple model	Steep if you do not already program
Job postings	The most requested by a wide margin	Common in AWS-only shops	Growing, still niche

When Terraform is the right answer

Most of the time, and for three concrete reasons.

It is what the market asks for. If you are learning to be employable, this decides it. Terraform appears in far more infrastructure job descriptions than the AWS-native tools, and the HashiCorp Terraform Associate is one of the three certifications worth taking early in a DevOps career.

It is one language for everything. Not just AWS: Cloudflare, Datadog, GitHub, Kubernetes, a database, your DNS. Real infrastructure is never confined to one provider, and being able to describe the whole thing in one place is worth more than any single feature.

The plan output is the best in class. Clear, diff-shaped, and fast enough to run on every pull request.

The cost of admission is the state file. Terraform keeps a record of what it believes exists, and that file is now infrastructure of its own: it must live in a remote backend such as S3 with locking, it must be protected because it contains secrets in plain text, and two people applying at once without locking is a genuinely bad afternoon. Anyone who tells you state is a minor detail has not lost one.

Our Terraform on AWS course is built around exactly that: modules, remote state, locking, plan discipline and the workflows teams actually use. If you would rather practise without an AWS bill, Terraform with LocalStack runs the same loop against a local emulator.

When CloudFormation is the right answer

When you are entirely on AWS and want fewer moving parts.

There is no state file, because AWS keeps the state inside the stack. There is automatic rollback: a failed deployment reverts to the previous known-good state instead of leaving you halfway. New AWS services appear the day they launch rather than after a provider release. And Service Catalog, StackSets and Control Tower assume it, so large regulated AWS estates often standardise on it whether or not the engineers would choose it.

The costs are equally real: YAML that grows long and repetitive, a weaker plan step (change sets are less readable than a Terraform plan), and knowledge that transfers nowhere else. Our AWS CloudFormation course covers templates, nested stacks and change sets for teams working this way.

When the CDK is the right answer

When your infrastructure has real logic in it, and your team are programmers first.

The CDK lets you write infrastructure in TypeScript or Python, with loops, conditionals, classes and unit tests, then synthesises CloudFormation from it. For a platform team producing reusable constructs — "give me our standard service, with its pipeline, alarms and dashboards" — that abstraction is genuinely powerful.

It has one failure mode worth naming: it is easy to write infrastructure code so abstract that nobody can predict what a change produces. The synthesised template is the truth, and teams that never read it eventually deploy something they did not intend. If you use the CDK, review the synthesised output in pull requests the way you would review a plan.

What about OpenTofu?

After the 2023 licence change, Terraform moved from open source to the Business Source Licence, and the community forked it as OpenTofu, now under the Linux Foundation. In practice the two remain close: the language is the same, most modules work with either, and switching is a matter of changing the binary for most teams.

What this means for a learner: nothing. Learn the language and the workflow. Whichever binary your employer runs, you already know it.

The concepts that transfer

Whatever tool you pick, these are what interviewers are actually probing, and they are identical across all three:

• Idempotence. Applying twice must not create twice.
• State and drift. What the tool believes exists, versus what actually exists, and what happens when someone changes something by hand.
• Modules and reuse. One definition, many environments, parameterised — instead of three copied folders that have quietly diverged.
• Secrets. They do not go in the repository, and in Terraform's case, remember they land in the state file too.
• Blast radius. Splitting infrastructure so a mistake in one component cannot destroy the database.
• Plan discipline. Nobody applies without reading the plan. Nobody.

Learn these once and the tool becomes a syntax question.

What to learn first, concretely

1. Terraform, for two to three weeks: resources, variables, outputs, modules, remote state with locking, and plan before every apply.
2. Build one real environment — network, compute, database, secrets — and destroy and rebuild it from zero. The rebuild is the exercise.
3. Add CloudFormation only if you work in an AWS-only shop that uses it, and give it a week. The mental model is nearly the same.
4. Add the CDK when you have a reason: a platform team, or infrastructure with real conditional logic.
5. Put it in a pipeline. Plan on every pull request, apply on merge to main, with a human approval on production. That is the workflow that gets you hired, and it is where infrastructure as code meets CI/CD.

Frequently asked questions

Should I learn Terraform or CloudFormation first?

Terraform. It appears in far more job postings, works across clouds and providers, and its core concepts — state, modules, plan and apply — transfer directly to any other infrastructure tool. Learn CloudFormation afterwards if your employer uses it, which takes about a week once you know Terraform. The Terraform on AWS course starts here.

What is the difference between Terraform and CloudFormation?

Terraform is cloud-agnostic and keeps its own state file that you must store and lock; CloudFormation is AWS-only and AWS manages the state inside the stack. CloudFormation supports new AWS services on launch day and rolls back failed deployments automatically. Terraform covers hundreds of providers and has a clearer plan step.

Is the AWS CDK better than Terraform?

Not better, different. The CDK suits teams who prefer a real programming language and are building reusable platform constructs on AWS. Terraform suits teams who want a declarative language, multi-cloud coverage and the most transferable skill. The CDK also produces CloudFormation, so it inherits both its strengths and its limits.

What is Terraform state and why does it matter?

The state file is Terraform’s record of what it believes it created, and how those resources map to your configuration. It matters because it must be stored remotely with locking so two people cannot apply at once, and because it contains secrets in plain text and has to be protected accordingly.

Is OpenTofu the same as Terraform?

Practically, yes for learners. OpenTofu is a community fork created after Terraform moved to the Business Source Licence, now hosted by the Linux Foundation. The language and workflow are the same and most modules work with either, so the skill transfers whichever binary your team runs.

Can I practise Terraform without paying for cloud resources?

Yes. LocalStack emulates most AWS services locally, so you can run the full plan, apply and destroy cycle against a container on your own machine. It is the cheapest way to build the habits before touching a real account. See the Terraform with LocalStack course.

Where to go next

Infrastructure as code only pays off inside a pipeline, so pair it with delivery: Terraform on AWS, then Jenkins and CI/CD. If you are following a longer path, the roadmap shows where infrastructure sits relative to containers, Kubernetes and cloud.