Priyam VaidyaMany companies hesitate between 2 options when they want to deploy infrastructure as code in AWS. Let’s compare these 2 options.
Cloudformation
You can model and provision AWS and third-party application resources for your cloud environment in a secure and repeatable manner using AWS CloudFormation, a managed AWS service with a common language. This makes it possible to map and build AWS infrastructure from a single point of reference.
Many of the aspects of managing dependencies between AWS resources are removed by CloudFormation. CloudFormation also makes it much easier to version and iterate on your infrastructure because it makes it possible to modify and destroy provisioned resources in a prescribed and predictable way. CloudFormation is AWS-native and focused on AWS.
CloudFormation takes care of this for you in a controlled manner, so you don’t have to figure out which AWS services need to be provisioned or how to make these dependencies connect. You can version control your own AWS infrastructure by destroying and altering AWS resources within CloudWatch in a controlled and predictable manner after they have been deployed. When configured correctly, this makes rollback and iterative testing possible.
Terraform
HashiCorp’s Terraform is an open-source, cloud-agnostic infrastructure management tool that enables modular infrastructure configuration, enabling the integration of third-party modules and AWS modules into the same infrastructure.
Terraform boasts the capability of simultaneously running clusters composed of high-level and low-level component modules. By writing configuration files that Terraform uses to generate an execution plan to achieve the desired state of your infrastructure, you can create Terraform setups.
State Management
You must keep track of all resources under management with both Terraform and CloudFormation.
Users of CloudFormation can regularly perform drift detection on their provisioned infrastructure as a whole and receive in-depth responses if anything has changed. While some resources in a CloudFormation stack are considered immutable and will be rebuilt, others can have their parameters changed without destroying the targeted resource. Additionally, if a resource has dependencies, CloudFormation will check for them before deleting it, failing the command if any are found.
Terraform stores the infrastructure’s current state on the computer used to provide it or at a remote location (for team use). This state file is a custom JSON format that Terraform uses as a map to show which resources it manages and how to configure them.
This is done for you because CloudFormation is a managed AWS service. CloudFormation will check the provisioned infrastructure regularly to see if it is keeping that state and configuration. There is a remote state option in Terraform, which writes the state data to a remote data store so that it can be shared by all team members. Terraform stores its state on a local disk. Amazon S3 is supported by a remote state, but you must configure it yourself.
Modularity
Flexibility is essential in the ever-evolving world of infrastructure requirements. Terraform and CloudFormation each provide distinct solutions to this problem.
Modules are containers for a variety of resources that can be used together in Terraform. Similar to functions in a programming language like Ruby, modules enable developers to abstract their infrastructure into reusable, shareable code and speed up iteration for teams.
CloudFormation makes use of a technique known as “nested stacks.” Specifically, calling CloudFormation templates from within CloudFormation templates. StackSets can further abstract these nested stacks. StackSets, in addition to the normal AWS CloudFormation permissions, require additional permissions.
When compared to CloudFormation, Terraform offers more modularity and flexibility. Terraform modules can be rolled out by organizations or pulled in for any supported provider.
On the other hand, CloudFormation makes it difficult for users to provision or natively coordinate non-AWS resources in a multi-cloud or hybrid environment. It’s not impossible because CloudFormation has a feature for custom resources. However, bringing in third-party resources or AWS services that aren’t naturally available will require additional design and template work.
Configuration
Terraform and CloudFormation handle configuration and parameters in different ways.
Provider-specific data sources are used by Terraform. The modular design of the implementation makes it possible to retrieve or compute data for use elsewhere in a Terraform configuration. This permits a Terraform configuration to update or provision infrastructure using information defined outside of Terraform, such as an Elastic IP address.
CloudFormation makes use of parameters, and each template can have no more than 60 parameters. In the template, each parameter must have a logical and distinct ID. The boundaries should be of a sort upheld by CloudFormation and they must be given at the stack’s runtime. In addition, the same template must be used for declaring and referencing each parameter. If the AWS Systems Manager parameter store is properly configured, CloudFormation can use Dynamic References to retrieve parameters at runtime.
Language
HashiCorp developed the HashiCorp Configuration Language (HCL) that Terraform uses. It was designed to strike a balance between machine-friendly and human-friendly languages while remaining readable to humans. It is fully compatible with JSON.
Example of the Terraform code
JSON or YAML can be used in AWS CloudFormation, with the YAML version being slightly easier to read and smaller. The template body itself is limited to 51,000 bytes by CloudFormation as well. AWS advises developers to divide resources into nested stacks when creating a larger template.
Example of the CloudFormation code
After these distinctions have been established, let’s examine a few Mission use cases in which we utilized Terraform as a customer solution.
Rollback and Safeguard
Protection against deletion is offered by CloudFormation and Terraform. By preventing you from deleting resources that are being used as dependencies by other applications, this safeguard significantly reduces the likelihood that you will accidentally break your infrastructure!
Before modifying or deleting data stores, CloudFormation also backs them up. Your CloudFormation infrastructure may fail on occasion if you update manually. In these situations, CloudFormation will roll back your infrastructure to its previous operational state automatically.
Automatic rollbacks are not built into Terraform by default. You can manually revert to a previous configuration that worked or deploy fixes yourself. Using the command terraform plan, which outputs a list of all upcoming changes before their actual execution, you can also prevent a rollback. Terraform plan can also be used to run a dry run of an update, double-check the results to make sure that all of the changes are what you expected, and then commit your changes.
Scope
Terraform is available outside of AWS Cloud. When choosing between Terraform and CloudFormation, the fact that Terraform supports other cloud providers and services is the most important consideration.
Therefore, Terraform is the best option if you intend to utilize IAC (Infrastructure As Code) across multiple cloud platforms. Even though it is a powerful tool, CloudFormation is only available on AWS. You can deploy your application to multiple cloud platforms and set up infrastructure with Terraform, making it more robust and available.
Handling Existing Resources
Only a small number of resource types can be imported by CloudFormation. Terraform lets you import resources that already exist. Providers give you the ability to query attributes from existing resources on top of that data.
Terraform provides better support for managing existing resources.
Secrets
CloudFormation can import encrypted secrets from AWS SSM and AWS Secrets Manager. CloudFormation never stores the secret values. Terraform can read secrets from environment files and remote backends. Terraform always stores the unencrypted secret value in the state file, which presents a significant risk!
CloudFormation handles secrets like database passwords better!
Loops and Conditions
When a condition is met, CloudFormation provides first-rate support for enabling or disabling resources. CloudFormation does not natively support a loop over an array. Loops are built into Terraform and can be used to enable or disable a resource based on a set of conditions.
CloudFormation makes conditions a little easier, but Terraform is the only programming language that allows loops.
Linting
Linters for Terraform and CloudFormation are available. The CloudFormation Linter ensures that your templates adhere to certain best practices and flags numerous errors. Terraform is the same for TFLint.
When setting up AWS infrastructure using both tools, I believe that the CloudFormation Linter identifies more issues.
Feature Support
Since CloudFormation is an AWS Service, it typically receives updates before Terraform as AWS releases new services and features. The majority of these services’ features and services are currently covered by both tools. We do have a workaround for this minor disadvantage of Terraform.
Additionally, you have the option of incorporating a CloudFormation stack into your Terraform code. Therefore, you can temporarily set up a CloudFormation stack inside your Terraform code if you use Terraform but it does not have a feature.
Technical Support
CloudFormation support is also included in the paid AWS technical support plan.HashiCorp also offers paid plans for Terraform technical support.
Result — CloudFormation vs 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 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.
My personal choice when I would have to choose between Terraform and CloudFomration would be Terraform. As a multi-cloud architect, I prefer to write infrastructure in the same tool. The second reason is that the syntax of the Terraform code is more user-friendly for me than the syntax used in CloudFormation.
Add comment