UPDATE: AWS Cloudformation now supports YAML. To be sure, this is a huge improvement over JSON in terms of formatting and use of comments. This will also simplify windows and linux userdata scripts. So for teams that are just starting with AWS and don’t need any of the additional benefits of Terraform, YAML would be the best place to start. Existing teams will likely still have a cache of JSON templates that they will need to recreate and should consider whether the other benefits of Terraform warrant a move away from CFT.
If you’re familiar with AWS CloudFormation Templates (CFTs) and how they work but have been considering Terraform, this guide is for you. This basic guide will introduce you to some of the advantages and disadvantages of Terraform in comparison to CFT to determine if you should investigate further and try it yourself. If you don’t have a rudimentary familiarity with Terraform, head over to https://www.terraform.io/intro/index.html for a quick overview.
Advantages
Formatting – This is far and away the strongest advantage of Terraform. JSON is not a coding language, and it shows. It’s common for CFTs to be 3000 lines long, and most of that is just JSON braces and bracket. Terraform has a simple (but custom) HCL for creating templates and makes it easy to document and comment your code. Whole sections can be moved to a folder structure for design and clarity. This makes your infrastructure feel a bit more like actual code. Lastly, you won’t need to convert Userdata bash and PowerShell scripts to JSON only to deploy and discover you forgot one last escaping backslash. Userdata scripts can be written in separate files exactly as you would write them on the server locally. For an example, here’s a comparison of JSON to Terraform for creating an instance:
Instance in CFT
"StagingInstance": {
"Type": "AWS::EC2::Instance",
"Properties": {
"UserData": {
"Fn::Base64": {
"Fn::Join": ["", [
"#!/bin/bash -v\n",
"yum update -y aws*\n",
"yum update --sec-severity=critical -y\n",
"yum install -y aws-cfn-bootstrap\n",
"# download data and install file\n",
"/opt/aws/bin/cfn-init -s ", {
"Ref": "AWS::StackName"
}, " -r StagingInstance ",
" --region ", {
"Ref": "AWS::Region"
},
" || error_exit 'Failed to run cfn-init'\n"
]]
}
},
"SecurityGroupIds": [{
"Ref": "StagingSecurityGroup"
}],
"ImageId": {
"Ref": "StagingAMI"
},
"KeyName": {
"Ref": "InstancePrivateKeyName"
},
"InstanceType": {
"Ref": "StagingInstanceType"
},
"IamInstanceProfile": {
"Ref": "StagingInstanceProfile"
},
"Tags": [{
"Key": "Name",
"Value": {
"Fn::Join": ["-", [
"staging", {
"Ref": "AWS::StackName"
}, "app-instance"
]]
}
}],
"SubnetId": {
"Ref": "PrivateSubnet1"
}
}
}
Instance in Terraform
#
Create the staging instance
resource "aws_instance"
"staging" {
ami = "${var.staging_instance_ami}"
instance_type =
"${var.staging_instance_type}"
subnet_id =
"${var.private_subnet_id_1}"
vpc_security_group_ids = [
"${aws_security_group.staging.id}"
]
iam_instance_profile =
"${aws_iam_instance_profile.staging.name}"
key_name =
"${var.instance_private_key_name}"
tags {
Name =
"staging-${var.stack_name}-instance"
}
user_data = "${file("
instances / staginguserdatascript.sh ")}"
}Managing State – This is the second advantage for Terraform. Terraform knows the state of the environment from the last run, so you can run “terraform plan” and see exactly what has changed with the items that Terraform has created. With an update to a CFT, you only know that an item will be “Modified,” but not how. At that point you’ll need to audit the modified item and manually compare to the existing CFT to determine what needs to be updated.
Multi-Provider Support – Depending on how you utilize AWS and other providers, this can be a very big deal. Terraform gives you a centralized location to manage multiple providers. Maybe your DNS is in Azure but your servers are in AWS. You could build an ELB and update the Azure DNS all in the same run. Or maybe you want to update your AWS infrastructure and also update your DataDog monitoring too. If you needed a provider they didn’t have, you could presumably add it since the code is open source.
Short learning curve – While they did introduce custom formatting for Terraform templates, the CFT and API nomenclature is *mostly* preserved. For example, when creating an instance in CFT you need an InstanceType and KeyName. In Terraform this is instance_type and key_name. Words are separated by underscores and all lowercase. This makes it somewhat easy to migrate existing CFTs. All told, it took about a day of experimentation with Terraform to feel comfortable.
Open Source – The general terraform tool is open source, which brings all the good and bad to the table that you normally associate with open source. As mentioned previously, if you have GoLang resources, the world is your oyster. Terraform can be made to do whatever you want it to do, and adding back to the repository will enhance it for everyone else. You can check out the git repo to see that it has pretty active development.
Challenges
Cost – The free version of Terraform is free, but the enterprise version is expensive. Of course the enterprise version adds a lot of bells and whistles, but I would recommend doing a serious evaluation to determine if they are worth the cost.
No Rollback – Rolling back a CFT deployment or upgrade is sometimes a blessing and sometimes a curse, but with CFT at least you have an option. With Terraform, there is never an automatic rollback. You have to figure out what went wrong and plow forward, or first rollback your code then re-deploy. Either way it can be messy. However, rollback for AWS CFT can be messy too. Especially when changes are introduced that make CFT deployment and reconfiguration incompatible. This invariably leads to the creation of an AWS support ticket to make adjustments to the CFT that is not possible otherwise.
CFT is “tightly coupled” with AWS, while Terraform is not. This is the YANG to the open source YIN. Amazon has a dedicated team to continue to improve and update CFTs. They won’t just focus on the most popular items and will have access to internal resources to vet and prove out their approach.
Conclusion
While this article only scratches the surface of the differences between utilizing AWS CFT and Terraform, it provides a good starting point when evaluating both. If you’re looking for a better “infrastructure as code,” state management, or multi-provider support, Terraform is definitely worth a look. We are here to help our customers, so if you need help developing a cloud-first strategy, contact us here.
-Coin Graham, Sr Cloud Consultant, 2nd Watch
