AWS Control Tower

Jon Holman

September 8, 2022

•

5 min read

TL;DR:

Don’t use AWS Control Tower, but don’t completely write it off. Recognize what Control Tower is trying to accomplish and use that as a starting point or a baseline for your AWS Organization’s security posture.

Amazon Web Services (AWS) Control Tower is an AWS-provided service commonly brought up or recommended when creating and securing a multi-account AWS organization. It is an opinionated service that does many things for you, like implementing and enforcing several best practices for an AWS Organization (multi-account) environment. As its service landing page says, "implementation best practices based on AWS’s experience working with thousands of customers as they move to the cloud." Since creating an organization and having no workloads in your root account is considered best practice, this dilemma of using Control Tower or not extends to all AWS customers.

I have been using AWS’s Control Tower service in several AWS Organizations. Recently I was discussing Control Tower with some friends and was asked, “what does Control Tower give you?” That was a great question. I was surprised that I had to think hard about what I gained by using AWS’s Control Tower.

What Control Tower gives us:

It creates an AWS Organization for you.
It sets up AWS Single Sign-On (SSO) / AWS IAM Identity Center for you.
It creates a log archive AWS account and configures CloudTrail on all enrolled member AWS accounts to send their CloudTrail logs to that account.
It creates a security tooling/audit AWS account for you.
It assists in creating a region deny Service Control Policy (SCP).

My concerns with Control Tower in its current form:

Mandatory Guardrails: Control Tower has a concept of accounts being enrolled or not enrolled. Once you see the enrollment status, you will want all your accounts to be enrolled. But, if your account is enrolled, mandatory guardrails take effect. I am not a fan of what AWS defines as mandatory, though, because it includes that AWS Config must record all changes to AWS resources for every enrolled account. For a sandbox or development account, AWS Config will quickly become your most significant expense in those AWS accounts. The solution to that issue is to keep those sandbox and development accounts unenrolled from Control Tower, but then you are missing out on all other Control Tower coverage that would be helpful.
New Account Creation: The process to create a new AWS account through Control Tower. When using Control Tower, we use its account factory feature to create new AWS accounts; this leverages AWS ServiceCatalog. We must complete a form to start account creation. There are required fields for an email address and first and last names on that form. When filling out required fields on a new account request form, I would want all the answers for the account created associated with a team, not an individual. However, if you provide a distribution list for these required fields, a generic AWS SSO/ AWS IAM Identity Center user will be made for that distribution list. All user accounts should be associated with an individual. A common workaround is to provide this form with a user already existing in AWS SSO / AWS IAM Identity Center so that Control Tower will not create a new user. That does work but is bizarre, in my opinion.
Regional governance: From the Control Tower setup screens, “You can add governance to Regions after setup. Opting out of a Region does not prevent you from deploying resources in that Region, but those resources will remain outside of AWS Control Tower governance.” As I understand this, it also will be applied to regions in which AWS Control Tower is not yet available, which as of this writing, are N. California, GovCloud, Cape Town, Hong Kong, Jakarta, Osaka, Milan, and Bahrain. I would be even more concerned about account activity occurring in regions where I believe my organization does not have workloads than regions where we are running workloads. We will notice the activity in the regions we are using.
Control Tower is not a finished product. I have previously seen others accuse AWS of not finishing a product, like getting it to 99% done, then releasing it. I cannot defend AWS from that accusation in the case of AWS’s Control Tower.
AWS Control Tower is much more fragile than every other AWS service I have used. For example, if you want to start over and try configuring Control Tower again, you cannot simply delete your Control Tower resources and start over. If you do, this Control Tower will end up completely broken. As a result of my attempt at doing this, AWS support has advised me to create a new AWS account and abandon the account where I did this.
Of course, you should try never to use your root account. However, as I struggled through example use cases to evaluate Control Tower, I started using the root account. I then tried to create an account using AWS Control Tower’s account factory, and the error I received was “No launch paths found for resource.” If to you, that says, “You cannot perform this action with the root account; try with a non-root user,” then yes, that one is on me.

What are the alternatives?

There are many other options, including some created by AWS, for example:

Lessons to learn from Control Tower:

Here is a list of things that I see Control Tower currently doing that every AWS customer should do, whether through Control Tower or another means.

Always create an AWS organization and run no workloads in the root management account.
Configure service control policies (SCPs) in AWS organizations to create a restriction on all organization accounts, like disallowing the use of regions that your organization does not use.
Use AWS SSO / AWS IAM Identity Center. AWS SSO / AWS IAM Identity Center must be one of the greatest AWS services. As its name implies, you can create a user one time and then give that user access to all the AWS accounts they need access to, with the level of permissions they require. It supports programmatic and console access with a maximum duration of 12 hours, meaning no long-lived access keys.
If you need to create a customized account factory, use AWS Service Catalog.
Create a log archive account and send all the organization’s CloudTrail logs there.
Create a security tooling account and run your audit tools from there, not from your root management account.

My recommendation:

I recommend thoroughly reviewing the options to find the one that makes the most sense to your use case. Most importantly, your team needs to understand what is being set up rather than relying on a tool to do it for you. I will not recommend using Control Tower, but I would look to it as an example or checklist of steps we should take to secure an AWS account.

Thanks for reading. Please share your thoughts with us on social media.