Part 2 of this series introduced AWS Landing Zone and how that solution gives customers a well architected multi-account structure within AWS. Like many other architectures available in the cloud, AWS Landing Zone makes use of a multitude of AWS services and deploys them via infrastructure as code and other DevOps tools to provide an underlying environment that is AWS ready. AWS also provides services that are more platform oriented (PaaS) and abstract away a lot of the complexities that infrastructure sometimes provides. Why run MySQL on an EC2 instance when you can utilize AWS RDS? Why build your own complex cloud networking constructs when you can use AWS Transit Gateway? AWS recently released a new service called Control Tower that is meant to be the platform of choice for creating a landing zone in AWS.
Is this just some flight tracking app?
Questionable naming choice aside, Control Tower is actually a service that simplifies the deployment and management of a landing zone within AWS. Unlike AWS Landing Zone, which uses a Cloud Formation template to initiate the deployment, Control Tower is simply run by clicking the Set up landing zone button within the service. Similar to AWS Landing Zone, the AWS account in which you initiate the deployment of Control Tower will be considered your master account from an AWS Organizations perspective. This is why it is usually best to deploy your landing zone into a brand new, completely unused AWS account. The deployment of Control Tower itself is much simpler than AWS Landing Zone. You essentially need to provide two email addresses, one to be used for each new account that is created by the Control Tower deployment. You also need to choose the region into which you will deploy Control Tower:
Once you enter this info and hit go, Control Tower automates the entire process behind the scenes. This takes about 1-2 hours to complete successfully. Once finished, the box turns green and alerts you that your landing zone is available.
The infrastructure deployed by Control Tower is similar to AWS Landing Zone, but there are key differences. Out of the gate you get a new AWS Organization that consists of your master account as well as the two new accounts deployed by Control Tower: log archive and audit.
The master account contains the Control Tower service itself, AWS Organizations, the service catalog for an account creation service called Account Factory, AWS SSO, among others. Similar to AWS Landing Zone, there is a log archive account that acts as the aggregation point for CloudTrail and Config logs across the organization. There is also an audit account that contains cross-account security roles and centralized CloudWatch monitoring with SNS notifications.
The main differences in the baseline structure from AWS Landing Zone are that there is no Shared Services account / VPC out of the box, no security account with a pre-defined GuardDuty master, and none of the CodePipeline, S3 bucket for CloudFormation manifest file, and other stuff required by the AWS Landing Zone deployment. Like most other PaaS solutions, Control Tower begins to mask some of the underlying infrastructure of the landing zone itself.
The log archive and audit accounts are provisioned into a Core OU within AWS Organizations, while a default Custom OU is available for new accounts.
Governance via guardrails
One of the big benefits provided by Control Tower is easy access to a set of guard rails that provide governance for your organization. These guardrails are essentially AWS Organizations Service Control Policies (SCPs) under the covers, but Control Tower makes it very easy to view and consume guardrails by giving you the ability to enable/disable them without needing to dig through the JSON to see what they do. These guard rails can be enforced across the entire organization and come in two flavors:
Preventive – when enforced, these guardrails disallow specific actions to take place that would otherwise lead to a policy violation. Guardrails like disallow changes to log archive and disallow actions as a root user enforce rules that actively deny specific actions from taking place.
Detective – when enforced, these guardrails discover whether accounts are in compliance or not and alert based on that compliance. Guardrails such as enable MFA for the root user and disallow public read access to S3 buckets will detect whether accounts are in compliance with this guardrail, and if not will display an alert showing which account needs remediation by an administrator.
There are a number of mandatory guardrails that are enabled by default by Control Tower, as well as optional guardrails that are initially disabled and defined as either strongly recommended or elective.
The Control Tower dashboard
Another new features that comes with Control Tower is a dashboard that begins to bring a “single pane of glass” to landing zone management. From the dashboard you get some basic insights into the overall state of your organization, such as the number of OUs and accounts along with a guardrail summary. You also have recommended actions that bring you to the different components within Control Tower and can view non-compliant resources.
The components that come under the purview of Control Tower are accounts, OUs, guardrails, user and access and account factory. Drilling down into most of these allow you to configure your organization from directly within Control Tower. For example, within guardrails you have the ability to enable optional guardrails and view information about each of the guardrails, such as what they do and whether they are preventive or detective.
Selecting the user and access option of Control Tower gives you some information as well as links that launch the AWS SSO service into a new tab. Similarly, the account factory option describes what it is used for (basically the same as the account vending machine in AWS Landing Zone) and allows for some basic configuration settings. Clicking to provision a new account simply launches the Service Catalog into a new tab where you can then run the Account Factory service.
How ControlTower stacks up…
Control Tower is still in it’s infancy, but is a great step towards simplifying a landing zone experience for AWS customers. The deployment itself is super simple and the dashboard begins to bring some of the components under one roof. Yes, the deployment doesn’t include a shared services account, but that just means once Control Tower has been deployed, it is up to the organization to deploy new accounts with VPCs, Transit Gateway and whatever else may be needed for the overall organizational design.
Like some other AWS services, one of the draw backs is that by hiding many of the deployment components behind the platform, Control Tower is less flexible than AWS Landing Zone. If your organization is very fluent in Cloud Formation and other AWS DevOps tools, you could customize AWS Landing Zone more to your liking. Everyone gets the same default config with Control Tower, but it does come with a dashboard that starts to bring the pieces together and may be easier for a security and infrastructure team to manage regularly.
You can still go into AWS Organizations and see some of the behind the scenes stuff once you’ve deployed Control Tower, so you have to be careful when using native services to configure anything, because Control Tower will have no insight into it. One of the knocks on Control Tower is that you are given guardrails, but you can’t similarly create your own SCPs and have Control Tower govern that. You can certainly deploy SCPs from AWS Organizations, but then you have to manage your organizational governance from within both Control Tower and Organizations. You also only have the ability to create new OUs under the root OU, so building a tree-like hierarchy is not currently possible. Hopefully as the Control Tower service continues to mature, some of these low hanging fruit options will become available to better expand it’s flexibility.
Control Tower is definitely a great option for customers that are looking to build a new organization within AWS, but it has some ways to go before it can completely unburden admins from all of the complexity involved with a landing zone.
