Thoughts on AWS Control Tower

In July 2019, AWS launched Control Tower as a method to provision a new AWS account hierarchy and configuration referred to as a “landing zone”. We took a deep dive on AWS account design and AWS Control Tower to see what it all means.

Trent Hornibrook

Background on an AWS environment

Best practice for an AWS environment is to have multiple AWS accounts, with a specific AWS account as an access control boundary.

You then end up with two groups of accounts:

  • Core accounts - the accounts that provide that plumbing, baseline & security governance
  • Workload accounts - the accounts where the workloads are run



Conceptually, a multi-account hierarchy makes sense, but to date implementing best practice either requires deep AWS expertise around IAM, or a lot of luck. Organisations that can afford to hire Cloud Engineers, Site Reliability Engineers, DevOps Engineers, or whatever the title is for the job of ‘doing the AWS infrastructure things’ generally have this available. What about those smaller organisations that cannot?

By not having some form of AWS account separation, ensuring audit logging is enabled, and controls around access, you leave yourself exposed to not understanding how you were exploited, or being able to track who or what exploited you. Lumping everything into a single account also makes cost allocation and access controls substantially more complex and expensive to manage. Modern cloud practices use accounts as an isolation approach not only between business lines, but often used between teams, environments and even specific developers.

Over many years AWS built documentation and patterns of best practices called Landing Zones - the objective of these patterns are to make it easier and consistent when provisioning new accounts, while ensuring that a standard set of security controls, billing constructs and best practices are enforced.

Even with this documentation and configuration-as-code, it is still too hard for people who are not familiar with AWS to build a working and easily supportable Landing Zone approach.

AWS subsequently iterated upon Landing Zones by building a product offering called AWS Control Tower.


From 0 to an AWS Control Tower environment

The idea of AWS Control Tower is to simplify the multi-account provisioning setup to:

  • Sign up for an AWS Account with a credit card
  • Set root MFA on your account and put those details in a secure location
  • Provision an admin IAM user with root MFA that you can now use to log in
  • Navigate over to AWS Control Tower and just provision it
  • Come back in 60 minutes and create a Single Sign On account for you and others who need access



My Thoughts on Control Tower

There are some great things around Control Tower…and some not so great - all depending on the maturity of the AWS infrastructure team within an organisation.

The provisioning of Control Tower is via ‘clickopsing’ - authenticating into the console, navigating to Control Tower and clicking on create. It’s not possible do this this via code or CloudFormation.

Once provisioned, Control Tower implements good practices for account access by using Amazon SSO for access into the accounts with well thought through cookie-cutter role based access control setup.


What I like

  • Forces individual access into accounts down SSO - this removes the long lived IAM user security risk that is quite common in accounts
  • You get a working solution from nothing after 60-90 minutes
  • Control Tower provides a decent security baseline for an account
  • The Cloudtrail logs are enabled and shipped to the central audit account
  • There is a baseline set of Service Control Policies to prevent bad things from happening
  • There is a baseline set of Amazon Config rules to notify you of common strange scenarios that might occur within the account


What I don’t like

  • Control Tower is ‘clickops’ at the moment, thus there is no way to build any continuous integration of an account setup
  • Guardduty is not enabled in the account provisioning - this is quite odd to me as Guardduty is a very low cost, highly valuable threat detection service
  • The multi-account hierarchy in the current implementation is a little too simplistic for my liking. More complex environments require a Security account to manage things like AWS Firewall Manager, a Network account to manage Transit Gateway and so on
  • Control Tower does not provide the ability to turn on and off regions, as it’s now becoming more common to turn off regions where you don’t have any workloads to limit security surface area
  • The Account Factory VPC topology does not provide any room for decent customisation
  • The AWS Account Service team limit the number of accounts that are created by default and there isn’t a nice feedback loop when a workload account fails to provision due to limits
  • Even though AWS SSO has the ability to use an on-prem AD configuration as user and group datastore, it’s not possible to do this elegantly given a chicken & egg scenario around AD connectors
  • It’s very difficult to deprovision AWS workload accounts; I’m still waiting on that Account Deprovision API


My pony request (what I would love added to the roadmap)

  • On top as configuration-as-code support, the ability to customise the definition of a “Core account” topology. For instance, being able to provision a Security or Network core account as an option from the start
  • Ability to add custom workflows based on events that occur during account provisioning - for instance allowing a customer to customise their own Account Factory provisioning
  • Transit Gateway unlocks interesting network topologies to control and manage ingress and egress compute network traffic from a security standpoint - having this self-serviced would be really useful
  • More simple SSO configuration to enable various identity providers out-of-the-box
  • A marketplace style integration to allow AWS Partners to add their own secret sauce without losing the great value of the product offering of Control Tower


Final thoughts

I’d recommend using Control Tower for small to medium businesses looking to get into AWS, without a complex workload and just wanting ‘best practice’. It’s currently not a solution to retrofit an existing account topology. This leaves a grey area for an organisation that is looking to start in AWS with custom workloads, or where there is a use case of forecasting significant amount of short term scale. I’m not sure Control Tower is the right solution for the account setup, yet: the retrofitting required to build in the extra controls, (eg ‘Core Accounts’ & access policies) might be more trouble than it’s worth by doing it around the Control Tower ecosystem.

I was fortunate enough to meet the AWS Control Tower team in Seattle where I was able to provide this feedback. Their response was that their initial version one was targeted at the 80% of customers who want something decent but who don’t know where to start. I think they have hit the mark, and I’m sure they have a long roadmap to further enrich the product.

Hit me up on Twitter @mysqldbahelp / @cevoaustralia or via our contact page if you want to know more about Control Tower.