Infrastructure As Code: Terraform vs. AWS CloudFormation
Infrastructure-as-code, a process used to manage and provision the technology stack for an application through software, has earned significant popularity for its many benefits, from simplifying reproducibility of infrastructure environments to allowing for version control tracking of virtual hardware appliances to improvements in cost effectiveness, scaling speed and availability. Terraform and AWS CloudFormation are the two most widely used tools for implementing infrastructure-as-code on AWS, and inevitably leads to the question of “which is better?”. Of course, the answer is purely subjective and dependent on many factors.
Terraform & AWS CloudFormation
Both Terraform and AWS CloudFormation are used to define templates or configurations that describe the target state of the infrastructure you are looking to deploy. AWS CloudFormation is an AWS managed service that is designed specifically to integrate with AWS services. Terraform is an open source infrastructure as code software tool that uses a proprietary language and supports a broad range of cloud providers.
Late last year, AWS CloudFormation added the ability to import resources. As one of the biggest core features to be introduced, this ability brings far greater parity between the two solutions, making the choice between them even harder to make. Both Terraform and AWS CloudFormation offer unique features and capabilities that display strengths in different situations. As always, the best way to go is to pick the solution that best meets the needs of the job being undertaken.
One significant difference, however, comes in the degree of involvement you must have in managing the underlying method of tracking the current state of your infrastructure in order to compare it to the desired future state. AWS CloudFormation offers a completely managed state-tracking system, allowing you to focus on the code to determine the design and management of the infrastructure. Terraform, on the other hand, requires that you bring state management in-house, requiring yet another piece of infrastructure that you have to manage and ensure availability for. Although this management is not impossible and there are many guides and templates to use, and you can use open source tools such as Onica’s Runway to simplify your efforts, it is an extra step that can add complexities and potential problems in the long run.
With regard to resource types, Terraform supports a vast number of AWS resources because it is written to use the underlying AWS service APIs. Within days of a new AWS service being announced (sometimes sooner) Terraform may announce support for it. AWS CloudFormation is developed by a separate team at AWS, and requires updates to its underlying managed systems to support new AWS services. This process can be done ahead of time and a new service may launch with AWS CloudFormation support on Day 1, or it may take weeks or months before AWS CloudFormation supports these new features.
As a result of a more recent announcement, AWS CloudFormation supports a small but rapidly growing set of resource types that can be imported. These include core resources such as security groups, Amazon EC2 instances and AWS Lambda functions. Until this support, one significant issue with using AWS CloudFormation was seeing manual changes taking resources out of the code-managed infrastructure, with no way of adding them back in without destroying the deployment. And destroying the deployment is not always a practical solution, as adding back the resources and data (e.g. in an Amazon RDS instance) can be a cumbersome and daunting task. The ability to simply import resources makes it easier to start working with a proof of concept deployment, incorporate it into a development environment and retrofit the AWS CloudFormation templates to reflect that for reproducibility. This import feature makes AWS CloudFormation a more viable choice where Terraform used to be the only option.