Building a Landing zone with AWS Control Tower (part 1)

Since 2021, I have built ~20 AWS Landing Zones for different customers, big and small, enterprises and startups, and in this series of articles, I will share my experience with you if you strive to improve security in your AWS Cloud Environment. Let’s start from the very beginning.

A landing zone is a well-architected, multi-account AWS environment that is scalable and secure. This is a starting point from which your organization can quickly launch and deploy workloads and applications with confidence in your security and infrastructure environment. Building a landing zone involves technical and business decisions to be made across account structure, networking, security, and access management in accordance with your organization’s growth and business goals for the future.

In this post, we will look at different options for organizing a multi-account AWS environment based on my experience with ~20 customers. Let’s start with history for a better understanding of why the landing zone appeared.

How it was

A team created an AWS account, logged in directly, and deployed some resources (EC2 instances, Databases, storage, etc.). As the company grew, new teams appeared. They also logged in directly to the AWS account and deployed their own resources.

The following question appears at this point:

• How to distinguish the workloads of different teams?
• How to manage permissions properly?
• How to deal with service limits (quotas)?

In February 2017, AWS released the Organizations, and since then different teams can have their own isolated AWS accounts, which will be under the control of the Management account. Management account provides the following:

• Consolidated billing and volume discounts
• Centralized access control and SSO
• Organizational policies
• A central place for configuring security services and monitoring security findings

AWS Organization is a baseline for a Landing Zone.

Who may need a Landing Zone and what for?

If your company answers “Yes” to any of the following questions:

Does your business require …

• Administrative isolation between workloads?
• Limited visibility and discoverability of workloads?
• Isolation to minimize the scope of impact?
• Strong isolation of recovery and/or auditing data?

Landing zone may help you with the following:

• Security controls — Different security policies for different workloads
• Isolation — The AWS account is a unit of security protection
• Data isolation — Limit access to highly private data
• Different teams with different responsibilities and resource needs
• Different business units with different purposes and processes
• Billing — separate charges (especially for traffic, as it can not be tagged)
• Limit allocation — Prevents one workload from affecting others (when service limit was reached)

AWS Control Tower

AWS Control Tower offers a straightforward way to set up and govern an AWS multi-account environment, following prescriptive best practices. AWS Control Tower orchestrates the capabilities of several other AWS services, including AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center, to build a landing zone in less than an hour. Resources are set up and managed on your behalf.

When you go to the Control Tower web console, you see only one button “Set up landing zone”.

Next, you need to set the following:

• Home Region (default Region where resources will be provisioned)
• Email for foundational Landing Zone accounts (Audit and Log Archive)
• Several optional settings (Log retention, encryption, additional regions)

Start provisioning and wait ~30 minutes. During this time SSO will be enabled via AWS IAM Identity Center with the default directory, a Security organizational unit will be created with two accounts (Log Archive and Audit) and CloudFormation StackSets will be used to deploy resources in all three foundational accounts:

• Management account will get an organizational CloudTrail
• The Audit will have AWS Config Aggregator (AWS Config will be enabled in all AWS accounts in the Landing Zone) + several IAM roles and an SNS topic for security notifications
• The Log Archive account will have an S3 bucket for storing logs from AWS Config and AWS Cloudtrail from all accounts + the bucket will be protected by the Service Control Policy (the bucket can not be removed and encryption settings can not be changed)

Later you will be able to customize and expand the baseline (set of resources) that will be automatically deployed to any AWS account within your Landing Zone.

Account structure

Let’s briefly look at which accounts may be in your Landing Zone and what are their purposes (in the next article we will check it in more detail):

• Management account is used for Consolidated billing and SSO, as was mentioned above; Control Tower Controls (a.k.a. Guardrails) — security rules, that can be centrally managed for the whole AWS organization; Account factory is needed for enrolling new accounts into Landing Zone
• Log Archive account contains S3 buckets for different kinds of logs
• Audit account is a central point for Security services. We can delegate administrator access for Security Hub, GuardDuty, Inspector, and other services from the Management account to the Audit account
• Infrastructure OU can have accounts for the central network, shared services, DevOps tools, Backups, etc.
• Workloads OUs are used for different environments of your product (Prod, Stage, Dev, etc.) or different applications
• Sandbox OU can be used to provide your employees with personal AWS accounts for tests and experiments. Such accounts can be additionally limited from Budget point of view, some actions can be restricted and they are disconnected from the main network for security reasons
• Suspended OU is a fully restricted via SCP (deny all). We can temporary move accounts here before account closure or for security reasons, for example more a Sandbox account here, if it exceeds a budget.

Here is an example, how the organizational structure may look like for real company:

Control Tower Controls (Guardrails)

A control is a high-level rule that provides ongoing governance for your overall AWS environment. It’s expressed in plain language. AWS Control Tower implements preventive, detective, and proactive controls that help you govern your resources and monitor compliance across groups of AWS accounts.

I wrote a post about Controls in details , so here I just briefly mention them. Controls are a big and important part of every Landing Zone.

In high-level, Detective controls just monitor and notify you about non-compliant resources, Preventive controls prohibit some actions in AWS account, Proactive controls make sense only if you use CloudFormation for the infrastructure deployment, they check your CloudFormation template before applying it and interrupt deployment if the template does not comply rules.

There are more than 500 controls available in Control Tower, but some of them may be absent in some AWS regions. Check availability in docs.

Conclusion

In this post, I explained what a Landing Zone is and what were the preconditions for a Landing Zone to appear. Why and when you should consider creating a Landing Zone. Explained a bit what is AWS Control Tower and how may a Landing Zone look like from the Organizational Units perspective. A little bit about Controls (a.k.a. Guardrails). Let’s stop here and continue in the next article, where I will show more about every account and organizational unit.