Please note that this post, first published over a year ago, may now be out of date.
Ever since its initial release we’ve been busy building Control Tower landing zones for our customers. It’s an easy product to recommend because it brings a lot of value at a modest effort. But once in a while we come across concerns from teams using Terraform who aren’t sure if it’s a good fit for them. I’d like to address some of those concerns and make a case for Control Tower no matter what IaC (Infrastructure as Code) tool you use. In fact the vast majority of our customers are Terraform shops, happily getting along with their landing zones. I’ll focus on Terraform here but most of this should apply to other tools as well, such as Pulumi or CDK.
The problem Control Tower is solving
Let’s start by looking at the main problem Control Tower is trying to solve. If you ever saw anyone from AWS talk about it, you might have noticed a slide which looks something like this:
Achieving governance goals without impacting agility is Control Tower’s main mission. By introducing security guardrails, workload isolation and AWS account baselines it can mitigate some of the risks without slowing you down. Have your cake and eat it.
The baseline vs. the workload
This naturally leads to a distinction between the account baseline and workload resources. Each has a different set of characteristics and it makes sense to handle them in different ways. Let’s briefly explore what those characteristics are.
Account baseline contains resources which aren’t directly related to the workload but help with risk reduction, security, compliance and bootstrapping. A baseline may include cross account CloudTrail logging, GuardDuty detectors and similar services. Those services are often protected with guardrails to prevent malicious or accidental modification. Baseline has the following characteristics:
- Deployed across all AWS accounts in an organisation.
- Little variation between individual AWS accounts, although they may be some at the OU level.
- Because of the wide scope of deployment it requires high privileges to manage.
- Often administered by the platform team, if you have one.
- The rate of change tends to be slow after the initial deployment.
Control Tower will set up an initial baseline for you out of the box, mainly involving CloudTrail and AWS Config, which is deployed using CloudFormation StackSets. It’s not something you generally need to (or should) touch. It’s managed for you by Control Tower. Relax and enjoy not having to maintain it.
The workload on the other hand is your bread and butter. These are the services you build and operate that hopefully make you a bit of money. The common workload infrastructure characteristics are:
- Deployed to a smaller subset of AWS accounts, often organised by environment, such as test and production.
- Often managed by the same team who built the application. Their AWS experience may not be as deep as that of the platform team.
- High rate of change and deployment frequency.
- Permissions can be scoped down to only necessary services.
- More complex.
Because of the high rate of change this is where fast development cycle and developer ergonomics pay dividends and Terraform really shines in this department. Luckily Control Tower has no opinion about what you use to manage the workload. As long as you operate within the set guardrails you can use whatever tools you like and the majority of our customers choose Terraform.
But I can’t provision Control Tower with Terraform!
This is a common concern we hear about. The deployment of Control Tower is already highly automated and you only do it once. Is it worth terraforming? Probably not.
Update Control Tower now has an API for managing guardrails, and we use that as part of our AWS Foundations solution. Customising things further with aws_controltower_control in Terraform is an option if you prefer to work that way.
Can I use account factory with Terraform?
Yes. The Control Tower account factory uses AWS Service Catalog under the hood which is well supported by Terraform. It can be useful when frequently provisioning new accounts, such as when using accounts for SaaS tenant isolation.
Extending the baseline
More often than not the simple baseline included in Control Tower will not be enough and you’ll want to extend it. There are many ways to skin that cat, but let me share some of the approaches we tried.
At The Scale Factory we use Terraform a lot, but we always try to use the best tool for the job and avoid the trap of tool dogmatism. We looked at the characteristics of baseline management and analysed the trade-offs between the different approaches. In the end we recognised that CloudFormation StackSets are actually a really good fit for this problem because they make it easy to deploy resources en masse across an organisation with no bootstrapping necessary. The slower development cycle is not a problem because the baseline doesn’t change very often.
Doing the same with Terraform usually results in a worse cost (effort) to benefit ratio. Most of the landing zones we build use StackSets for the baseline and Terraform for the workload. We find this works really well because it uses the strengths of both tools and keeps the two concerns nicely decoupled. It also keeps the boilerplate out of the Terraform codebase, making it cleaner, more focused and faster to apply.
Our B2B SaaS Foundations solution uses Customisations for Control Tower (CfCT) to manage the baseline templates. It’s essentially a CI/CD workflow for deploying StackSets and SCPs (Service Control Policies). It’s simple and works well for baselining but it’s not suitable for more complex configurations so don’t go managing your entire workload with it.
If you really want to baseline your accounts with Terraform there is also the Account Factory for Terraform (AFT). In my experience it’s complex and not as nicely integrated as StackSets (no surprises here), but it also doesn’t have that fast feedback loop you’d expect from Terraform. You can’t quickly run a plan against an account and see the diff. It has the disadvantages of both worlds and it’ll cost you $350 a month for just sitting there idle most of the time.
And lastly you can build a bespoke solution, such as our own tfctl. This may be appropriate if your requirements are complex enough but in majority of cases it’s not worth the effort.
Where to draw the line
Control Tower works well with Terraform as long as you view it as another layer of automation in its own right and set a clear boundary of responsibilities. I hope this post helped you decide where to draw that line.
Like the sound of all that but want some expert help implementing Control Tower in your AWS estate? Our SaaS Foundations package includes a bespoke Control Tower design and installation by our experienced AWS consultants for a simple fixed price.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
