AWS – Setting up an automated landing zone with AWS Control Tower

How to run your first application on Kubernetes

AWS Control Tower is a service that helps you set up an automated landing zone using best practices for account management that have been learned from years of working with a variety of customers who have complex multi-account environments. Control Tower is the successor to AWS Landing Zone and relies heavily on AWS Organizations, which will be covered in detail later in this chapter.

In this recipe, you will create a new account to serve as the Control Tower master, and within that account, you will launch your Control Tower environment, which will spawn two additional core accounts: Log Archive and Audit. Then, you will use the AWS Service Catalog to create a new provisioned account. Within a provisioned account, you will attempt to create resources that fail to comply with the guardrails established on the organizational unit and see that you are quickly alerted to the problem.

How to do it…

Follow these steps to set up your core accounts:

  1. Create a new account using the recipe in Chapter 1, AWS Fundamentals. Pay special attention to the security recommendations, since this will be the master account for your new multi-account AWS environment. Give users strong passwords, and always configure multi-factor authentication!
  2. Log in to the new master account as a user with full administrative privileges and navigate to the Control Tower console. Click the Get Started button to set up a new environment.
  3. Configure the email addresses for each of the subordinate accounts that will be created for you by Control Tower:

Setting up the AWS Control Tower Shared account

See the How it works section that follows for a full description of each account.

Some email providers have a nifty feature that is not very well documented: the ability to easily create email aliases by including a plus sign in the address. Gmail, for example, allows you to use addresses such as and as synonyms. If you aren’t using Gmail, check with your company’s system administrator to see if your email server supports this functionality. It can make setting up various AWS accounts much simpler since they will be associated with a single inbox. If you don’t have that feature available, another option is to set up distribution lists instead of fully functional email accounts.
  1. Select your desired region.
  2. Check the box to grant Control Tower the administrative privileges it needs to administer accounts on your behalf.


  1. Launch your Control Tower installation and go to the Dashboard, where you can watch the progress as it creates resources and accounts for you in the background. While the setup is in progress, you will receive a few emails, so keep an eye on your inbox so that you can verify your email address and confirm the subscription to Simple Notification Service (SNS) notifications related to the new accounts:

AWS Control Tower Launching
  1. When the landing zone is fully launched, take some time to explore the Dashboard and inspect the various components, including Organizational units, Accounts, Preventive guardrails, Detective guardrails, Recommended actions, and Non-compliant resources.
  2. You should have received an email with the following subject line:  Invitation to join AWS Single Sign-On. Click Accept Invitation to create credentials for the master Single-Sign-On (SSO) user. Keep in mind that this is not the same identity that you used to create the master account, even if it does share the same email address! You will use these credentials later in this recipe.
  3. On the side navigation bar, click Guardrails and scroll down to the bottom. Click Disallow public read access to S3 buckets. Note that this is a detective guardrail, meaning that provisioned accounts will not be prevented from creating public buckets, but you will receive a notification if a bucket is marked as public. We will test this guardrail in subsequent steps.


  1. Scroll down to Organizational units enabled and click Enable guardrail on OU. Choose the custom OU and enable it. It may take a few minutes to appear in the list of enabled OUs. You should see an email with the subject line  Config Rules Compliance Change to alert you to the configuration change that was made to the Custom OU:

Organizational units enabled
  1. Log out of your account and then log back in with the SSO credentials you created in Step 8.
  2. Once logged in, you will land on a screen titled Your applications. Click the orange cube to see a list of accounts that you can access with this user:

SSO accounts
  1. Click your Master account and log in to the management console as an administrator.
  2. On the side navigation bar, select Users and access, and then click View in AWS Single Sign-On:

Control Tower Users and access
  1. On the SSO Directory page, click Add User. Create a new user account.
  2. Add the user to the AWSAccountFactory group:

Add user to groups screen
  1. Complete the user creation process. Log out of the console, and also log out of SSO. Then, log back in as the new user you just created. This is important because we need to be logged in as a user who has rights to provision accounts, and we want to simulate a real-world scenario: a user provisioning an account and then creating non-compliant resources.
  2. Go to the Service Catalog service dashboard.
  3. In the  Service Catalog, choose AWS Control Tower Account Factory. Click Launch Product.
  4. Fill in the parameters, tag options, and notifications for the new account. Launch the product and wait for your new account to be fully provisioned. When the process has finished, you can use AWS SSO to sign in to the new account.


  1. Once you’re logged in to the new account, create an S3 bucket and give it public access. (Note that this is bad practice and you should never create public buckets! Don’t put any files into this bucket!) Use the following bucket policy to open the contents of the bucket to the world:
    "Version": "2012-10-17",
    "Statement": [
            "Action": "s3:",
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::my-noncompliant-bucket-name/",
            "Principal": "*"

The following screenshot shows what the bucket policy screen will look like:

Bucket policy

The S3 console makes it very obvious when you have created a public bucket since it is considered bad practice!

  1. Log out of the console and out of the SSO. Then, log back in as the administrator. If the guardrail on the Custom OU has had time to propagate, you should be able to go back to the guardrail screen and see the warning under Noncompliant resources:

Guardrail components

At this point, you have created the basis for a secure, enterprise-ready account foundation on AWS. If you do not plan to continue using these accounts, be sure to go to each account and clean up the resources, as you may incur some future charges.

How it works…

AWS Control Tower is a service that helps you organize multi-account environments by creating a set of guardrails, which are sets of governance rules that specify the default operational and security posture of accounts that are created in this environment. It uses AWS SSO to manage a directory of users, whether this is a self-managed directory or your on-premises Active Directory installation. AWS Organizations and AWS Service Catalog are used to provide an Account Factory to your users so that they can create accounts that automatically comply with your company’s best practices.


It’s important to understand the role of each of the accounts that are created by Control Tower when you launch a new environment. In the following diagram, you can see that we start with a master account. Within that account are AWS Organization’s Organizational Units (OU), called Core and Custom. Under the Core OU, Control Tower creates a Log Archive Account and an Audit Account. Later, you and your users will make use of AWS Service Catalog to create Provisioned Accounts under the Custom OU:

Control Tower accounts

Each of the blocks in the preceding diagram represents an account:

  • The Master Account: This account is where all of the coordination happens for your multi-account environment. Take extra precautions with regard to user access in this account, and be careful with any actions you take here because you can affect all of the child accounts.
  • The Log Archive Account: The logging account keeps a copy of the AWS CloudTrail and AWS Config logs as a secure backup to the copy that is kept in each provisioned account for operational purposes. It is good practice to store these logs in an account that is only accessible to auditors. That prevents a bad actor from covering up their tracks in an account where the logs are not shipped to a different location.
  • The Audit Account: This account is to be used by auditors and comes equipped with cross-account roles into the other accounts. Auditors and security staff should log in to this account and then use those cross-account roles to switch context into the affected accounts while they are conducting investigations or implementing emergency security measures.
  • Provisioned Accounts: These accounts are the whole reason we have gone to the trouble of creating our environment with Control Tower. This is where your application lives. You may have a single provisioned account to host your resources, but it’s more likely that you will have a long list of accounts that are used for various purposes. It is good practice to create a separate account for production and development environments, for instance, to reduce the blast radius of changes that are made during the development process.
In preview editions of Control Tower, a third core account was dedicated to shared services. This account was meant to host resources that need to be shared across all your provisioned accounts. A good example of something that should be provisioned in a shared services account is your domain registration. Use Route53 to register a domain, but then delegate the name servers to one of your provisioned accounts where the domain is configured. This makes it much easier to switch an application from one account to another. 

Since this account is no longer created for you, our recommendation is to provision an account under the Custom OU for shared services.

There’s more…

AWS Control Tower uses guardrails to help you establish a compliant environment where all the subordinate accounts follow your company’s best practices. Guardrails fall into one of two broad categories:

  • Detective
  • Preventative

Detective controls make use of AWS Config Rules to alert you to resources that are out of compliance within provisioned accounts. You can take manual action to correct the problems, or you can use AWS Lambda to automate your response.

Preventative controls use Service Control Policies (SCP) to make certain actions impossible within provisioned accounts, even to the root user! You must take great care with SCPs since they can have drastic effects on a large number of child accounts.

See also

  • The Setting up a master account with AWS Organizations recipe in this chapter
  • The Adding a Service Control Policy (SCP) recipe in this chapter

Comments are closed.