AWS Cloud Formation Vs Terraform

Infrastructure as code [IaC] is a buzzing word these days, and it’s no mystery why. IaC, referred to as software-defined infrastructure, is defined as an IT setup wherein developers or operations teams automatically manage and provision the technology stack for an application through software, rather than using a manual process to configure discrete hardware devices and operating systems. Infrastructure as Code addresses these deficiencies by bringing automation to the provisioning process. Rather than relying on manually performed steps, both administrators and developers can instantiate infrastructure using configuration files

Benefits of using IAC

· Cost-Reduction

· Speed of Execution

· Reduced Risk

When people look for tools to implement infrastructure as code on AWS, they often narrow the choice between AWS CloudFormation or the open-source tool Terraform. Let’s review the differences between the two so you can determine which is right for your needs.

CloudFormation

AWS CloudFormation provides a common language for you to model and provision AWS and third party application resources in your cloud environment. AWS CloudFormation allows you to use programming languages or a simple text file to model and provision, in an automated and secure manner, all the resources needed for your applications across all regions and accounts. This gives you a single source of truth for your AWS and third party resources.

Terraform‍

Created by HashiCorp, Terraform is an open-source infrastructure-as-code software tool that helps users with the task of setting up and provisioning datacenter infrastructure. A cloud-agnostic tool, Terraform codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.

Now that we’ve defined these two IaC platforms, let’s review some of the key differences in more depth.

Working Environment

Terraform is cloud agnostic, works with several cloud providers including Azure, GCP etc.

CloudFormation is AWS specific and provides tight integration by AWS tools.

If you are working with multi-providers then Terraform sails your boat.

State Management

CloudFormation, users can perform regular drift detection on their entire provisioned infrastructure, and receive detailed responses if anything has changed. Some resources in a CloudFormation stack are able to have parameters changed without destroying and rebuilding the targeted resource, while others are considered immutable and will be rebuilt. Additionally, before CloudFormation will delete a resource, it will determine dependencies and fail the command if any exist (which would remain after resource removal).

Terraform stores the state of the infrastructure on the provisioning computer, or in a remote site (for team use). This state file is a custom JSON format which serves as a map for Terraform, describing which resources it manages, and how those resources should be configured.

Modularity

Terraform has a modules, which are containers for multiple resources that are used together. Modules allow developers to abstract their infrastructure into reusable, shareable code and increases iteration speed for teams (much like functions do in a programming language like Ruby).

CloudFormation utilizes a system called “nested stacks.” That is, CloudFormation templates being called from within CloudFormation templates. These nested stacks can further be abstracted into StackSets. It should be noted that StackSets require additional permissions, beyond those of normal AWS CloudFormation.

Configuration

Terraform uses provider specific data sources. The implementation is in a modular fashion, allowing data to be fetched or computed for use elsewhere in a Terraform configuration. This lets a Terraform configuration make use of information defined outside of Terraform (such as an Elastic IP address), to update or provision infrastructure.

CloudFormation uses parameters, and has a maximum of 60 parameters per template. Each parameter must have a logical and unique ID among all others in the template. The parameters must be of a type supported by CloudFormation and they have to be provided at the stack’s runtime. Additionally, each parameter must be declared and referenced from within the same template. CloudFormation does have the capability to use Dynamic References to retrieve parameters at runtime from AWS Systems Manager parameter store, if one has been configured properly.

Language‍

Terraform uses HashiCorp Configuration Language (HCL), a language built by HashiCorp. It is fully compatible with JSON, and was created to strike a balance between human-friendly and machine-friendly languages, while remaining interpretable to humans.

AWS CloudFormation utilizes either JSON or YAML, with the YAML version being slightly easier to read (as well as more compact). CloudFormation also has a limit of 51,000 bytes for the template body itself. If a larger template is needed, AWS advises developers to separate resources into nested stacks.

The Bigger Picture — CloudFormation or Terraform‍

Both are powerful cloud infrastructure management tools. If you’re already on AWS and using all AWS tools, CloudFormation may be more convenient, especially if you have no external tie ins from 3rd parties. However, if you’re looking for additional flexibility from a cloud-agnostic platform that integrates with AWS services (and those of all other popular providers), Terraform might be of greater utility for your organization. It’s important to not only look at what is working currently — but what the future state of any infrastructure might be. There are long-term benefits with both toolsets, and the final decision may come down to simple usability and developer comfort.