Cloud Computing has revolutionized the world of DevOps. It is not just a buzzword anymore; it is here and it is here to change the way we develop and maintain our applications. While there are countless reasons why you should use cloud computing for all scales of businesses there is a slight limitation, you have to provision your infrastructure manually. You have to go to the consoles of your cloud providers and tell them exactly what you want. This works well for small use cases but what if you have different people making configuration changes in the console. You could end up with a super complicated infrastructure that will only become harder and harder to maintain. There is no efficient way to collaborate or keep track of the changes to the Infrastructure in the Cloud. Well, actually there is. Infrastructure as a Code. Infrastructure as a code is a very popular term in cloud computing. It is the process of managing your IT infrastructure using code. Yes, that is right. Instead of going to the console and doing everything manually; Infrastructure as a code, aka IAAC or IAC, allows you to write configuration files, which then provision your cloud infrastructure. IAC gives us the benefits like consistency, easy and fast maintenance, and no room for human errors. AWS is the leading cloud computing service in the world, having double the market share than the next cloud provider after it. There are over 200 services on AWS that can cater to hundreds and thousands of use cases. When starting to use IAC with AWS, you will often narrow down your choices to the AWS CloudFormation and the open-source tool, Terraform. When trying to make a choice between the two, understanding the multitude of features that both tools offer can be quite overwhelming. In this article, we will have a look at the differences between AWS CloudFormation and Terraform to help you decide which tool is better suited to your needs.
Terraform vs. AWS CloudFormation: Differences
Modularity
When using IAC in big organizations modularity can be a big factor for choosing the right tool.
CloudFormation
CloudFormation does not have native support for modules. It allows you to use something called nested stacks as modules. For example, you can have a standard configuration of how you want to provision an S3 bucket in your organization. So, you create a standard CloudFormation template that creates S3 buckets. Now when an end-user wants to create the S3 bucket they can use this CloudFormation template as a nested stack and create a standard S3 bucket. There is also a lesser-known service of AWS, the AWS Service Catalog that can help you with the modularity of your AWS CloudFormation. Service Catalog is an AWS service that is designed specifically for organizations that want to limit the scope of AWS Services to meet compliance, security, cost, or performance requirements. And guess what? AWS Service Catalog uses CloudFormation templates in the backend. Let us quickly understand this with an example. S3 buckets, if not used properly, can soon be catastrophic for your confidential data. Let us take the same example, you want to have a standard way of how you want to use S3 in your organization. The first option is to create the nested stack template, which can be used within other CloudFormation stacks and is equally good. If you don’t want users to have to use this standard template as a nested stack, you can use the AWS Service Catalog. Service Catalog will allow users to use this standard template from the UI of the console and specify some parameters, for slight customizations. This will allow you to control how infrastructure is provisioned in your AWS Accounts and prevent any unwanted scenarios.
Terraform
Terraform has native support for modules. It allows you to create standard configurations much like the AWS CloudFormation and use it in other terraform configurations. Since Terraform is an open-source tool you can also find and use some pre-made open-source modules in the Terraform Registry. You can also create your own modules with your own configurations and host them on a private module registry. Personally, I would prefer to use Terraform over CloudFormation if modularity was a big requirement. Using a nested stack in CloudFormation is not as easy as using modules in Terraform. The major factor being that passing data from a CFN template to the nested stack can be fairly complicated. There is no standard place where CloudFormation templates can be shared. You have the AWS Service Catalog but that is just a way for you to enforce some rules for creating infrastructure via Console. We are all about code. When using Service Catalog, although some complicated tasks are encapsulated by CloudFormation files, you still have to go through the manual task of going to the console and specifying parameters to make your Infrastructure. Terraform, on the other hand, has a set method of creating, maintaining and sharing the modules. You can see the exact requirements of the modules in the Terraform Module Registry and use them in your terraform files very easily.
Control and governance over Infrastructure
If you want to limit what resources your people can create in your AWS Accounts: Both AWS CloudFormation and Terraform provide you with the means to do so. Let us talk about CloudFormation first. CloudFormation in itself does not offer any control on how the templates are used but you can use the AWS IAM policies to only allow the users in your AWS Account to only use the standard CloudFormation templates for resource creation. In our S3 bucket example, you might want to limit all “S3 Create” permissions for users and only allow them to create S3 buckets from AWS Service Catalog or Nested Stacks. Terraform allows you to control which resources your users can create using a policy as a code tool Sentinel. Sentinel allows you to enforce fine-grained, logic-based policies to allow or deny user actions via Terraform. For example, you can deny all resources that create S3 buckets and only allow users to create S3 buckets from a standard module.
State Management
Both, AWS CloudFormation and Terraform need to keep track of the resources they are maintaining. Terraform stores the state of your infrastructure in a state file. This file is stored locally by default however you can store it on remote backends like S3 and have multiple users make changes to the same set of infrastructure. CloudFormation does not maintain a state file, at least not one that we can see. CloudFormation is a managed service so, it does all the state maintenance and checks in the background. Both, AWS CloudFormation and Terraform have a means for you to check what changes are going to be made to your infrastructure. In Terraform, you can run a command – “terraform plan” and how Terraform is planning to apply your configuration changes. In CloudFormation users can see this information via Change Sets.
Language
Terraform uses the HashiCorp Configuration Language, HCL, a language created by HashiCorp. It is very similar to JSON with additional built-in features and capabilities. CloudFormation templates are written in YAML or JSON formats
Logging and rollbacks
Both AWS CloudFormation and Terraform have good logging capabilities. In my experience, the errors and issues have been straightforward (for the most part). CloudFormation: By default, CloudFormation rolls back all your changes in case of a failed stack change. This is a good feature and can be disabled for any debugging purposes. Terraform: Terraform will not automatically roll back your changes in case it fails. This is not an issue as you can always run the terraform destroy command to delete the half-provisioned configuration and restart a Terraform run again.
Scope
Terraform is not limited to AWS Cloud. The most important factor when choosing between Terraform and CloudFormation is that Terraform supports other cloud providers and services. So if you plan to use IAC for multiple clouds platforms, Terraform is your best choice. CloudFormation, although a powerful tool, is only limited to AWS. By using Terraform you can set up infrastructure and deploy your application in multiple cloud platforms, thereby making your application more available and robust.
Feature Support
Usually, as AWS rolls out new services and features CloudFormation will be updated before Terraform, since it is an AWS Service. As of now, both tools cover most of the services and features of these services. This can be a slight drawback of using Terraform however, we do have a solution. There is also a possibility for you to create a CloudFormation stack within your Terraform code. So, if you use Terraform and it does not have a feature you can temporarily set up a CloudFormation stack inside your Terraform code.
Technical Support
The paid AWS technical support plan also covers CloudFormation support. HashiCorp has paid plans for technical support on Terraform as well.
Conclusion
Both AWS CloudFormation and Terraform are powerful and fully developed tools. The differences above will help you make an informed decision to choose the tool based on your requirements. As a personal suggestion, if you plan on using multiple cloud platforms in the future or are currently using multiple clouds you should use Terraform as a one-stop-shop for all your needs. If you are looking for an IAC tool only for AWS, both AWS CloudFormation and Terraform are fair game. If you are interested in learning Terraform, check out these online courses.
