Infrastructure as Code: Terraform vs AWS CloudFormation

Two well-known Infrastructure as Code (IaC) solutions for allocating and managing cloud resources are Terraform and AWS CloudFormation. Their scope, language, and state management are where they diverge most.

Scope:

• AWS CloudFormation: Exclusively designed for AWS, offering deep integration with AWS services and features.
• Terraform: A cloud-agnostic tool supporting multiple cloud providers (AWS, Azure, Google Cloud, etc.) and on-premises environments through various providers.

Configuration Language:

• AWS CloudFormation: Uses JSON or YAML templates for defining infrastructure resources.
• Terraform: Utilizes HashiCorp Configuration Language (HCL), which is designed for human readability and offers features like variables, loops, and conditionals.

State Management:

• AWS CloudFormation: Manages the state of your infrastructure internally within AWS, tracking resource creation, updates, and deletions.
• Terraform: Requires external state management, typically using backends like Amazon S3 or HashiCorp Consul, where it stores the desired and actual state of your infrastructure. This offers more control but also places responsibility on the user for state file integrity.

Resource Lifecycle:

• AWS CloudFormation: Follows a create-update-delete lifecycle for managing stacks.
• Terraform: Employs a plan-apply workflow, where a plan is generated to show proposed changes before they are applied to the infrastructure.

Community and Ecosystem:

• AWS CloudFormation: Benefits from AWS’s official support and documentation, with a community focused on AWS users.
• Terraform: Boasts a large and active open-source community, contributing to a vast ecosystem of providers and modules for various services.

Drift Detection:

• Both tools offer drift detection capabilities to identify discrepancies between the defined configuration and the actual deployed infrastructure.

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 it’s 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 & 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: New versions of Terraform are placed under the BUSL license, but everything created before version 1.5.x stays open-source. OpenTofu is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.

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.

Comparing Key Features

The idea behind AWS CloudFormation and Terraform is a stack, which is a collection of cloud components that administrators oversee as a deployment unit. Applications, environments, and any other grouping that is pertinent to a specific organization can be arranged using stacks. Cloud resources unique to the kind of cloud components that launch are defined by parameters. Both technologies make use of launch-related dynamic characteristics, such as launching distinct Amazon EC2 instance types for a development environment and a production environment.

To find their use cases, let’s examine some of the main features of both programs in more detail. The following will be our main focus:

Modularity

Modularity is the ability to create common components for reuse across multiple deployments. AWS CloudFormation offers the modules feature, which are building blocks that complement common registries. Administrators can reuse them across multiple stacks within a single account or across multiple AWS accounts.

Terraform has a similar feature, also called modules. It reuses common configurations and manages them either locally or remotely in custom registries or Git repositories.

Template customizations

Terraform provides a wider range of built-in functions for template customization compared to AWS CloudFormation. In many cases, it’s useful to apply dynamic configurations to a stack based on conditions and custom logic. Terraform offers more flexibility given the narrow range of AWS CloudFormation built-in functions. However, AWS CloudFormation offers built-in integration with custom Lambda functions — built by the stack owner — that can perform complex logic during stack updates.

Scalability

CloudFormation and Terraform stacks can manage up to 500 resources, which is sufficient for most large cloud infrastructure deployments. If a particular deployment exceeds this limit, one alternative in either platform is to launch multiple stacks. CloudFormation also offers the nested stack feature, with a limit of 2,500 resources.

Read Also: AWS vs Azure vs Google Cloud: A Detailed Comparison

The amount of time it takes to launch multiple resources can be similar in both tools, but it can vary significantly depending on the type and number of resources users must manage. While some deployments in either platform can take a few seconds to complete, there are situations where they can take several minutes. A key factor in CloudFormation launch time is the interdependency of resources, which results in a sequential launch of these components and potentially a longer launch time.

Failure handling

It’s not unusual to face situations where updates aren’t applied for various reasons, ranging from incorrect configurations to external failures. AWS CloudFormation delivers a reliable failure handling mechanism that enables developers to either keep, update or roll back resources in an unsuccessful stack creation or update. Terraform doesn’t offer a native rollback feature, which means developers must specifically apply the next steps to either remove or update the affected resources.

AWS CloudFormation’s change sets provide developers with a high-level visualization of resource updates before application. They can then either continue or cancel the operation. Terraform has a similar command called plan, which reduces the likelihood of applying unwanted, potentially destructive updates to a stack.

Support

One important difference between these two IaC tools is that Terraform supports multiple cloud providers, such as AWS, Azure, Google Cloud, Oracle and Digital Ocean, while CloudFormation only supports AWS. For a multi-cloud approach, consider Terraform. Keep in mind that each cloud provider requires a different set of parameters and configurations that users need to specify in Terraform, which could result in a complex set of templates.

Given that Terraform is not a cloud provider tool, new features in a particular platform are not necessarily available in Terraform. In the case of AWS, CloudFormation has a shorter time frame before new AWS features and services are available for launch using IaC, compared to Terraform. When using CloudFormation, there’s the option to engage AWS support for any potential issues. Terraform doesn’t offer direct support from cloud providers, just from Hashicorp and online communities.

DevOps

IaC is an essential component in a DevOps strategy. Integrating cloud infrastructure updates into the code management process delivers critical visibility into how infrastructure deploys, as well as launch and test automation, troubleshooting and rollback strategies in case of failure.

Given the potentially disruptive nature of infrastructure updates, it is important to implement manual approval processes for certain infrastructure updates. Terraform’s plan command and CloudFormation’s change sets are critical components in this process.

Both Terraform and CloudFormation deliver a similar level of integration with CI/CD pipelines and DevOps processes. Users can trigger them from pipelines in common Git repositories, such as GitLab, BitBucket or GitHub, or from AWS services such as CodePipeline or CodeBuild.

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, while 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

Dynamically creating and configuring resources is a powerful feature that Terraform provides that CloudFormation currently cannot match within its standard features. AWS does offer an extension to CloudFormation called the Serverless Application Model (SAM), as well as an entirely separate tool called the AWS Cloud Development Kit (CDK), but in this case, we are focusing on standard CloudFormation features. 

The Terraform count and Terraform for_each functionality allows you to create logic to create a resource multiple times dynamically. Furthermore, you can dynamically configure your resource using the dynamic block feature. AWS CloudFormation, on the other hand, is much less dynamic and more explicit. With CloudFormation, you will need to define a given resource multiple times (or modularize the resource and call the given module numerous times) to create resources repeatedly.

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 is extremely limited, providing less than 15 intrinsic functions in total. The lack of helper functions can lead to annoying, complicated situations 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, and CloudFormation doesn’t incur that much cost ($0.0009 per handler operation + $0.00008 per second for handler operation duration after the first free 30 seconds), but you will need to pay the cost of the resources you are spawning with them.

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.

The table below summarizes the key differences between Terraform and AWS CloudFormation:

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.

While, for this scenario, both Terraform and CloudFormation can be used, CloudFormation will have the upper hand as most features are included as soon as they are live into Cloudformation.

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.

While both tools can work, AWS CloudFormation is more suited for the job, as 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.

Final Thoughts

It is crucial to assess how each tool would interface with any current CI/CD pipelines and pinpoint any potential benefits or problems. One thing to keep in mind is that Terraform provides a more straightforward method for integrating sophisticated custom logic into a template.

Another important factor to consider is multi-cloud capability versus AWS-only technology. While CloudFormation will only support AWS, Terraform will make it easier to install cloud infrastructure components in a multi-cloud company. CloudFormation is probably the best option if an organization’s infrastructure is launched solely on AWS and there are no immediate plans to leverage other cloud platforms. Given that it is a product built by AWS, it will be eligible for AWS Support, and it will likely deliver more useful features for AWS components.