AWS Control Tower: Beginning of the Adventure
This is the start of a series of posts about setting up a Landing Zone using AWS Control Tower. In this post, I will try to show you how to setup a Landing Zone on an AWS account.
Update 2022–12–31
2nd part of the series is finally here: Adding a new AWS Account to a Landing Zone
What is a Landing Zone?
AWS makes it easy for new customers to quickly create an AWS account and launch their workloads immediately. However, as your workload grows, you might want to create separate accounts for production and development environments. This is where a Landing zone comes in. AWS defines a Landing Zone as the ff:
A landing zone is a well-architected, multi-account AWS environment that’s based on security and compliance best practices. It is the enterprise-wide container that holds all of your organizational units (OUs), accounts, users, and other resources that you want to be subject to compliance regulation. A landing zone can scale to fit the needs of an enterprise of any size.
In short, it creates a baseline for recommended security and configuration best practices for your AWS organization. When you create a new AWS account using the Landing Zone, SSO, logging, compliance and security is automatically configured for the new account. If you don’t use this, you’d have to configure and maintain each AWS account in the organization.
In the company I work for (Cascadeo) we help setup Landing Zones for organizations of various sizes. Currently, there are 2 ways to setup a Landing Zone. The 1st one is a custom solution provided by AWS. This solution deploys the landing zone via CloudFormation and build pipeline. Configuration is done via text files. You can extend and customize the Landing Zone, however you want, provided you understand and know what you are doing. This is the Landing Zone that we usually use in Cascadeo. As you might have guessed, you need in-depth AWS and technical knowledge to deploy and maintain this type of Landing Zone.
The other type of Landing Zone can be deployed using AWS Control Tower. Control Tower provides an easy way to setup and configure a Landing Zone. It provides a dashboard where you can see a compliance overview of the organization. You can also update and repair the Landing Zone, when there is a new version or when someone accidentally change any Landing Zone resources. All these built-in features means though you are going to sacrifice full customizability.
What will happen to my existing resources?
Control Tower will enable and configure new services, but not touch the existing resources in the current AWS account. The current AWS account will be the management account, but the Guardrails are not enabled on it. As long as you don’t use the services that Control Tower needs to configure, your existing workloads won’t be affected by the Landing Zone. This means that current IAM users can continue to login to the AWS account; and workloads should continue to run.
VPC
Control Tower will attempt to remove the default VPC in the home region. AWS frowns upon, for security reasons, the usage of the default VPC that is created by default. Migrate the running EC2 instances in the default VPC to a custom VPC.
SSO
There can only be 1 enabled SSO for the whole organization in all regions. Control Tower will setup the SSO with the native default directory. If SSO is already configured, Control Tower might change the identity source. It is a good idea to prepare and backup the groups and users if you are using the native SSO directory.
CloudTrail and CloudWatch
A trail for API activity will be added to send logs to the Log archive account. A CloudWatch Log group is also created for this trail.
IAM Roles
Additional roles for the ControlTower and SSO permission sets are created.
Before we Begin
Choose a region in the existing AWS account in which Control Tower is available. Choose the region in which most of your workloads will be located. This region will become your home region. The resources in the shared accounts (e.g. S3 log bucket) will also be located in the home region. The existing AWS account will become the management account.
Create or setup a group or shared email addresses for the log and audit accounts. These email addresses will be the root users for the log and audit accounts that Control Tower will create. You won’t almost never gonna login using those though. Login to the AWS accounts will be done via AWS SSO.
Start the Journey
Head over to AWS Control Tower and push the “Set up landing zone” button. The current region will be your home region, so if you want to choose another home region, select it in the upper right corner of the AWS Console.
You can also choose other regions that you want to be governed by Control Tower. It is important to note that you can add, but cannot remove regions in Control Tower.
Make sure to read the guidelines carefully. Essentially, it just says not to mess with the resources that were created by Control Tower. Anything you do outside of Control Tower, in terms of OUs and accounts, is invisible to it. So use Control Tower when you want to register OUs or enroll new accounts. Lastly when provisioning new accounts via the Account Factory, do not define TagOptions, enable notifications nor create a provisioned product plan.
Finally, push the “Set up landing zone” button again to kick things off. You will be redirected to the Control Tower dashboard where you can watch the progress bar. I recommend getting yourself something to eat or drink ☕️, because this will indeed take a while. AWS will say that it will take 60 minutes for this procedure to finish, but in my case it only took less than 30 minutes.
Unboxing the Landing Zone
Congratulations on your brand new Landing Zone! 🎉 🎉 🎉
Let’s see what is inside.
Dashboard
The dashboard shows an overview of compliance of all the OUs and accounts in the organization. It also suggests useful actions to take for your organization.
Organization Units
Control Tower created 2 OUs:
- Core
- Custom
The 1st thing I did is create the OUs for my workloads and rename the “Custom” OU to something more useful for me, e.g. “Infrastructure”.
To rename an OU, you have to do it outside of Control Tower. In the search bar on the top navigation bar, type AWS Organizations, then select it from the drop down menu. The Console will show you the organization structure in tree form. Select the OU you want to rename, in this case “Custom”. You can either click on the OU name or choose Rename from the actions button in the top right of the account tree.
Since we renamed the OU outside of Control Tower, we must repair the landing zone. In the left-hand side menu of the Control Tower service, click on “Landing zone Settings”. Then push the “Repair” button. Unfortunately, AWS will say that it will take another 60 minutes for the process to finish. I observed that the duration will depend on the number of OUs and accounts already in the Landing Zone.
Adding an OU is much simpler. In the Control Tower service of the AWS Console, click on the “Organization Units” on the left-hand side menu. Then click the Add an OU button. Enter the name for the OU. In my case, I want an OU that will hold AWS accounts for my experimental projects. I named my OU “Sandbox”.
Accounts
Our fresh Landing Zone has 3 AWS Accounts:
- Audit (new)
- Log archive (new)
- Management Account (existing AWS account)
The management account serves as the Root account. It holds billing information, SSO, Account Factory and other Control Tower resources.
The Log archive account holds for the aggregation of CloudTrail logs and resource configuration of all AWS accounts (including the Management Account) in the Landing Zone.
The Audit account contains programmatic R/W cross-account access roles for the security team. The account also contains the the Config aggregator for all the accounts in the organization. You can also subscribe to security and compliance notifications in the Audit account.
Guardrails
Guardrails are high level rules that are applied to all AWS accounts, except the Management account. Guardrails can be preventive, in which case it will prevent an action that will violate the rule from even occurring. Or it can be detective, a violation may occur but it will be logged and included in the audit notifications.
When the Landing Zone is created, only mandatory guardrails are enabled by default. These mandatory guardrails prevents users of non-management accounts from breaking the logging and config monitoring setup by the Landing Zone.
Account Factory
New accounts can be created, and existing accounts can be enrolled using the Account Factory. This is actually a Service Catalog portfolio that can gives users the ability to create new AWS accounts. The accounts that are created will be automatically configured with baseline resources and included in the Landing Zone. In order to use the Account Factory, users must have the AWSServiceCatalogEndUserFullAccess policy enabled. This brings us to the last major feature of the Landing Zone.
Single Sign-On
User authentication and authorization is handled by AWS SSO. When the Landing Zone is created, a native SSO directory is created with a single user. The initial SSO user has the email of the root user of the management account. SSO will send an email to the root user that contains a link to the SSO login page. This page is where all future users will access to login to all the accounts in the organization.
⚠️ The initial SSO user has Administrator access to all AWS accounts, including the management account. Treat it as you would normally do for any IAM user with Admin policy, and enable MFA immediately.
Summary
We were able to setup a Landing Zone, created some OUs and explored the major components. In the next posts, we are going to do more useful things like adding a new AWS account or onboarding a new user!