Setting Up Landing Zone with AWS Control Tower

Many years ago, I was working in a company where everything had to be created from scratch. Defining the requirements, designing the Rack, configuring the firewall, routers, and storage to be able to save data, defining user management, how to create all the infrastructure, and the list went on and on. This was a definitive infrastructure that hosted all customers and then managed them. Today, the way of thinking and drawing the entire infrastructure has changed. It has become much simpler thanks to flexibility and automation tools, but many of the requirements are the same.

When we start thinking about AWS and what customers want to do on AWS, we need to first think about requirements to better understand what the customers need. For example, which is the right service to use? What about security, governance, and baseline? How many accounts should I create for my customer based on own use cases? How many users, groups, and what permissions should they have?

Let me introduce you to the concept of a Landing Zone and Control Tower, and why they work well together.

AWS Control Tower is an AWS Managed Service which controls the following AWS resources:

1. AWS Organizations

2. Identity and Access Management

3. Guardrails

4. Service Catalog

5. Multiple AWS accounts.

Through the Service Catalog, you can create as many AWS accounts as you want and apply configured rules based on your requirements. In addition, AWS Control Tower can setup a Landing zone in easy and secure way. Or you can create your own solution based on your requirement and your own CloudFormation or Terraform stacks across AWS accounts.

Landing Zone solution using Control Tower Service

Master Account

From the Master account, you can set up an AWS Control Tower that allows you to create:

• Two Organizations Units (OUs), Core Unit and Custom Unit, (AWS Login and Audit are linked with Core Unit and AWS Custom Account are linked with Custom Unit, you can create as you need them)
• Guardrails –Control Tower by default create the rules that are part of the baseline and applied in each AWS Account, you can extend them as well.
• AWS Service Catalog allows you to provision new AWS accounts and assign this account to your favorite Organization Unit.

Shared Accounts

Shared Accounts includes Logging Account and Audit Account. They are not provisioned by Service Catalog, but during Control Tower set up. They share resources among all Landing Zone provisioned accounts. It could be services or tools to your organization; for example, centralized directory, Active Directory for SSO integration, perhaps some infrastructure scanning, EBS volumes, golden AMI, or a simple DNS. Cross Account IAM Role is necessary to delegate access across AWS accounts.

Logging Account

Control Tower create this account by default, and the purpose of having this account is to collect all the logs from different account to this one. But what kind of logs do we need to collect? The logs could include infrastructure logs, application logs, VPC logs, Security logs, Database logs, etc.. This account become the single point of truth. It should be extremely limited access in that, if you do log into the account, you may want to consider alarming in that condition. It can also be Kinesis stream with Lambda function that collects the log in real-time. For more information, I explained a centralized logging solution in a previous article.

Audit Account

This account also is set up by Control Tower and the purpose of this is to establish security. In this account is established cross-account role, reports, real-time alerts. Make sure the users, groups, applications has the right permissions

Functional Account

How many accounts you should create here depends on your case, and how you want to build and implement your application. To have a significant software development project is the use of multiple environments, and each environment. Below, I’ve listed four AWS accounts (Dev, QA, Pre-Prod and Production) that you should have, at the very least, in your solution. You can scale easily by adding more AWS accounts using the service catalog in the master account.

• Dev: This environment allows developers to start deploying things, to experiment, to learn, to innovate, and to build things up. Here developers deploy their code and test any newly implemented features or bugs. Once the code is considered stable, they start builds and deploy them to other accounts.
• Pre-Prod: This is where Quality Assurance (QA) is performed. Testers access the staging environment and ensure that the application works as it should, in this environment they run different tests to detect bugs and ensure that application is ready to deploy in production.
• Prod: This is the most restrictive environment. It’s where the production applications are made available to end-users. We should have very limited access into the account. We should ensure the right connectivity is there, our logs are going to the logging account, and there may be stricter security rules and policies in place around them.
• DevOps: This account allows the DevOps team to successfully release applications across AWS accounts (in this case, dev, pre-prod, and prod). It doesn’t matter what your DevOps process looks like and what kind of tools you use, but it is important that these tools are isolated by other environments for security purposes. Services that are hosted here include continuous integration and continuous delivery.

Baseline Requirements:

To establish a set of requirements in each AWS account, the first step in establishing a Landing Zone that is set up around these account level requirements. We’ve got the concept of accounts, and each account is truly independent from any other account within. Therefore, the baseline requirements we want should include:

1. Enable our MFA in our root access. Make sure that’s locked away.
2. There are no credentials.
3. There’s no access keys for my root account.
4. Enable cloud trail which is the API log off activities within the account. It’s API is logged there.
5. Access across not just my region that I’m operating, but every other region within my environment. Think about my enterprise roles.

What is the best way of setting up a landing zone using Control Tower or set up your own Landing Zone?

In the image below, there are some pros and cons of using a control tower versus setting up your own landing zone.

Conclusions

The Landing Zone solution helps customers with large organizations to automate and easily add as many accounts as needed, as many organizations as needed, and guardrails. There are pros and cons using Control Tower to set up Landing Zone, so it’s up to you to determine how you are going to set up Landing Zone based on your case and requirements.

#AWS #CloudSecury #CloudServices