Selecting the right infrastructure as code (IaC) framework depends largely on your needs and the comfort levels of your team but can have a significant impact on your cloud-native tech stack. When looking at two common IaC frameworks—Terraform by HashiCorp and Amazon CloudFormation—there are a lot of opinions for and against each.
Like any coding language, both of these IaC frameworks have advantages and disadvantages. They also have commonalities and differences. For example, they’re both declarative in that they describe the desired outcome rather than how to reach that desired outcome. On the other hand, the way they achieve those outcomes differs. In this post, we will look at some of those commonalities and differences between Terraform and CloudFormation.
CloudFormation uses JSON or YAML (the latter typically taking preference), while Terraform uses a domain-specific language called HashiCorp Configuration Language (HCL). Because users are likely already familiar with JSON or YAML, the learning curve in getting started with CloudFormation may be flatter. That said, HCL is compatible with JSON, and it strikes a nice balance between being machine-friendly and easy for humans to read. This is just one of the differences to keep in mind when considering Terraform vs CloudFormation.
Managing the state of your resources is one of IaC’s core jobs, and the ways CloudFormation and Terraform do this are slightly different. CloudFormation stores its state with stacks managed for you out-of-the-box, making it easy to avoid conflicting changes. This is a slight advantage over Terraform that requires users to save the state in a JSON file—the tfstate file—which can be stored locally on a disk or remotely. Managing tfstate locally can cause problems in large development teams who are working in parallel when conflicts arise and multiple people attempt commits or deployments (something Terraform Enterprise solves). Whatever the case may be, tfstate files can become unruly and can cause major headaches if handled haphazardly.
A big advantage of IaC is the repeatability and modularity it brings to provisioning and building infrastructure. The easier it is to copy or reuse IaC resources, the more modular it is.
Terraform was built with precisely this in mind. Terraform modules allow for complex functions while maintaining flexible and straightforward organization. You can achieve similar functions with CloudFormation’s modules or nested stacks that can import and export configurations, but modules are newer and less developed for CloudFormation and nested stacks are a bit more cumbersome and allow for less complexity than Terraform modules.
The combination of Terraform’s modules and separate plan and apply steps make it very simple to determine exactly what is changing. On the other hand, CloudFormation’s automatic provisioning and nested stacks make it harder to drill down into all the details.
Another benefit of IaC’s version controllable and storable nature is that it allows for third-party sharing and reuse. Similar to the use of open-source packages, open-source modules make it faster for developers to get up and running without having to reinvent the wheel. HashiCorp spearheaded this advantage with the popularization of modules through the Terraform Registry, which has over 7k modules. On the other hand, AWS recently added a registry, but there are not nearly as many available offerings in that registry.
Additionally, Terraform is an open-source project which has many advantages—regular and transparent updates, extensibility, etc. CloudFormation, on the other hand, is a SaaS service offered by AWS for free. So although it is free, it is fully managed with a built-in user interface. To manage Terraform using a UI rather than CLI, you have to use Terraform Cloud, which does have a free (albeit limited) version in addition to paid, user-based plans. Each approach has pros and cons depending on your preferences or circumstances.
Each tool handles it differently when provisioning or modifying infrastructure doesn’t go as planned. CloudFormation will try to automatically roll back changes if they can’t be applied, which is an interesting feature. It will also automatically check dependencies that might break before deleting a resource. On the other hand, Terraform does not roll back in case of failure but instead stops wherever it is and follows immutability. Unlike Terraform, CloudFormation doesn’t have to be immutable—you can change some parameters without rebuilding the resource in question.
Another consideration is how drift is managed. With CloudFormation, you can automatically detect disparate changes (i.e., drift) from the console, CLI, or from your own code on an entire stack or a particular resource. It only requires minimal access, which is optimal, but if you have multiple repos and accounts, it isn’t straightforward to track the correct file associated with the drifted template.
With Terraform, it’s also relatively simple to detect configuration drift. Whenever you run ‘terraform plan,’ it compares the actual state to the desired state and the known state. If the infrastructure is out of line with the desired state, it calculates the difference and recommends bringing it back in line. This does, however, require admin-like permission, thus making it hard to grant the right access within the organization to review drifts from anywhere.
If you are working on multi-cloud projects, Terraform does have one obvious advantage as CloudFormation is explicitly built for AWS. If you are working with other cloud providers (which many of us are), you will have to branch out with platform-specific tools or with a cloud-agnostic tool such as Terraform. You can use Terraform’s AWS provider, Terraform’s Azure provider, or any other cloud provider to simplify and streamline your multi-cloud projects. Terraform touts this as a significant benefit, being able to orchestrate multiple services across providers simultaneously with a unified syntax.
Leveraging CloudFormation for your AWS projects may have some advantages since AWS itself maintains it. That means it supports new services faster and, in some instances, with more ease or depth.
In addition to differences in how Terraform and CloudFormation approach managing cloud resources, there are also different considerations, each from a security perspective. All IaC frameworks present some unique security challenges, but the opportunities to overcome those challenges are more important. Stay tuned for our upcoming article on Terraform vs. CloudFormation from a security perspective.