AWS Feed
Fast and Secure Account Governance with Customizations for AWS Control Tower
Organizations around the world value a secure, well-architected, AWS environment that provides a strong foundation for their cloud operations. They seek a multi-account strategy that delivers operational excellence, security, reliability, performance, and cost optimization of their AWS resources now and into the future.
AWS Control Tower delivers on this multi-account strategy by orchestrating various AWS services. It sets up a landing zone using AWS Organizations and AWS Service Catalog. A landing zone provides a multi-account AWS environment with account structure, governance, network, and security configurations. Over time, as your organization grows, the landing zone must evolve to secure and organize your workloads and resources.
In this blog, I will show you how to customize your landing zone to align with your business needs using an AWS Solution called Customizations for AWS Control Tower.
Architecture overview
When you deploy AWS Control Tower, it creates two Organizational Units (OUs) under AWS Organizations. One is for shared accounts, and the other is for accounts provisioned by your users. An OU is a construct for grouping accounts for governance. You can create your own OU and add existing or new accounts to it.
Customizations for AWS Control Tower enable you to deploy resources and governance at scale in your AWS Control Tower managed landing zone.
Figure 1. Architecture for Customizations for AWS Control Tower
The solution must be deployed using an AWS CloudFormation template in the same AWS Region and management account as your AWS Control Tower landing zone. Once deployed, you can configure the solution to your needs using a configuration package. The package contains a manifest file, templates, and related files that are stored in Amazon Simple Storage Service (Amazon S3) by default. You can choose AWS CodeCommit as your source repository instead of Amazon S3 at the time of deployment. This manifest describes the AWS resources to deploy to your OU or account(s) in specific AWS Regions. It points to the CloudFormation template for resources, and a JSON file for the AWS Organizations service control policies (SCPs). The solution deploys AWS CloudFormation StackSets and AWS Organizations SCPs across multiple accounts and Regions.
The solution takes a DevOps approach to deployment by using AWS CodePipeline for continuous integration and delivery. CodePipeline extracts the contents of the package stored in your source repository and kicks off the build and deployment process. If a manual approval step is needed, you can configure the pipeline to include one.
When you create a new managed account using AWS Control Tower Account Factory, the solution uses the AWS Control Tower Lifecycle Event to invoke the CodePipeline workflow. The workflow deploys the existing stack of AWS resources to the new account.
Note: The solution uses AWS Key Management Service (AWS KMS) to encrypt the configuration ZIP file in S3. Modify the key policy to grant the AWS Identity and Access Management (AWS IAM) role or user permission to download/upload the ZIP file.
Use case matrix
Now let’s look at some typical scenarios. The matrix in figure 2 shows the behavior of the solution to changes in your AWS Control Tower managed landing zone.
Let’s start by defining the terms used:
- New OU: A custom OU that you create in your landing zone. Assume that there are no AWS accounts associated with this OU.
- Existing OU: An OU that was created by AWS Control Tower, or an OU that has been brought under its management. Assume that this OU has accounts associated with it.
- New Account: Account created using AWS Control Tower Account Factory.
- Existing Account: An account that was previously provisioned using Account Factory or enrolled into Control Tower.
Figure 2. Matrix of use cases
Let’s dive into these use cases using concrete examples.
Deep dive: Resource deployment and account governance
Consider an organization with multiple projects comprising multiple teams.
Figure 3 shows each project mapped to an OU. A project OU has teams with dedicated AWS accounts.
Figure 3. Example AWS Control Tower managed landing zone – Current state
Project1 OU has Team1 Acct with storage and compute resources. Team1 uses Amazon S3 to store files and Amazon Elastic Compute Cloud (Amazon EC2) to process them. The admin defines these resources in a CloudFormation template and includes them in the configuration package ready to be deployed for new accounts. Project1 OU has SCP1 in place that denies public access to S3 buckets, and allows launching only specific EC2 instance types. SCP1 governs Team1 Acct.
Project2 OU has two team accounts, Team3 and Team4. Team3 works with serverless technologies and uses AWS Lambda. Team4 has yet to decide on a compute strategy. Project2 OU has SCP2 in place that denies public access to S3 buckets. SCP2 governs Team3 and Team4 Accts.
New account added to existing OU
Consider a future scenario where Project1 expands and hires a second team.
Figure 4. Update to landing zone – Team2 Acct added to Project1 OU
An account is provisioned for Team2 using AWS Control Tower Account Factory. This invokes an AWS Control Tower Lifecycle Event that deploys the existing stack of storage and compute resources to Team2 Acct. Project1 OU governance now extends to Team2. This ensures a consistent set of resources and policies across accounts.
New resources added to existing account
Team4 decides on a compute strategy and wants to use containers for its applications. It wants to launch Amazon Elastic Container Service (Amazon ECS) clusters in two different AWS Regions.
Figure 5. Update to landing zone – New resources added to Team4 Acct
The admin defines the resources in a CloudFormation template and updates the manifest to include template, target account Team4, and target Regions. Uploading the package to the configuration bucket triggers the CodePipeline workflow that deploys the container resources to Team4 Acct in specified Regions. If needed, the admin can add additional SCPs to Project2 OU to govern compute resources.
Best practices
- Start with an example manifest in the solution’s GitHub repo to get started quickly.
- To store your customizations, adopt a consistent file structure that includes the manifest, templates, policies, and parameters.
- When adding or modifying SCPs, carefully review existing policies to avoid conflict. Remember, SCPs work with your AWS IAM policies and an explicit deny overrides an explicit allow, per AWS IAM policy evaluation logic.
- Double check your manifest file to make sure it reflects the correct target account(s) and Region(s). This helps prevent unintended changes to your account resources.
Conclusion
In this blog, I highlighted a few use cases for the solution, Customizations for AWS Control Tower. You can use the solution to deploy your resources and governance at scale using the recommended best practices. The built-in DevOps workflows provide business agility and reliability. The result is a secure and scalable multi-account AWS environment that sets you up for growth and success in the cloud.