AWS Control Tower for Existing Organizations

Disclaimer: This is a personal weblog. The opinions expressed here represent my own and not those of my employer.

Introduction

Companies of all shapes and sizes utilize the public-cloud for hosting many critical applications and services. One common best practice for managing and governing the cloud at scale is to implement a fully governed and policy-driven multi-account strategy, i.e. Landing Zone. A successful multi-account landing zone has an accompanying automated account provisioning process. This allows builders to provision new AWS accounts while maintaining secure boundaries and adhering to the established policies.

In June 2019, AWS launched a fully managed landing zone solution, Control Tower. AWS Control Tower sets up an automated landing zone which employs best-practice blueprints managed by AWS Organizations, AWS Single Sign-on, automated account provisioning using AWS Service Catalog [Account Factory], centralized logging with AWS CloudTrail and AWS Config. Well established AWS customers have not been able to take advantage of AWS Control Tower as the product did not initially ship with support for an existing AWS Organization. Control Tower support for existing AWS Organizations is now Generally Available in US East (N. Virginia & Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Sydney).

This blog post will detail the steps to enable Control Tower in an existing AWS Organization and how to add Unregistered accounts to Control Tower as well.

Enabling Control Tower

As with any major migration thoroughly read all available documentation and release notes to ensure that the solution is right for your needs. Control Tower does have an explicit list of prerequisites. For example, ensure that in the AWS Organizations Master Account all supported Control Tower AWS Regions are Activated. AWS Security Token Service (STS) is used to deploy AWS CloudFormation StackSet(s) within the AWS Control Tower managed accounts.

Second, you will need to enable AWS CloudFormation StackSets in your AWS Organizations.

Log in to the Organization Master account as a user with AdministratorAccess role, in the AWS Management Console navigate to the Control Tower service. You are prompted for basic information including email addresses for the Audit and Log Archive accounts. Once completed ‘Launch your AWS Control Tower.” The entire setup process takes about 60 minutes to complete.

I recommend taking this time to venture over to the official Control Tower Documentation and read through the concept of Guardrails. Moving forward with ControlTower and into day 2 operations it will be important to understand how Mandatory, Strongly Recommended and Elective Guardrails apply along with the difference between each.

Upon completion you will be left with a fully implemented AWS Control Tower landing zone where you can begin working immediately. The Control Tower dashboard will show how many Organizational Units (OUs) and Accounts we have registered. In my environment I have 2 OUs (Core and Custom) and 3 Accounts (Master, Audit and Logging). You probably are asking, what about the OUs and AWS Accounts which already existed? Control Tower is implemented alongside existing OUs and accounts, no changes are made! You’re able to continue to use those OUs and accounts exactly as they are! The existing accounts and OUs will display as ‘Unregistered’ within the Control Tower interface.

Security & Compliance for New and Existing Accounts

OUs and accounts which were previously created outside of Control Tower are considered to be Unregistered, as mentioned above. Any OUs or accounts moving forward which are created outside of Control Tower will also be Unregistered. You should consider Control Tower and AWS Service Catalog Account Factory to be the new standard within your AWS Organization. At a high-level the process of Registering an Unregistered account is as simple as moving the Account into a Registered OU. However under the covers there are some prerequisites which need to be met so that the account is able to be properly governed.

If you recall previously we enabled trust access for AWS CloudFormation inside of our AWS Organization. This requirement exists because AWS Control Tower natively utilizes AWS CloudFormation StackSets to create, update and/or delete stacks across the multiple accounts and AWS Regions.

During the account enrollment process AWS Control Tower will baseline the account and deploy several StackSets. In order to complete these tasks ad role must be created in each account – AWSControlTowerExecution. This role will require an AdministratorAccess policy within IAM.

There are a few caveats which should be considered prior to registering new accounts with AWS Control Tower. For example, is there a default VPC in the account you wish to register? Is AWS Config been enabled in the account(s)? If the answer is yes to either of these questions action will need to be taken. The enrollment will fail when a default VPC or a default config recorder is present. For large organizations this will certain present a challenge.

A colleague at AWS has written a Control Tower Account Migration Script in Python which you can clone: https://github.com/aws-samples/aws-control-tower-reference-architectures

The script is very easy to use and has just a few basic inputs.

• -o Target Registered OU
• -u Origin UnRegistered OU
• -i Enroll a Single Account

For a detailed walkthrough of the Python steps mentioned above please visit the official AWS Documentation. The post leverages Amazon EC2 which you SSH into. I do not consider this to be a requirement as I was able to successfully use Visual Studio Code where I had already configured the necessary AWS credentials locally.

Alternative to the Python method, you may use the AWS Control Tower Account Factory to “Enroll” Unregistered accounts as well. If you have a small handful this may be the easiest route for you based on your individual experience level for example.

Conclusion

In this blog post I walked you through enabling AWS Control Tower in an existing AWS Organization. Are you planning to use or already use AWS Control Tower as your landing zone solution? Share your thoughts in the comments below!

I suspect this feature alone will generate more service adoption and many more companies will utilize AWS Control Tower to manage and govern their AWS environments.