As DevOps teams have sought to become more agile over the past few years, Infrastructure as Code (IaC) has become the de facto method for deploying cloud infrastructure. As a practical way to tactically automate small sets of infrastructure, it delivers on DevOps’ “need for speed”—an operational mandate to increase efficiency and agility within organizations. And indeed, the traditional method of provisioning cloud infrastructure manually (tickets, tickets, tickets!) is no longer sustainable, as it creates bottlenecks that impede the productivity of developers.
Terraform and AWS CloudFormation are two of the most popular Infrastructure as Code (IaC) tools today.
As an AWS tool, AWS CloudFormation helps users provision and manage both Amazon and third-party resources as they manage, monitor, and test infrastructure.
The open-source Terraform takes a cloud-agnostic approach to infrastructure management. As such, users can use both third-party and AWS modules in the same infrastructure.
While each helps organizations deliver applications more quickly, there are a few key distinctions between the two. Understanding these differences and how they apply to your organization may prove instructive as you refine your IT setup.
You can learn more about how modern DevOps teams are evolving how they use these tools, check out our ebook, Why Infrastructure as Code Tools are Not Enough.
Jump to a section to learn more:
- Multi-cloud support
- State management
- Rollbacks and safeguards
- Code syntax
- Usable functions
- Management and governance
- Multi-tech support
- Cloud cost control
Using modules, developers can break up their infrastructure into reusable code, which increases their velocity.
While Terraform used to be the one tool that provided support for modules, AWS has offered support for AWS CloudFormation modules for the past several years.
However, Terraform modules can be used for any supported provider, whereas AWS doesn’t offer such flexibility in provisioning non-AWS resources (additional templating and design is necessary).
In fact, support across cloud service providers is a key distinction between these two tools.
While Terraform is cloud-agnostic, allowing users to user their cloud provider of choice, AWS CloudFormation is largely restricted to AWS services. Granted, AWS users can deploy to others, but the support is not native to AWS.
Terraform can store an infrastructure state remotely or on disk. Users create states with JSON configuration files that detail how the infrastructure resources will be provisioned.
State management for AWS CloudFormation resources occurs automatically, with resources bundled into stacks. These stacks are tied to dependencies, such as applications. Therefore, when you change an application, the stack is also modified. This saves the users from performing a more labor-intensive modification.
To protect work that is not yet finalized, Terraform offers users the option to view changes before they are executed. Additionally, users can review their proposed output before finalizing any changes.
AWS automates the deletion protection process, as it backs up data before it performs a deletion or modification. If a user experiences an infrastructure fail, AWS automatically reverts things to its last stable state. Additionally, with its ChangeSets feature, developers can preview changes before they are executed, future-proofing their work from unexpected end user issues.
This is a functional distinction: AWS users write YAML and JSON-based templates, whereas Terraform users write HCL, a language that is fully compatible with JSON. Some users find HCL easier to learn.
Terraform users can access different types of functions within their code, including string manipulation, encoding, and filesystem—to name just a few. AWS CloudFormation offers far fewer functions and requires users to create custom resources that deliver the desired functionality.
When considering the best way to use IaC tools, it’s important to consider what you need to deliver infrastructure rapidly.
For many developers and DevOps teams, applications require increasingly complex environments to support various stages of the development process.
In many cases, this means that no single IaC tool will resolve all their challenges with infrastructure.
Here are a few considerations to keep in mind.
Neither Terraform nor AWS CloudFormation alone offers the kind of management and governance that modern DevOps teams need.
While the decentralized nature of IaC helps DevOps people assemble infrastructure more quickly, the volume of these files can quickly get out of control. This makes it hard to ensure any required updates to infrastructure or configurations are applied to all IaC assets in use, track down the files that need to be updated, or control who can make changes to the IaC assets.
Our users solve these problems by automatically discovering all folders and IaC files within an asset repository (GitHub, GitLab, and Bitbucket) and importing them into auto-generated blueprints for ready-to-launch application environments. Devs can then launch these blueprints on-demand via self-service when needed.
Admins can then set governance policies for the environments deployed from these blueprints, such as restrictions on instance sizes or maximum duration so an environment shuts down automatically when no longer needed.
The blueprint also provides a central place to monitor and notify admins about drift within the infrastructure or configurations their teams are using. Updates made at the blueprint level will then apply to all environments that their teams launch thereafter.
Naturally, governance challenges are compounded as teams and applications rely on several infrastructure assets from multiple different IaC tools.
As applications become more complex, DevOps teams increasingly find themselves building environments with assets from Terraform, AWS CloudFormation, and other similar technologies, such as Helm or native Kubernetes. Since these technologies were not designed to interact with one another, deploying and maintaining environments can become tedious and complex.
Torque users import the individual infrastructure components for a unique environment into a control layer, which is powered by a Kubernetes cluster or public cloud account to run commands to operate the environment.
The control layer configures the complete multi-tech environment automatically, with the ability to deploy as many times as needed.
Simple misconfigurations and operational oversights are responsible for some of the biggest contributors to unnecessary cloud costs.
Neither Terraform nor AWS CloudFormation prevent end users from deploying infrastructure using cloud instances that are larger—and therefore more expensive—than needed for the application. Similarly, these tools don’t preventing DevOps admins from leaving an environment running for a full week when it’s only needed for a one-hour function.
Our users pre-configure templates for their environments with the right cloud instances for the right workload and set maximum durations so these environments shut down after a pre-determined period of time.
Policies can prohibit users from deploying cloud instances that are large or more expensive than needed, while role-based access controls restrict unauthorized users from changing these settings.
To learn more about how modern DevOps and IT teams are provisioning infrastructure, read our eBook, “Why Infrastructure as Code Tools are not enough.”