Deploying a Landing Zone with AWS Control Tower - Part 2

2022-09-05 8 min read Walkthroughs Adam Divall

Previously in Part 1 of this Walkthrough, I touched on what a Landing Zone was and a brief background on them before going through how to launch AWS Control Tower as the foundation of a Multi-Account Architecture.

In this , I’m going to walkthrough through some of the initial post configuration activities with Control Tower including setting up the organisational structure and enabling guardrails.

What has Control Tower deployed?

As part of the setup, Control Tower has utilised a number of other AWS Services including:

AWS CloudFormation: This has been utilised for provisioning resources through Infrastructure as Code (IaC) across the multiple AWS Accounts using a combination of both Stacks and StackSets.
AWS CloudTrail: An Organizational Trail has been configured in the Management AWS Account. This Trail is configured to monitor all AWS regions, send its logs to an S3 Bucket that is in the Log Archive account, is encrypted using the KMS CMK that was created during the Control Tower setup, has Log File Validation Enabled, is integrated with CloudWatch Logs and also configured to send notifications to an SNS Topic in the Audit Account when new logs files are sent to the S3 Bucket.
Amazon CloudWatch: CloudWatch Log Groups are created as part of the integration with the CloudTrail Trail, as well as any execution of the Lambda Functions deployed by the Control Tower setup.
AWS Config: An Organization Config Aggregator is created within the Management Account and Config Recorders are created in all AWS Accounts within the AWS Organization with the exception of the Management Account. In addition, several Config Rules will be created as part of the Mandatory Guardrails configured during the setup process.

AWS Config is something that we should have enabled in all AWS Accounts and since Control Tower doesn’t create a Config Recorder in the Management Account we’ll need to do this. I’ll explain how this can be done later using Customisations for Control Tower.
Amazon EventBridge: An EventBridge Rule is created within all AWS Accounts with the exception of the Management Account to trigger a Lambda Function on any Config Rule Compliance Change.
AWS IAM: Several IAM Roles are created including IAM Service Roles. The IAM Roles have IAM Permissions Policies added to them to grant the relevant level of permissions and the Trust Policies are configured to allow the Role Assumption by only specific Source AWS Accounts, AWS Services or via the SSO Identity Provider using SAML.
AWS IAM Identity Center: This service gets enabled within the Home Region of Control Tower to provide Single Sign-On. Several Groups & Permission Sets are created and those Groups then have a Permission Set assigned to them against the provisioned AWS Accounts within the AWS Organization (Management, Audit and Log Archive Accounts). A User is also created that maps to the e-mail address of the root user of the Management AWS Account.
AWS KMS: AWS Managed KMS keys are utilised for the encryption of data at rest in conjunction with the creation of the S3 Buckets. In addition, as part of our setup configuration we also created a Customer Managed Key (CMK) to encrypt the CloudTrail Trail.
AWS Lambda: A Lambda Function is created within all AWS Accounts with the exception of the Management Account. This Function used as part of the mechanism for forwarding notifications of Config Rule compliance changes.
AWS Organizations: This has been used to create the Organization which is crucial to a Multi-Account setup. As part of the Organization it has then setup two Organizational Units (OU) that were defined during the Shared Accounts page of the Control Tower setup. Typically these OUs will be named Security (in previous versions of the Control Tower service it was named Core) and the other Sandbox. In addition, several Service Control Policies (SCP) will have been created as part of the Mandatory Guardrails configured during the setup process.
Amazon S3: Two S3 Buckets are deployed within the Log Archive account.
- One Bucket is used for the storage of CloudTrail and Config logs as part of a Centralised Logging Solution. It is configured with Default Encryption using KMS (AWS Managed Keys), has Versioning enabled, a Bucket Policy to restrict access, is configured to Block Public Access, Access Logging enabled and is configured with a Lifecycle Policy.
- The other S3 bucket is used for the storage of the S3 Access Logs. It is configured with Default Encryption using KMS (AWS Managed Keys), has Versioning enabled, a Bucket Policy to restrict access, is configured to Block Public Access, Access Logging enabled and is configured with a Lifecycle Policy.
AWS Service Catalog: A Portfolio is created with a Product added that provides Control Tower with Account Factory component.
Amazon SNS: An SNS Topic is created within all AWS Accounts with the exception of the Management Account. That Topic has a destination of a Lambda Function that then forwards the message to another SNS Topic in the Audit Account which in turn then sends an e-mail to the the e-mail address assigned to the root user of the Audit Account.
AWS Step Functions: Whilst the Control Tower setup implements State Machines that is used as part of the wider orchestration and for the Account Factory element, these are not visible within any of the AWS Accounts that exist in the AWS Organization. These are under the control and management of AWS as part of the Service Offering.

Organisational Structure

There is a really good blog post from AWS on the Best Practices for Organizational Units that describes each of the OU’s and there purpose. However, these are just guidelines and should be tailored to meet the needs of your particular Business.

The diagram below is based on what I typically see when working with Clients.

Creating the OU Structure

Click Organization.

Click Create resources and then Select Create organizational unit.

On the Add an OU page; Enter the OU Name, Click Parent OU and then Select the OU Name to replicate the high level organization layout.

Once configured it will look something similar to the below screenshot.

Only Organisation Units that have been created through the Control Tower Console will show a state of “Registered” on the Organization page in Control Tower. If the Organisation Unit was created either via the AWS CLI or within AWS Organizations, it will show a state of “Unregistered” and will therefore need to be registered by selecting the OU in question on the Organization page in the Control Tower console, selecting “Actions” and then Clicking “Register organizational unit”.

Configuring Guardrails in Control Tower

Guardrails are rules that enable you to provide ongoing governance and oversight across your environment. In terms of guardrails within Control Tower there are 2 different types - preventative and detective.

Preventative guardrails are implemented through Service Control Policies (SCP) and stop you from going outside of a specific set of boundaries as defined within the SCP. Since SCPs are implemented at the Organisation level, it provides a layer of control over all AWS Accounts within the organisation without needing to implement something directly in every single AWS Account.

Detective guardrails on the other hand are implemented through Config Rules and will send notifications if a resource within the individual AWS Account doesn’t adhere to the settings within the rule. For example, if the rule says that all EBS Volumes must be encrypted and there is an EBS Volume within the Account that isn’t it will notify you.

Control Tower guardrails can only be implemented on Organisation Units and not directly on AWS Accounts. Thats not to say you couldn’t create something customised, but in that case you’d need to write some automation to do this and it wouldn’t be shown within the Control Tower console if something was non-compliant.

When enabling a guardrail in Control Tower, it creates a CloudFormation StackSet in the Management Account and leveraging the integration with AWS Organizations it adds a CloudFormation Stack Instance for each AWS Account that resides within the hierarchy of the OU that the guardrail was enabled on to the StackSet, that in turn creates a CloudFormation Stack within the corresponding AWS Account. Similarly with the disabling of a guardrail, it deletes the Stack Instance from the StackSet and in turn then deletes the Stack from the corresponding AWS Account.

Enabling Guardrails

Click Guardrails.

Find the guardrail that you’re want to implement by either scrolling through the pages until you locate it or by using the filter mechanism.

Click the Name of the Guardrail. For example, “Detect whether public read access to Amazon S3 buckets is allowed”.

Click Enable guardrail on OU.

Select the OU that you want to enable the guardrail on and then Click Enable guardrail on OU.
Repeat the process again for each OU that you want to enable the guardrail on. Unfortunately at this moment in time it can’t be added to multiple OUs at the same time, so has to be repeated.
Repeat the process for all guardrails that you want to enable.

Disabling Guardrails

Click Guardrails.

Find the guardrail that you’re want to implement by either scrolling through the pages until you locate it or by using the filter mechanism.

Click the Name of the Guardrail. For example, “Detect whether public read access to Amazon S3 buckets is allowed”.

Select the OU where the guardrail has been applied and Click Disable guardrail.
Repeat the process again for each OU that you want to disable the guardrail on. Unfortunately at this moment in time it can’t be removed from multiple OUs at the same time, so has to be repeated.
Repeat the process for all guardrails that you want to disable.

In Part 3 of this Walkthrough, I’ll continue with the remaining post-deployment activities within Control Tower including configuring IAM Identity Center and provisioning a new AWS Account through Account Factory.