CloudFormation’s Secret Powers
Terraform vs CloudFormation articles are everywhere. Most seem to highlight Terraforms dominance over CloudFormation. It’s easy to see why. Terraform has a far superior syntax and is much more versatile. However, CloudFormation has features that are not mentioned in any of these articles which in some cases dwarves the advantages that you get from Terraform. Depending on your circumstance, these secret powers could actually sway you to use CloudFormation over Terraform.
In this article we will look at common problems that organisations face and how using CloudFormation can solve them.
Problem: Multi Account/Region Deployments
Most organisations that use AWS require mandatory IAM roles, S3 Buckets, or Cloud infrastructure to be deployed across all of their AWS accounts. They may also want to deploy an application to multiple accounts or regions for users. When organisations have many AWS accounts, this can be tedious to manage. No native approach exists in Terraform. Engineers must create pipelines to execute their code in multiple AWS accounts.
Solution: StackSets
CloudFormation has a useful feature called StackSets. This allows engineers to create a single CloudFormation stack which is then deployed to multiple different AWS accounts or regions. This greatly simplifies provisioning and updating infrastructure across an AWS environment. Engineers can deploy and update a single CloudFormation stack which is subsequently pushed out to all required regions and accounts. Subsequent updates are done in parallel which in itself is a challenge to recreate in Terraform.
StackSets have the ability to define different parameters for different accounts and regions. Therefore dev, test and production environments can be deployed through a single StackSet. When applying an update, it is possible to target which accounts are updated by a StackSet. This means that dev and test environments can be updated before deploying to production. All of these features are ready to use without needing engineers to build it out themselves.
One challenge with administrating multiple AWS accounts is setting up the required IAM roles in child accounts so that a parent account can provision resources in those accounts. AWS have recently allowed StackSets to automatically create and manage the required IAM roles on your behalf making it even easier to use. When an AWS account is removed from an organisation, a StackSet resources can be configured to automatically delete provisioned resources.
Problem: Platform Engineering
Large organisations that have many AWS accounts and teams often create a platform engineering team. This team is tasked to standardise monitoring, alerting and infrastructure provisioning across all AWS accounts.
Let’s suppose that a platform engineer team uses Terraform to define a fully compliant Kubernetes cluster with all monitoring and alerting baked in. Teams will be able to provision this whenever they need a cluster. After completing their scripts, they run into a problem: How do they allow teams to provision a cluster on demand? How do they make updates and force all instances of the cluster to be updated? How can they regulate their AWS accounts to enforce the use of the standardised cluster? Then there are the technical questions such as managing Terraform state and concurrency.
Solution: AWS Service Catalogues
To solve this problem, CloudFormation natively integrates with AWS Service Catalogues. This service allows us to define a CloudFormation template which is published as a Catalogue Item to targeted AWS account. User’s can then provision the required resources by executing the Service Catalogue item.
With this tool, platform engineers can define their standardised infrastructure. Publishing, updating, and provisioning this infrastructure is solved saving countless months to implement themselves.
Problem: Logging, Auditing & Notification
Organisations want all changes that are made by their tools to be tracked and audited. In some cases they also want engineers to be notified when changes occur to their environment whether it is in a pipeline or outside of a pipeline.
Solution: Stacks & AWS Config
When deploying a CloudFormation template, a Stack entity is created representing an instance of that template. This entity shows historical details such as when the stack was created, updated or deleted. Stacks that have been removed still have metadata that exist and can be reviewed.
AWS Config can be utilised to detect when a Stack set has changed. Notifications can be sent to certain individuals based on rules. It can also be configured to assess CloudFormation stack against agreed upon standard. Stack parameters can be inspected as well.
Other Terraform Challenges
In this section we will look at some challenges that exist in Terraform which do not exist in CloudFormation.
Parallel Deployments
I recently encountered this problem with Terraform. In the environment I was working in, we had an application deployed in many locations globally. When it came to updating all of these instances concurrently, Terraform does not natively support this.
The reason why is that it operates in a directory which must be initialised. If there are multiple instances of a terraform template in an environment, each of these would be a separately initialised which changes the local terraform state file that is generated. This is particularly challenging in large environments. When using CloudFormation, a user can push their updates and it will concurrently apply the changes.
State Management
Articles comparing Terraform to CloudFormation almost always have this as a win for CloudFormation. In my opinion, this is understated especially when you have a large AWS environment. State management can be tedious. Location, security, access and concurrency need to be managed. It is possible for state file storage to get disorganised. Teams need to agree and commit to a location / naming conventions for storing state files.
Building these features in Terraform
Most of these problems can be solved with Terraform. I have successfully solved these myself. “Let’s create a Jenkins pipeline that executes the Terraform code!” … but it is never as straight forward as that. How do we manage multiple different Terraform instances across different AWS accounts and regions whilst ensuring that they are updated when the platform team makes changes? Then there is the concurrency issue. How do we plan on concurrently updating many instances of a template in Terraform?
Yes, all of these problems can be solved. But now the platform team has to manage the Terraform code and a complex custom Jenkins deployment pipeline. This overhead can not be underestimated when stretched across many AWS accounts. When using CloudFormation, all of these powerful features exist out of the box ready to go.
Conclusion
CloudFormation is more than an IaC tool. It attempts to solve the management of provisioning and updating resources across an entire organisation. This is a massive win for organisations that have many AWS accounts. Terraform, in itself, does not attempt to do this. It is purely an IaC tool. Other services need to be either created or purchased. Building that kind of capability for terraform must not be underestimated.
