I bet you have a smoke detector on the ceiling somewhere in your house. It’s great for catching a localised problem like your pizza burning in the oven. Unfortunately, a smoke detector probably isn’t going to help a lot when a less localised problem occurs. The United States Forest Service has to worry about fire across an estate of 193 million acres. At their scale, they use fire lookout towers, often built on hills or mountains, to get a far-reaching view and spot forest fires before they become a major problem. Sometimes even that’s not practical, and for such cases they can use NASA’s FIRMS to detect fires from orbit. As the scale of the problem changes, you need to shift perspective and get a view from a higher level.
The same is true for your AWS estate. Perhaps your SaaS application started as a prototype, with a small, comprehensible AWS footprint. As the complexity of your system increases, and your compliance burden grows, you may find it harder and harder to manage it all while maintaining confidence in the security and stability of the system. Amazon (and us) recommend scaling out with multiple AWS accounts, we know it works because we’ve helped many of our customers reap the benefits. Implementing a multi-account architecture has many benefits like reducing the blast radius for disaster and security issues, or enabling different environments to have different security controls. However, going multi-account has its own set of unique challenges for auditing, access and observability. Are you trying to detect a forest fire with a handful of household smoke detectors?
So how do you shift your perspective and get a better, top-down view of your SaaS application’s multi-account AWS estate? What is the AWS equivalent of the fire lookout station? It’s called AWS Control Tower.
What is AWS Control Tower?
AWS Control Tower is a service that makes it easier to secure and govern a multi-account AWS estate. Unlike a fire lookout tower, it is not just a detective tool, having a wide remit that spans all aspects of multi-account management. Control Tower deploys a landing zone that takes many other AWS services and packages them up into a service whose value is greater than the sum of its parts, abstracting away complexity and giving you a polished out-of-the-box solution.
Behind the scenes it’s using:
- AWS Organizations for unified billing and organization structure.
- AWS Service Catalog for account vending.
- AWS Config for continuous auditing of AWS resource configuration.
- AWS CloudTrail for centralised audit logs.
- AWS Single Sign-On.
- AWS CloudFormation for deploying and configuring resources across multiple accounts using Stack Sets.
- and more…
For the most part, you can ignore this list and just think about the landing zone. The landing zone is your multi-account AWS environment template, the blueprint that ties all of the above services together into a single package.
What Problems Does AWS Control Tower Solve?
To have a large multi-account AWS estate to manage, you first need to create one. Surprisingly, this can actually be the hardest part. Creating a new AWS account is easy enough, there is even an API for that, but creating an account is only step one. Once you have a new AWS account you need a litany of things before it is actually usable: access for those who will use it, organisational security controls and of course, observability over when and how the account is actually being used. If left unchecked, this can result in a wild west, where every account has different arbitrary rules enforced by their own sheriff. On the other end of the spectrum, excessive bureaucracy may creep in, where each request for a new account gets bounced around teams and ticketing systems, slowing down everyone. Unless you’re in the thermal printer business, it’s generally good policy to avoid extra process where you can. Clearly, we need a third way.
When using Control Tower accounts can be vended using the Account Factory. When an account is created using the Account Factory, you need only to provide an email address, name and organizational unit (OU) for the new account to be created in. Control Tower creates the new account and configures all the ongoing governance rules (guardrails, detailed below) you have specified for that OU. As the Account Factory performs all additional configuration of governance services during account creation, it then becomes feasible to allow self-service vending of accounts, reducing operational overheads and lead times.
Just because Control Tower makes it easy to create an account doesn’t mean it isn’t expressive. Not every AWS account is created equal, you’ll be using accounts for different workloads and environments that naturally have varying configuration requirements. By partitioning your accounts into organizational units along these logical boundaries, you can consistently apply configuration for both existing and newly vended accounts.
Guardrails are high level rules that help you secure and monitor your multi-account AWS estate in line with AWS best practices. Each guardrail can be applied to your entire Organization, to an organizational unit (a subset of your AWS accounts), or to individual accounts. Guardrails come in two flavours: preventative and detective. Preventative guardrails, such as “Disallow Actions as a Root User”, block actions at the AWS API level. Detective guardrails like “Detect Whether Public Read Access to Amazon S3 Buckets is Allowed” detect and alert you to non-compliant resources within your estate.
There are three sets of guardrails provided by Amazon, one mandatory and two elective all of which include a mix of detective and preventative controls. The mandatory guardrails are applied to all accounts that are managed through Control Tower. These baseline controls prevent modification to the infrastructure deployed by Control Tower so you can be confident that the information Control Tower provides about your account is accurate. The two optional groups are “Strongly Recommended” and “Elective”, from these you can mix and match individual guardrails that make sense for your organization. As guardrails can be applied to organizational units or even individual accounts, you have the flexibility to choose different controls for different environments and workloads. Your developer sandbox accounts likely don’t need the same stringent controls as your centralised backup account.
So we have our accounts, and we are confident they are configured in a compliant way. How do we actually provide access to our engineers? On a small scale, IAM roles can be created to enable cross account access, but as your AWS Organization expands, it can be very difficult to keep track of which accounts have which roles and what permissions each role grants. This is where AWS Single Sign-On steps in.
AWS Single Sign-On (AWS SSO) comes configured automatically with Control Tower and allows you to define permission sets which are mapped between groups and AWS accounts in a single centralised console, no need to individually craft IAM roles or permissions in every AWS account. When a user logs in through AWS SSO, they are not presented with the AWS console immediately, but instead a list of accounts, and the roles within them, that they can access.
Although not required, you can also hook AWS SSO into your existing identity provider, like Google Workspace or Active Directory. This can simplify your AWS onboarding and offboarding process to a matter of group membership. If you are happy with your existing access methods, then you can also choose not to use AWS SSO at all.
Tools with a smooth first time setup are good. Tools which also make the long tail of maintenance and upkeep easier are great! For SaaS businesses that need to show compliance, that long tail will likely largely consist of ensuring that effective controls are in place, and periodic auditing.
One of the hardest parts of utilising a multi-account Organization is discovering what is actually going on in each account. If you need traceability to prove compliance with industry standards such as PCI DSS or ISO 27001, or want to be able to respond actively to security incidents like lost credentials, then you’ll want a durable record of changes made via the control plane. Although setting up an encrypted multi-account trail is not an insurmountable task, ensuring the data is stored securely, while being accessible to those who need it, can be a fiddly job. Control Tower gives you a batteries-included CloudTrail deployment straight out of the box. When you deploy Control Tower you get a brand-new log archive account. The landing zone configures all accounts in your Organization to log security records to this centralised location. Furthermore, if you are using AWS SSO, Control Tower will create groups that allow varying levels of access to this audit data that can be used by your internal security teams or external auditors.
The log archive account doesn’t just contain your CloudTrail data, it also contains logs for the detective guardrails you have configured on your account. It’s also a great place to aggregate other logs, such as from your workloads. By keeping this data all in one place, Control Tower makes it easier to do a comprehensive audit of all of your accounts using tools like Amazon Athena.
Control Tower can also be thought of as an enabler. Once managing, governing and auditing your multi-account AWS estate becomes trivial, you can then use the excess operational bandwidth to extend that foundation. For example, we often set up Terraform infrastructure pipelines on top of a Control Tower landing zone.
With “Customizations for AWS Control Tower” (using CloudFormation) or “Account Factory for Terraform”, you can use infrastructure as code (IaC) to extend your Control Tower installation. Your focus might be to extend the compliance capabilities of Control Tower, on making it simpler to add new SaaS tenants, or you might want to automate vending of sandbox environments for full-scale integration tests. Control Tower gives you a great starting point for each of those options.
Many AWS services integrate directly with AWS Organizations, with a well architected Control Tower installation it becomes easier to roll out services like AWS Backup, AWS Security Hub, or AWS Firewall Manager. To build upon the controls provided by guardrails, we often set up GuardDuty (a managed security alert service) as part of our SaaS Foundations package. We think GuardDuty is an important extra add-on for any landing zone.
What Are You Waiting For?
By using Control Tower you can shift your perspective and start looking at your AWS estate from a higher level. You can stop worrying about the trees and focus on the forest. By removing operational overheads related to managing multi-account setups, you make room for improvements that add value. It’s all about using the right tools for the job.
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.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.