I recently had some deep experience in deploying AWS Control Tower into an existing AWS Organization structure. The experience went well – until I broke it. This blog is all about the ways to break (and fix) Control Tower. It would not be a great technical blog without covering the basics of what Control Tower is, does, can do and finally, how I broke it, fixed it, and learned a lot more about it than what is widely documented.
In this Part 1 of a two-part series, we explore Control Tower components and structures. In Part 2 of this series, we will explore how to break and fix Control Tower and some guidance when integrating existing accounts in an Organization into Control Tower.
What is AWS Control Tower?
AWS Control Tower offers the easiest way to set up and govern a secure, compliant, multi-account AWS environment based on best practices established by working with thousands of enterprises. Control Tower extends the capabilities of AWS Organizations to orchestrate and manage several AWS services and protect their configuration from drift.
In addition, Control Tower sets up AWS Identity Center for single sign-on, builds a Service Catalog product for an Account Factory to build pre-governed AWS accounts. Finally, Control Tower creates and manages baseline detective controls using AWS Config and deploys centralised organisation CloudTrail’s.
Control Tower deploys a secure, Well-Architected, multi-account structure the provides:
- Preventative Controls – in the form of Service Control Policies (SCP’s)
- Detective Controls – in the form of AWS Config service deployment
- Proactive Controls – in the form of CloudFormation hooks for AWS Organizations – Organization Units (OU’s)
Control Tower Features
AWS Control Tower has the following features:
- Landing zone – A landing zone is a well-architected, multi-account environment that is based on security and compliance best practices. It is the enterprise-wide container that holds all your OUs, accounts, users, and other resources that you want to be subject to compliance regulation. A landing zone can be scaled to fit the needs of an enterprise of any size.
- Controls – A control (sometimes called a guardrail) is a high-level rule that provides ongoing governance for your overall AWS environment. It is expressed in plain language. Three kinds of controls exist: preventive, detective, and proactive. Three categories of guidance apply to controls: mandatory, strongly recommended, or elective. For more information about controls, see How controls work.
- Account Factory – An Account Factory is a configurable account template that helps to standardise the provisioning of new accounts with pre-approved account configurations. AWS Control Tower offers a built-in Account Factory that helps automate the account provisioning workflow in your organisation. For more information, see Provision and manage accounts with Account Factory.
- Dashboard – The dashboard offers continuous oversight of your landing zone to your team of central cloud administrators. Use the dashboard to see provisioned accounts across your enterprise, controls enabled for policy enforcement, controls enabled for continuous detection of policy non-conformance, and non-compliant resources organised by accounts and OUs.
Control Tower Landing Zone
A Control Tower Landing Zone comprises several accounts and roles for management and governance. These are deployed and configured automatically during the deployment of the Control Tower Landing Zone provisioning. Here is the baseline setup of what Landing Zone builds using Control Tower:
The roles of these accounts are as follows:
Account Type | Role in Landing Zone |
Management Account | Manages Control Tower itself. It is immune from Control Tower guardrails as it must reside within the root of the AWS Organization. It also provides single sign-on through AWS Identity Center, manages AWS Organizations and Service Catalog for the Account Factory. |
Log Archive Account | Hosts the centralised logs from the Organization CloudTrail (introduced in v3.0 of Control Tower). |
Audit Account | Centralises security notifications for AWS Config, Security Hub, GuardDuty, Inspector and Macie. Acts as the AWS Config Aggregator for centrally viewing AWS Config findings across an Organization’s member accounts. The AWS Config authorisations are centrally deployed from the Audit account for all member accounts. |
Security OU | A container for accounts that contains the Log Archive and Audit member accounts. |
Sandbox OU | Holds member accounts for experimentation and proof of concepts. |
The power of Control Tower is not about what it does, but what you can do with it. AWS Control Tower is a starting point for a landing zone. You need to determine your strategy for networking, access management, and security based on your unique requirements as you build out your landing zone. To assist with those missing elements, Control Tower allows for many customisations to be bolted onto it including Landing Zone Accelerator (LZA), Account Factory for Terraform (AFT) and Customisation for Control Tower (CfCT). These solutions extend Control Tower capabilities by leveraging deep integration with AWS Organizations and customisations to the Account Factory for provisioning accounts.
See here for a detailed breakdown of LZA:
The AWS (Amazon Web Services) Landing Zone Accelerator (LZA) – Part 1
The AWS (Amazon Web Services) Landing Zone Accelerator (LZA) – Part 2
Services Control Tower Manages
Control Tower manages several elements of the Landing Zone and protects those resources from being modified outside of Control Tower in Member Accounts. By preventing modification, Control Tower protects itself from drift (where resources are modified outside of the known good state). The caveat here is that the management account of the Control Tower Landing Zone (the account that built it) cannot be impacted by SCP’s as it must reside in the root of the AWS Organization.
This is where things get interesting. As an administrator of Control Tower – you have the power to break it, and this is the key to this blog. Control Tower cannot break itself after all.
Guardrails
The controls applied by Control Tower represent the best practices and prevent drift of those resources. An example control is the creation of the Organization CloudTrail while preventing users and roles other than Control Tower managed roles from disabling or deleting logs via a managed Service Control Policy (SCP). If this SCP is modified, Control Tower detects this as drift and allows recovery back to a compliant state.
AWS Config
AWS Config uses the configuration recorder to detect changes in your resource configurations and capture these changes as configuration items. You must create a configuration recorder before AWS Config can track your resource configurations. When you start the configuration recorder, AWS Config takes an inventory of all AWS resources in your account. There are several considerations with AWS Config:
- One configuration recorder per region per account
- You can have only one configuration recorder channel per AWS Region per AWS account, and the configuration recorder is required to use AWS Config.
- The configuration recorder is automatically created when you set up AWS Config
- If you set up AWS Config by using the console or the AWS CLI, AWS Config automatically creates and then starts the configuration recorder for you.
- All supported resource types are recorded by default
- By default, the configuration recorder records all supported resources in the region where AWS Config is running. You can create a customised configuration recorder that records only the resource types that you specify. For more information, see Recording AWS Resources.
- You are charged service usage fees for using the configuration recorder
- You are charged service usage fees when AWS Config starts recording configurations. For pricing information, see AWS Config Pricing.
Control Tower deploys AWS Config on your behalf and enables a configuration recorder and delivery channel in each member account enrolled into Control Tower. Control Tower sets up the Audit account to be the aggregator for findings from all member accounts running AWS Config.
CloudTrail
The default behaviour from Control Tower prior to v3.0 was for each member account to maintain its own CloudTrail. In v3.0, AWS enabled the use of Organization Trails to consolidate all member account CloudTrail’s into the central Audit account. When enabled during Control Tower deployment, update or reset, the default organisation trail is enabled. When disabled, CloudTrail is not enabled in the member account. This is fine if you have manually deployed an organisation trail for ingestion into a SIEM (such as XSIAM or Splunk) however be aware CloudTrail logging is disabled.
Continue reading
Check out Part 2 where we discuss how to break and fix Control Tower and some guidance when integrating existing accounts in an Organization into Control Tower.
