How do Terraform and CloudFormation differ? Terraform is multi-cloud and uses HashiCorp Configuration Language (HCL), whereas CloudFormation is AWS-native and uses JSON or YAML. Terraform is generally preferred for complex, cross-platform infrastructure management, whereas CloudFormation is optimal for teams operating solely within AWS.
In this blog post, we will be comparing these two most common Infrastructure as Code options, Terraform and AWS CloudFormation, and outlining some of the key differences between them.
We will cover:
- What is Terraform?
- What is AWS CloudFormation?
- Differences between Terraform and AWS CloudFormation
- Terraform and AWS CloudFormation use cases
- Can Terraform and CloudFormation be used together?
- Automating Infrastructure as Code with CloudFormation and Terraform
- Should you use Terraform over CloudFormation?
How we compared these platforms
We aim to make our recommendations practical and vendor-neutral. We based this comparison on each vendor’s public documentation and pricing pages, hands-on experience using both tools, and the dimensions that matter most in practice.
What is Terraform?
Terraform is an Infrastructure as Code tool created by HashiCorp. Terraform utilizes a syntax called the HashiCorp Configuration Language (HCL), which allows users to define their infrastructure programmatically.
One of the most notable benefits of Terraform is that it provides the ability to deploy resources to multiple cloud providers, which makes it dare I say – “cloud agnostic.”
Although the term cloud-agnostic is often used when discussing Terraform, just because you are using Terraform doesn’t automatically make you “multi-cloud” or any more cloud agnostic than if you were using AWS CloudFormation. This is because you won’t be able to re-use the same code you’re using for one cloud provider (e.g., AWS), to deploy resources to another cloud provider (e.g., Azure). Instead, you’ll end up creating code specifically for each cloud provider.
In addition to the “multi-provider” support that Terraform provides, there are other benefits to consider as well, such as its ability to dynamically create resources using its for_each or count features and the ability to dynamically configure properties of a resource with the dynamic block functionality.
Additionally, Terraform supports built-in functions that can be called and used within your code, which become very useful for everyday tasks.
Providers and resource types
Speaking of providers, Terraform itself has the concept of “providers”, which you’ll need to define and configure within your code explicitly. The provider configuration is where you specify things like how you are authenticating into a particular AWS account and what region will be used for the resources you’re trying to deploy. When using a provider, each provider has its selection of “resource types”, which are the literal items you define your code to create.
These resource types are typically cloud resources; for most folks, that’s what we are ultimately looking to define and deploy at the end of the day. When deploying resources, you’ll find that the provider name is embedded within the resource type name for a given resource, which helps users understand what provider they are currently using.
For example, if you were looking to create an Amazon S3 Bucket, you would be using the aws_s3_bucket resource type. Based on this naming being prefixed with aws_, you can tell that this resource type is within the aws provider. Pretty convenient, right?
Most useful Terraform features
Terraform features include:
- Support for virtually any cloud provider and other platforms through Terraform providers
- Declarative configuration using HashiCorp Configuration Language (HCL)
- Execution plans – see what is going to happen to your infrastructure resources before actually applying the changes
- Resource graph – build a graph of all your resources and identify the dependencies between them
- State management – tracks the state of your infrastructure, making it easy to determine what kind of changes have to be made to your infrastructure
- Loops, conditionals, and dynamic blocks for reusability
- Strong community and ecosystem
Note: Terraform’s licensing changed in August 2023. Releases after version 1.5.x use the Business Source License (BSL) 1.1 (sometimes written BUSL), a source-available license that is not open source. Everything up to and including 1.5.x stays under the open-source Mozilla Public License (MPL) 2.0. In February 2025, IBM completed its acquisition of HashiCorp, so Terraform’s commercial development and support now sit inside IBM.
If you want a fully open-source path, OpenTofu is a community-driven fork of Terraform (forked from version 1.5.6) that is production-ready and governed by the Linux Foundation. For the full story, see our Terraform license change guide.
What is AWS CloudFormation?
AWS CloudFormation is an AWS service that is designed specifically for provisioning AWS resources. You have a choice of using either YAML or JSON syntax for writing your AWS CloudFormation code, both of which are natural choices for many users.
Given AWS CloudFormation is AWS’s native language and service for infrastructure as code, you will likely find more official quickstarts provided by AWS in the language. In addition to this, AWS Support will probably be more capable of assisting you with issues when you need help. AWS Support is essential for large enterprises, particularly those new to the cloud or slow to adopt. These types of organizations may have a skill gap within their organization regarding their cloud skill set, and in turn, they are more likely to use AWS Enterprise Support.
Historically speaking, one of the primary reasons users would pick a tool such as Terraform over CloudFormation was the lack of support for modules. When using AWS CloudFormation, you previously needed to utilize nested templates to achieve re-usable code – and may still follow this approach today.
Fortunately, though, in November 2020, AWS introduced support for AWS CloudFormation modules, allowing for a new way to create re-usable code. There are, of course, other significant differences between the two languages, which we will be exploring in the following section.
Read more: What is AWS Cloudformation?
Most useful CloudFormation features
CloudFormation features include:
- AWS support
- YAML/JSON templates to define your AWS infrastructure
- Execution plans via Change Sets
- Custom resources – allows you to integrate third-party resources and APIs into your CloudFormation-managed infrastructure
- Rollback and automatic resource deletion
- Cross-region and cross-account deployment
Differences between Terraform and AWS CloudFormation
The main difference between Terraform and AWS CloudFormation is that Terraform is a cloud-agnostic infrastructure as code tool that supports multiple providers, whereas AWS CloudFormation is a native AWS service designed specifically for managing AWS resources.
Let’s dive deeper.
1) Code syntax
The syntax between Terraform and CloudFormation is probably the most apparent major differentiator, as many users are already familiar with writing YAML and JSON-based templates compared to Terraform’s HCL syntax.
Granted, many users find HCL reasonably straightforward to learn.
2) Learning curve
The learning curve for Terraform can be considered moderate, as it has straightforward syntax and support for multiple cloud providers. However, understanding its state management, modules, and provider ecosystem can take some time. Terraform’s approach to infrastructure as code across multiple clouds (not just AWS) means learners also need to grasp provider-specific nuances.
For CloudFormation, the learning curve might be steeper for those not familiar with JSON’s strict syntax. However, for users already deeply integrated into the AWS ecosystem, learning CloudFormation could feel more natural as it is designed specifically for AWS resources and services. The integration with AWS services means that users need to understand AWS offerings and how they interact.
3) Dynamic features
Terraform makes dynamic resource creation a first-class part of the language. With count and for_each, you can create a resource multiple times from a single block, and the dynamic block lets you generate nested configuration on the fly.
CloudFormation used to have no answer to this. That has changed. CloudFormation now supports a native looping function, Fn::ForEach, through the AWS::LanguageExtensions transform. You can use it to replicate resources, properties, conditions, and outputs from a collection instead of copying blocks by hand.
The capability gap has narrowed, but the experience still differs. Terraform’s for_each and count read cleanly and work everywhere in the language. CloudFormation’s Fn::ForEach requires the language extensions transform, leans on JSON or YAML syntax, and feels heavier for complex cases.
AWS also offers the Serverless Application Model (SAM) and the separate Cloud Development Kit (CDK) if you want richer programmatic constructs, but here we are comparing standard CloudFormation. For teams that provision many similar resources, Terraform’s dynamic features are still the more comfortable fit.
4) Usable functions
The ability to use built-in functions within your code can have tremendous benefits.
In Terraform, you have access to many different types of functions. A few example categories of Terraform functions include numeric, string manipulation, encoding, date/time, and filesystem – and this is not the complete list!
In comparison, CloudFormation offers a small set of intrinsic functions, around 15 in the base language (the AWS::LanguageExtensions transform adds a few more). The limited helper library can lead to complicated workarounds for basic tasks.
For example, if you’re simply looking to obtain the date or time within your CloudFormation template, there’s no built-in function for this. Instead, you’ll need to create a custom resource within your template that calls a lambda function that returns the information you need.
5) State management
When using Terraform, users will be quickly introduced to the concept of “state.” Terraform state represents stored information about your deployed infrastructure and configuration (a list of what resources have been created).
This “state” is a file created once you run the terraform apply command to deploy the resources you defined in your code. You’ll need to come up with a process for maintaining your Terraform state file, whether that’s storing it in an Amazon S3, utilizing Spacelift’s managed state feature, or other means. The default functionality of Terraform is to keep your state locally, which is problematic when attempting to use Terraform collaboratively.
With AWS CloudFormation, this is simply something you don’t have to worry about, as CloudFormation deployments are represented within the CloudFormation service as a “stack” – showing the deployment result/events of the resources that were created/updated/deleted based on the CloudFormation template you deployed.
6) Cloud providers
AWS CloudFormation, as the name suggests, is specific to Amazon Web Services. You can theoretically achieve deployment to third-party resources through the use of custom resources, but this is rather hacky, and at the end of the day, those third-party resources are not truly supported by CloudFormation.
On the other hand, Terraform allows you to deploy to other cloud providers as well. Granted, you won’t be able to re-use the same codebase from one cloud provider to another. At the very least, when using Terraform, you’ll have familiar syntax and methods for deploying to different cloud providers. For some companies, this is a significant benefit, as being able to use the same syntax and deployment methods to deploy to multiple cloud providers is a clear plus.
7) Community and documentation
Being provider-agnostic gives Terraform the edge when it comes to community. Many organizations contribute modules and providers to the ecosystem, but sometimes, this means that documentation can be as good as the provider’s documentation itself.
CloudFormation has an active AWS community, that is smaller when compared to Terraform’s. The documentation is very thorough but can be overwhelming. Integration with AWS-specific features and services is well-documented, which is beneficial for users fully committed to the AWS ecosystem.
8) Cost
Terraform is free to run. CloudFormation is also free for native AWS resources: you pay only for the resources you provision. The one exception is third-party or registry resource types and custom Hooks, which carry a small charge per handler operation ($0.0009 per operation, plus $0.00008 per second after the first free 30 seconds), with the first 1,000 handler operations each month included at no cost.
For most teams provisioning standard AWS resources, CloudFormation itself adds nothing to the bill.
9) Enterprise support
If your organization uses AWS Enterprise Support, this certainly provides peace of mind knowing that AWS can assist you directly when/if you have issues with your AWS CloudFormation.
This is in comparison to Terraform, where you can also obtain support from HashiCorp directly or through the open-source community. For users that are all-in on AWS, the ability to have native knowledgeable support for your infrastructure as code tool is a significant benefit.
Since IBM completed its acquisition of HashiCorp in February 2025, Terraform’s commercial support and roadmap now sit within IBM, which may matter to organizations that already have an IBM or Red Hat relationship.
Terraform vs CloudFormation table comparison
The table below summarizes the key differences between Terraform and AWS CloudFormation:
| Feature | Terraform | AWS CloudFormation |
| Code syntax | HCL (concise, modular) | YAML/JSON (verbose) |
| Learning curve | Moderate (Multicloud concepts, state handling) | Steep for beginners; easier for AWS users |
| Dynamic features | Native count, for_each, and dynamic blocks | Fn::ForEach via the AWS::LanguageExtensions transform; less ergonomic |
| Usable functions | Large built-in function library | Small set of intrinsic functions (around 15 in the base language) |
| State management | Manual; uses a state file (can be remote) | Fully managed by AWS as stacks; no file handling |
| Cloud providers | Multicloud (AWS, Azure, Google Cloud, etc.) | AWS only |
| Community & docs | Large community, Terraform Registry | Strong AWS docs; smaller community |
| Cost | Free core; paid HCP Terraform and Terraform Enterprise tiers | Free for AWS resources; small charge for third-party or registry resource types and Hooks |
| Enterprise support | HashiCorp (IBM) paid tiers | Covered under AWS Support plans |
| Licensing | BSL 1.1 after v1.5.x (source-available); MPL 2.0 up to v1.5.x | Free service from AWS |
| Ownership | HashiCorp, part of IBM since February 2025 | Amazon Web Services |
| Open-source alternative | OpenTofu (Linux Foundation fork) | None directly; CDK and SAM are AWS-native |
Terraform and AWS CloudFormation use cases
In this section, we will tackle four real-life scenarios and see why Terraform/Cloudformation is the better choice.
Scenario 1: Multi-cloud and GitHub resource management
A company is using multiple cloud providers (AWS, Microsoft Azure, and Google Cloud) and also wants to manage everything related to their GitHub organization through an IaC tool.
For this scenario, if you want to use a single tool that can do everything you need (manage infrastructure from multiple cloud providers + GitHub resources), the only viable option between the two will be Terraform, as it has dedicated providers for all of the providers plus a dedicated provider for GitHub.
Scenario 2: Deep AWS integration
A company is very invested in AWS, using a bunch of AWS services and requiring the most up-to-date integrations and features.
Although both Terraform and CloudFormation can be used here, CloudFormation has the upper hand, because most features are available in CloudFormation as soon as they go live.
Scenario 3: Mass environment provisioning with reusability
A company needs to build hundreds of environments that have a similar template (just some variables change).
For this scenario, through the modules and the ability to take advantage of loops, conditionals, and a bunch of functions, Terraform is the winner.
Scenario 4: Enterprise-grade AWS architecture with compliance needs
A company has a very complicated AWS Architecture that involves intricate IAM roles, VPC configurations, and direct connections, with a need for strict compliance and governance structures.
Although both tools can work, AWS CloudFormation is more suited for the job, because its direct integration with AWS services ensures that configurations adhere closely to AWS’s recommended practices, making it easier to meet strict enterprise governance requirements.
Can Terraform and CloudFormation be used together?
You can use Terraform and AWS CloudFormation together, but it wouldn’t be the smoothest workflow. Using them together might be considered in specific scenarios where their features complement each other or when transitioning from one tool to the other.
Terraform allows you to create CloudFormation stacks using the aws_cloudformation_stack resource, so calling the entire workflow from Terraform would make perfect sense. This is especially useful in environments where different DevOps or Platform teams prefer different tools due to their expertise or historical reasons.
Automating Infrastructure as Code with CloudFormation and Terraform
So by now, you know that you have a variety of infrastructure as code tools to choose from, with the two most common being AWS CloudFormation and Terraform, but these tools all inevitably bring about new problems that can be difficult to solve.
Most organizations will initially go down the path of building their own custom tooling or scripts around their IaC deployments, but will eventually discover that these custom-built tools often don’t scale, struggle to meet compliance requirements, and carry ongoing maintenance overhead.
On top of that, if you use more than one IaC tool, you have to build multiple tools yourself or further complicate the custom tool you are already trying to maintain.
Fortunately, there is a platform that solves these problems and provides additional benefits, such as compliance, reliability, and scalability. Spacelift is the most flexible infrastructure orchestration platform and was purpose-built for this use case.
Spacelift supports multiple IaC tools, including AWS CloudFormation and Terraform, along with OpenTofu, Terragrunt, Pulumi, Ansible, and Kubernetes, so you can standardize your deployment processes and compliance requirements across all of them. It also includes capabilities you would otherwise have to build yourself, such as policy as code for access controls and approvals, drift detection, self-service workflows, and stack dependencies that span your IaC tools.
And with Spacelift Intelligence, your team can design, deploy, and understand infrastructure through natural language, while your policies still apply to every change.
If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.
Pomelo’s initial approach to managing Terraform was not up to the task of accommodating the needs of a rapidly expanding company. Now that they use Spacelift, they can rely on a specialized platform for infrastructure as code (IaC) that will adapt to their needs as they scale and provide a cost-effective alternative to largely manual processes.
Should you use Terraform over CloudFormation?
The battle of Terraform vs. CloudFormation is poised to be an ongoing debate. At the end of the day, this is a decision for you to make based on your preferences between the two tools.
If having native support from AWS is essential to you, then perhaps you should consider AWS CloudFormation. If you enjoy the dynamic features that Terraform provides, such as count and for_each, maybe Terraform is best.
Is Terraform better than CloudFormation?
Terraform is better than CloudFormation in many use cases, but at the same time, if your infrastructure is exclusively on AWS and you always need to keep the latest updates for the services you use, or if you need to build complex AWS architectures, CloudFormation can be a very sensible choice.
Where does OpenTofu fit?
Any Terraform comparison has to mention OpenTofu. When Terraform moved to the BSL, a group of users and vendors forked the last open-source release (version 1.5.6) and created OpenTofu, now governed by the Linux Foundation. It keeps HCL, the provider model, and the plan-and-apply workflow, so most Terraform configurations run on it with little or no change.
For this comparison, treat OpenTofu as the open-source path that behaves like Terraform. If your reason for considering CloudFormation is discomfort with Terraform’s license rather than a need for AWS-native tooling, OpenTofu is the more direct answer.
Spacelift supports Terraform, OpenTofu, and CloudFormation, so you are not locked into one choice. Learn more on our OpenTofu page.
Key points
At the end of the day, though, why restrict yourself to one infrastructure as code tool if you can use the benefits of both? There’s nothing wrong with using multiple infrastructure-as-code tools, especially if your IaC automation tool can support this.
If you want to learn how other tools compare to Terraform, see our Terraform vs. Kubernetes article and 10 popular Terraform alternatives.
Solve your infrastructure challenges
Spacelift is an infrastructure orchestration platform built for IaC. It brings collaboration, automation, and governance into a single workflow, so your team can provision cloud infrastructure faster without losing control.
Frequently asked questions
Is Terraform better than CloudFormation?
Neither tool is universally better. Terraform wins when you work across multiple clouds, manage non-AWS resources such as GitHub or Datadog, or provision many similar resources dynamically. CloudFormation wins when you are all-in on AWS, want the newest AWS features the day they ship, and prefer a fully managed service with no state file to maintain.
Who owns Terraform?
Terraform is built by HashiCorp, which IBM acquired in February 2025. Terraform’s commercial products and support now sit within IBM.
Is CloudFormation free?
Yes, for native AWS resources. You pay only for the resources you provision. Third-party or registry resource types and custom Hooks carry a small per-operation charge, with the first 1,000 handler operations each month free.
