AWS Cloud Operations & Migrations Blog

Scaling Landing Zone with AWS Control Towers

A landing zone (LZ) is a well-architected, multi-account AWS environment that is scalable and secure. This is a starting point from which your organizations can quickly launch and deploy workloads in the secured infrastructure environment. A well-defined LZ provides a set of guardrails and baselines with multi-account architecture, identity and access management, control, data security, network design, and logging. Building an LZ requires making decisions about account structure, networking, security, and access management in accordance with your organization’s growth and business objectives.

As enterprises scale their footprint in the cloud, they apply AWS best practices to establish an LZ in the cloud. These best practices center around the need to isolate resources and workloads into multiple AWS accounts (resource containers) for isolation and scope of impact reductions. The following are the various benefits of using a multi-account LZ:

  • Security Control: Different applications can have different security profiles, with varying control policies and mechanisms around them.
  • Isolation: Potential risks and security threats can be contained within an account without affecting others.
  • Data isolation: Data stores can be isolated to the account, limiting the number of people that can access and manage it. This controls exposure to highly-private data and helps with General Data Protection Regulation (GDPR) compliance.
  • Many teams: Controlling access based upon responsibilities and specific resource needs.
  • Business process: Supporting business-specific purposes and processes.
  • Billing: Separate items at a billing level across business units, functional teams, or individual users.
  • Limit allocation: Limits are per account. Separating workloads into different accounts prevents them from consuming limits or potentially overprovisioning.

In addition to establishing an LZ, many enterprises apply micro account strategy to control the security blast radius, provide developers with frictionless infrastructure provisioning, and maintain standardized controls. A set of AWS accounts are allocated to a project, application, or a microservice, and it’s owned by a team. This enables agility, independence of development, deployment, increased speed of experimentation, and innovation.

AWS has two options for creating your LZ: a managed service-based LZ using AWS Control Tower and a custom LZ that you build and maintain. AWS Control Tower helps you save time by automating the setup of an LZ so that you can run secure and scalable workloads. It provides the easiest way to set up and govern a secure, multi-account LZ. AWS Control Tower orchestrates the set-up of integrated services, such as AWS Service Catalog, AWS Single Sign-On (AWS SSO), AWS CloudTrail, and AWS Organizations, to provision accounts, log actions, and manage access to those accounts. With AWS Control Tower, you can control newly created accounts or extend control into existing accounts, along with gaining visibility into their compliance status.

AWS Control Tower applies both preventive and detective controls (guardrails) to help keep your organizations and accounts from drift and divergence from best practices. The provided guardrails are based upon AWS best practices and AWS Well Architected (AWS WA) recommendations curated from thousands of customer LZ implementations. Preventive guardrails are Service Control Policies (SCPs) applied at the Organizations and Organization Unit (OU) level. Detective guardrails are applied by enabling individual AWS Config rules at each AWS account and governed region. Account Factory, a configurable account template and account creation workflow, standardizes the provisioning of new accounts with pre-approved account configurations. Refer to the AWS Control Tower user guide for details regarding various guardrails.

AWS Control Tower performs the following actions in your management account on your behalf:

  • Creates a ‘Security’ OU with Log Archive and Audit accounts.
  • Creates optional OU for your workload accounts. Existing OU can be opted in.
  • Creates a cloud-native directory in AWS SSO, with preconfigured groups and AWS SSO access. Your existing Active Directory (AD) or external Identity Provider (IdP) can be integrated with AWS SSO.
  • Applies mandatory preventive guardrails to enforce policies and detective guardrails to detect configuration violations.

Each AWS Control Tower supports 300 accounts per OU. This account limit can be extended further by limiting control to AWS regions in which your enterprise operates. Many large enterprises may exceed this limit and choose to deploy multiple AWS Control Towers. The solution described here shows how this can be accomplished using an automated process.

Overview of solution

Many enterprises create multiple Organizations as they scale their footprint in the cloud. This may result from the business need for data sovereignty and independent business OUs that manage their own cloud and scalability needs. Simultaneously, these enterprises can also benefit from having a centralized place to create AWS accounts, apply the account baseline, and guardrails. As a result, these customers can avoid having multiple teams doing the same type of task for each organization.

Following is a reference architecture for establishing a multi-organization LZ by using multiple AWS Control Towers. The solution described here accepts account creation requests from users and abstracts orchestration details across multiple AWS Control Towers. It provides the following benefits:

  • Provides a single API and a routing mechanism for clients to request new AWS accounts across multiple organizations.
  • Use multiple organizations to enable enterprises to scale their account creation beyond the quota supported by Organizations.
  • Enable a decentralized baseline model, where individual infrastructure teams can participate in the account creation process and apply their own baselines.
  • Enable enterprises to apply baselines and guardrails at the global level, and let each OU apply their own local baselines and guardrails.

The following architecture diagram shows an automated LZ solution using multiple AWS Control Towers.

Architecture Diagram.

Figure 1. Architecture Diagram.

Walkthrough

The following is the solution execution sequence:

  1. Application team leader provisions AWS Service Catalog Product Workload or invokes Amazon API Gateway API to create accounts for a given application associated with a specific deployment model. If the request was made by provisioning AWS Service Catalog Product, then an AWS CloudFormation Stack is provisioned to publish the workload request message to the SQS Queue. If the request was made via API Gateway, then it’s validated and forwarded to the same SQS queue of the Request Processor Lambda. The example JSON request payload is as follows:
JSON Request Example.

Figure 2. JSON Request Example.

  • deploymentType’: Deployment model type as defined by your organization. Each deployment model type maps to one or more deployment environment. Then, each deployment environment maps to an AWS Control Tower group associated with that environment. Examples of deployment types are as follows: devops, sandbox, analytics, etc.
  • ‘applicationName’: Unique application name. Account name of each newly created AWS Account is derived from this attribute value by appending it with the deployment environment.
  • ‘accountEmail’: Used to generate unique email addresses for each newly created account. Each account’s email address is derived from ‘accountEmail’, ‘applicationName’, and associated deployment environment.
  • AWS SSO User attributes: First name, last name, and email address of the AWS SSO User.
  • AWS Service Catalog Product matches the request payload parameters.
  1. Request Processor Lambda receives and validates the request.
  2. Request Processor Lambda retrieves mapping between ‘deploymentType’ and associated deployment environments from the configured environment variable. For example:
JSON Config Example.

Figure 3. JSON Config Example.

  • In the above example, ‘devops’ deployment type maps to ‘Dev’, ‘Test’, ‘PreProd’, and ‘Prod’ deployment environments. Each deployment environment has an associated AWS Control Tower.
  1. AWS Lambda retrieves configuration about a given AWS Control Tower from the ‘ControlTowers’ Amazon DynamoDB  table. It validates the application name for uniqueness in the database. It generates unique AWS Account email addresses using the user-provided account email, application name, and deployment environment. Application name and environment values are appended to the provided email using the ‘+’ symbol.
  2. Lambda prepares all of the attribute values for new AWS Account request and writes those to the ‘CT_Accounts’ DynamoDB table. Account creation status is marked as ‘PENDING’. This allows for the ability to sequence account creation in a given AWS Control Tower and avoid provisioning failures. Lambda queries the ‘CT_Accounts’ table to identify and provision ‘PENDING’ accounts and AWS Control Towers with no active ‘Account Factory’ AWS Service Catalog provisioning request.
  3. Lambda assumes an AWS Identity and Access Management (IAM) Role to broker the security token using AWS Security Token Service. It invokes AWS Service Catalog APIs to provision Account Factory Service Catalog Product.
  4. All AWS Control Tower management accounts are configured to forward AWS Control Tower CloudWatch events to the Control Plane management account.
  5. The Control Plane management account is configured to invoke Lambda when AWS Control Tower CloudWatch events are received.
  6. Lambda processes the AWS Control Tower CloudWatch event to update the ‘CT_Accounts’ table with the newly created AWS Account’s account ID.
  7. Once all of the accounts associated with a given request have been created, Lambda composes a JSON message with information about newly created accounts for the given request, and then sends an Amazon Simple Notification Service (Amazon SNS) notification to the configured topic. Then, additional on-boarding and configuration activities can be initiated. These activities can be distributed across multiple onboarding domains and groups.
  8. Scheduled periodic Amazon CloudWatch event triggers Request Processor Lambda to check for any failed requests and to initiate the provisioning of pending requests.

Deployment and setup

The following section describes the steps to deploy and set up the solution.

  1. A new or existing AWS Account can be used to function as the Control Plane Management Account. Additionally, each AWS Control Tower is set up in an independent AWS Account. Refer to documentation to create new AWS Accounts.
  2. Deploy the attached ‘control-plane-setup.yaml’ CloudFormation Stack to the Control Plane Management Account. This will deploy the Request Processor Lambda, DynamoDB, Lambda IAM Role, Amazon SNS topic, API Gateway, SQS Queue, CloudWatch Event Rule, Service Catalog Workload, product and other resources.
    1. Upload the provided Request Processor Lambda zip file to an Amazon Simple Storage Service (Amazon S3) bucket in your account.
    2. Upload the provided ‘workload-product.template’ CloudFormation stack to the S3 bucket in your account and note the associated http URL.
    3. Navigate to the CloudFormation console to deploy the ‘control-plane-setup.yaml’ CloudFormation Stack. Enter the listed parameter values as described.
CFT Parameters.

Figure 4. CFT Parameters.

Refer to step-3 in the execution sequence for the JSON definition of the ‘DeploymentTypeToEnvironmentMapping’ parameter.

  1. Identify the management accounts for each new AWS Control Tower.
  2. Enable each AWS Control Tower using the following steps:
    1. Log in to the management account of a new AWS Control Tower.
    2. Request a higher account limit that satisfies your demand by visiting the Service Quotas console for Organizations.
    3. Set up AWS Control Tower LZ using the provided instructions. You may select additional AWS regions to govern under the AWS Control Tower and create additional workload OUs as described in the instructions.
    4. If desired, navigate to the AWS SSO console to configure the external identity source, such as: AD or External IdP.
    5. Deploy the attached ‘control-tower-setup.yaml’ CloudFormation Stack to each AWS Control Tower management account. Provide the following parameter values as described.
CFT Parameters.

Figure 5. CFT Parameters.

Note that the AWS Control Tower Account Factory Portfolio Id and Product Id can be found from the AWS Service Catalog Console, under the Portfolios Administration section.

  1. Navigate to the Amazon EventBridge Console in the Control Plane account and update the resource policy for your event bus to allow the AWS Control Tower account to forward AWS Control Tower Cloud Watch events. The following is the example JSON resource policy.
JSON Resource Policy Example.

Figure 6. JSON Resource Policy Example.

  1.  Navigate to the DynamoDB console to insert information about each AWS Control Tower into the ‘ControlTowers’ table. Update place holder values in the following example attributes.
DynamoDB Item Example.

Figure 7. DynamoDB Item Example.

Test using Service Catalog

  1. Navigate to the AWS Service Catalog Console in your Control Plane account.
  2. Launch ‘Control Plane Workload’ Product.
  3. Provide the unique provisioned product name and enter the following parameter values.
CFT Parameters.

Figure 8. CFT Parameters.

Test using API Gateway

  1. Log in to API Gateway to retrieve the Invoke URL for the ‘POST’ method of the ‘/workload’ resource.
Test via API GW

Figure 8. Test via API GW

  1. You may invoke the endpoint URL using various tools, such as: curl, Postman, etc. The following steps describe using curl.
  2. Prepare the JSON payload request.json file for the HTTP POST request to the /workload resource. Update the values in the following example payload.
JSON Request Example.

Figure 9. JSON Request Example.

  1. Execute the curl command to invoke the API Gateway resource.

Curl Request Example.

  1. Request payload is processed as described in the architecture section above.
  2. The account creation process can take few minutes. Log in to various AWS service consoles to observe the request execution.

Conclusion

This blog post described how AWS Control Tower service can be used to enable horizontally scalable enterprise landing zone. Solution described here provides a single API and a routing mechanism for clients to request new AWS accounts across multiple organizations. It enables a decentralized baseline model, where individual infrastructure teams can participate in the account creation process and apply their own baselines.

Additional information

Customization for AWS Control Tower

AWS Control Tower provides a collection of guardrails out of the box. There guardrails are classified as: mandatory, strongly recommended, and elective. All mandatory guardrails are enabled by default when you set up your LZ and can’t be disabled. Strongly recommended guardrails are based on best practices for well-architected, multi-account environments, and they aren’t enabled by default. However, it’s highly recommended to enable these guardrails across various workload account OUs of your Organization. Elective guardrails enable you to lock down or track attempts at performing commonly restricted actions in an AWS enterprise environment, and these guardrails aren’t enabled by default.

You may need to apply additional preventive and detective guardrails that are specific to your organization. You may also have a need to create additional baseline AWS resources (such as, IAM Roles, CloudWatch Events forwarding, etc.) into newly created workload accounts before those accounts are ready to be used. The Customizations for AWS Control Tower solution provides the ability to apply these custom guardrails and baselines. Deploy the Customizations for AWS Control Tower solution Cloud Formation stack into each AWS Control Tower management account.

Control Tower Customization.

Figure 10. Control Tower Customization

The newly created AWS account via AWS Control Tower Account Factory generates an CloudWatch Event. Then, this event triggers an AWS CodePipeline to apply your custom guardrails and baselines to the newly created account. This solution also enables you to establish a CI/CD DevOps process to manage your custom guardrails and baselines using GIT repository. Updates to guardrails and baselines are applied to all configured target OUs and accounts in the manifest YAML file. All of the resources listed in the manifest file are applied or updated sequentially. The CloudFormation custom resource could be deployed as the last resource in the manifest file to detect when the deployment of custom guardrails and baselines is complete. This custom resource can publish notifications to an Amazon SNS topic configured in the Control Plane Management Account.

AWS SSO

AWS SSO is a cloud-based service that simplifies how you manage AWS SSO access to AWS accounts and business applications. You can control access and user permissions across all of your AWS accounts in Organizations. AWS Control Tower uses AWS SSO to set up and manage access to the accounts created through Account Factory. AWS SSO can act as the User Store and as an identity source for those users, or it can point to an external identity source, such as: AD or External IdP. Each AWS Control Tower and associated Organization will have its own AWS SSO. However, each AWS SSO could point to the same identity source in your enterprise. The AWS Control Tower home Region must be the same as the AWS SSO Region. AWS SSO can be installed only in the management account of the organization.

About the authors:

Sanjay Patel

Sanjay is a Senior Cloud Application Architect with AWS Professional Services. He has a diverse background in software design, enterprise architecture, and API integrations. He has helped AWS customers automate infrastructure security. He enjoys working with AWS customers to identify and implement the best fit solution.

Alex Rosa

Alex Rosa is a Principal Cloud Architect with AWS based out of Florida, USA. In the last years, he helped dozens of enterprise customers to improve their businesses by adopting the AWS cloud. When he is not working, he loves to hang out with his family or learn new stuff.

Suhas Pasricha

Suhas is a Cloud Infrastructure Architect in the AWS Professional Services (ProServe) team. He has a background in web development & infrastructure automation. At Amazon he has been helping customers setup and operate an enterprise-wide landing zone. In his spare time, he likes to read & play video games.