AWS Control Tower is the easiest way to set up and govern a new, secure, multi-account AWS environment based on best practices. The service allows customers to create a landing zone, a centrally managed environment where they can create new AWS accounts or enrol existing ones, group those accounts into Organizational Units (OUs) and apply guardrails at the OU level. This ensures a consistent security posture for all of the accounts within an OU.

With AWS Control Tower, customers benefit from the flexibility of a multi-account structure. For example, each line of business or department can have their own AWS accounts so they have a level of autonomy while maintaining central governance and protection of those accounts.

By listening to our customers, the AWS Public Sector team learned that customers, particularly those operating in highly regulated domains, needed a solution which built on AWS Control Tower to provide additional security, guardrails, and observability. To satisfy that customer need, the AWS Professional Services team built an offering, consisting of automation to provide the additional security, guardrails and observability, alongside deployment and operations documentation. In addition, the Professional Services team can provide support to customers in deployment, security accreditation, migration services and ongoing operations.

Customers who are new to AWS and want to get started quickly will also benefit from this Professional Services offering. Those customers won’t need to invest time, resources, and money to understand AWS best practices before they build out their AWS environment. They can get going right away with the reassurance they will be building upon a best practice foundation and operating within the additional security, guardrails and observability provided by this offering. The offering provides a self-service provisioning capability so teams can quickly provision the resources they need and then focus on their core business.

Architecture Overview

The architecture extends the AWS multi-account best practice by creating Organizational Units (OUs) in addition to the default OUs and accounts provided by AWS Control Tower. Further details of the additional OUs and accounts can be found in the Extending AWS multi-account best practice section of this post. The AWS accounts shown as grey boxes in the following diagram belong to the additional OUs. Guardrails can be applied to the additional OUs to protect your accounts and other sensitive resources, such as your software development and deployment pipelines.

Multi-account architecture overview, showing additional accounts and OUs. These are described in the Extending AWS multi-account best practice section of this post

There are additional preventative and detective guardrails provided in the design that offer more protection for the resources within your AWS accounts. Amazon GuardDuty and AWS Security Hub are enabled to provide more security and observability.

Through a self-service provisioning capability provided by AWS Service Catalog, your teams no longer have to wait in line for a central team to provision resources for them or manually provision resources themselves. They can use predefined secure blueprints, known as Service Catalog Products, to provision resources automatically.

The offering includes a best practice centralised network, which provides private access to AWS services, simplified management of your network, and the ability to deploy packet inspection and filtering technologies. This extends the network standardisation offered by AWS Control Tower, as described in the Best Practice Networking section below.

The additional functionality and structure is applied through automation, which removes the manual burden on your teams and ensures the additional security, guardrails and observability are consistently applied. The mechanics of the automation are explained later in this post.

Extending AWS multi-account best practice

Using multiple AWS accounts is a recommended best practice because an AWS account provides a boundary for security and billing. For example, you can place a production workload in its own AWS account and provide very limited access to that account. You can easily see how much it costs to run that production workload because it is the cost of the AWS account. For more information about the multi-account best practice, see the Establishing your best practice AWS environment page and the Best Practices for Organizational Units with AWS Organizations blog post.

This AWS Professional Services offering extends the multi-account best practice provided by Control Tower through additional OUs and AWS accounts, specifically:

  • Internal OU, which contains the following AWS account:
    • Shared Services is for services used by multiple workloads or lines of business.
  • Networking OU, which contains these AWS accounts:
    • Internal Networking contains VPC Endpoints for private access to AWS services.
    • External Networking contains a preconfigured network layout, designed for an (optional) internet filtering solution. An internet filtering solution can provide more security and limit access to preapproved websites.
  • Sandbox OU will contain sandbox AWS accounts where lines of business or individuals can more freely experiment.
  • Workloads OU will contain an AWS account for each workload, or groups of workloads, as per the customer requirement. You can provide more security to AWS accounts under this OU by applying more guardrails to the OU.
  • Deployment OU will contain AWS accounts that contain your deployment or CI/CD services. Ultimately, the services in the accounts under this OU are driving your software development pipelines, housekeeping and deployment automation, these are the foundation of your digital business or operations. By placing these services in their own OU, you can apply additional security to them.
  • Suspended OU is for AWS accounts that are no longer required. You can apply guardrails to the OU to make these AWS accounts read-only.

This OU structure can be customised to suit your needs. You’ll find more examples of multi-account structures in the AWS re:Invent 2019: Architecting security & governance across your landing zone (SEC325-R2).

Accelerating customers who are new to AWS

Starting out on your cloud journey can be a daunting task. Customers often want to get started quickly, to get that competitive edge. However, they don’t want to discover down the line that those first steps, which are now the foundation of their AWS environment, need unpicking and reimplementing. This is where AWS Control Tower and this offering in particular, fits in: Customers can get started quickly knowing they are building upon a best practice foundation with the assurance of the additional security, guardrails, and observability.

Self-service provisioning

A self-service provisioning capability is a common customer requirement. This offering provides that capability through AWS Service Catalog. Customers can quickly and easily provision AWS resources without having to deeply understand AWS and technologies such as AWS CloudFormation, or wait in line for a central team to provision the resources they need. The offering provides self-service items, known as Service Catalog Products, for common tasks such as creating a virtual private cloud (VPC); connecting a VPC to a centralised network, and providing private access to AWS services. As customer AWS usage increases and they become more familiar with technologies like AWS CloudFormation, they can develop their own Service Catalog Products; this will provide additional self-service items to accelerate their teams.

How we extended AWS Control Tower

Automation is essential to this solution. When a customer creates an AWS account through AWS Control Tower, we didn’t want the customer to have to manually apply additional guardrails to that account. We wanted the solution to do so automatically. For this reason, we used AWS Control Tower Lifecycle Events. The lifecycle events are emitted when AWS Control Tower completes an action, such as creating an AWS account or OU. The following diagram shows how the automation works.

Control Tower Lifecycle Events automation, which is described in the following text

  1. The customer takes an AWS Control Tower action, such as creating an AWS account through the Account Factory.
  2. That action causes a lifecycle event to be emitted. The automation intercepts that using Amazon EventBridge, where rules determine the target for that lifecycle event, typically a Lambda function.
  3. The Lambda function processes the lifecycle event, determining the action to take based on the content of that event.
  4. The Lambda function takes the appropriate action, for example, using AWS CloudFormation StackSets to apply additional guardrails to the OU, protecting both the new account and all others in that OU.

For examples of how AWS Control Tower lifecycle events can be used, see the Using lifecycle events to track AWS Control Tower actions and trigger automated workflows blog post.

Additional Guardrails

AWS Control Tower provides both preventative and detective guardrails. Preventative guardrails are implemented through service control policies (SCPs), which are statements governing the maximum permissions or actions that can be carried out within the entire organization, an OU, or an individual AWS account.

Detective guardrails are implemented through AWS Config rules, which are specifications of your desired configuration. If AWS Config detects that a resource configuration has deviated from your desired configuration, it flags the resource (and the rule) as non-compliant. AWS Config optionally allows you to remediate, manually or automatically.

When customers using this offering provision AWS Control Tower or create additional OUs, the automation applies additional SCPs. These SCPs provide additional preventative guardrails for example, only allowing users to provision resources in a single AWS region or enforcing encryption at-rest and in-transit for S3 buckets.

As AWS accounts are created in AWS Control Tower, the offering automatically applies additional AWS Config rules to the new account and all other accounts within the same OU. These rules enable more detective guardrails.

The benefit of the additional guardrails being applied automatically include:

  • Customers have a consistently improved security posture.
  • Customers don’t need to spend time manually applying the additional guardrails.
  • Centralised visibility of AWS Control Tower and additional guardrails in the AWS Config Aggregator dashboard.

The full list of additional preventative and detective guardrails can be found in the offering documentation pack. The Deployment and Operations Guide explains how to add guardrails according to the customer’s compliance requirements. 

Best practice networking

The offering extends the network standardisation provided by AWS Control Tower, where users are able to select from a predefined list of network layouts, for the initial VPC created in vended AWS accounts. Specifically, the solution provides a best practice, centralised, network layout, as shown in the diagram below:

Best practice network design, which is described in the following textThe key elements of the network solution are:

  • An AWS Transit Gateway is used to provide centralised management of internal network connectivity across AWS accounts and VPCs within Control Tower.
  • An Internal Networking account and VPC are created. All VPC endpoints are created in the Internal Networking VPC, providing centralised private network access to the AWS APIs. This lower costs because you no longer need VPC endpoints in each of your AWS accounts.
  • An External Networking account and VPC are created with a VPC peering connection to the Internal Networking VPC. All internet traffic, from all accounts and VPCs in AWS Control Tower, is routed through the External Networking VPC, providing the opportunity for traffic inspection and filtering. The AWS Marketplace and the AWS Control Tower Solutions sites include products you can deploy into the External Networking account to provide centralised traffic inspection and filtering

Additional Security Services

AWS Control Tower brings together multiple security services, such as AWS Config and AWS CloudTrail, to provide security guardrails and visibility. This offering automatically enables Amazon GuardDuty in all AWS accounts and Regions. The service continuously scans for malicious and unauthorised behaviour, using a combination of threat intelligence, managed rule sets, anomaly detection, and machine learning. This offering also automatically enables AWS Security Hub in all accounts and Regions. The service centralises security findings from both Amazon GuardDuty and AWS Config rules. AWS Control Tower administrators and your security team now have a single pane of glass to observe your security posture.

AWS Control Tower ensures that requests to AWS services within your accounts are recorded in AWS CloudTrail logs. This offering provides additional security and observability by analysing those CloudTrail logs and alerting your security administrators if potentially harmful or suspicious activity is detected. Particular focus is applied to the Log Archive and Audit accounts because this is where AWS Control Tower aggregates all security and configuration data. Across all AWS accounts in your organization, this offering detects and alerts security administrators if root user credentials are used. As a best practice, root user credentials should not be used in your AWS accounts. Instead, IAM users, groups or roles should be created, with least-privilege IAM policies attached to them.


In this blog post I showed how the AWS Professional Services team, through automation, extended AWS Control Tower to provide more security, guardrails and self-service capabilities. This benefits customers who need the additional security, guardrails and observability for their workloads and those customers who are new to AWS and want to get started quickly and safely.

Creation of this offering was a team effort, I’d like to thank the other members of the Public Sector team who built this solution, namely: Matt Stead, Chris Rose, Michael Gamlin, Dan Thomas, Luke Morfitt, Paul Ogden, Tom Garnett, Douglas Farr, Lynton Bell, Danny Temple and Charlie Llewellyn.

For more information about this AWS Professional Services offering, please contact the WWPS UK NatSec Professional Services team.

Andy Phillips

Andy Phillips

Andy Phillips is a Senior DevOps Consultant within AWS Professional Services. He is passionate about helping customers to increase their agility and security using automation and serverless technologies on AWS. In his spare time, Andy likes to be outside: playing with his kids, running or exploring a snowy mountain.