# Get started with AWS Control Tower from the console
This getting started procedure is intended for AWS Control Tower administrators. Follow this procedure when you're ready to set up your landing zone using the AWS Control Tower console. From start to finish, it should take about half an hour. This procedure requires some prerequisites and three main steps.
If you are an AWS customer currently, but new to AWS Control Tower, you may wish to review the section called [Plan your AWS Control Tower landing zone](planning-your-deployment.md), before you proceed.
**Topics**
+ [Expectations for landing zone configuration](getting-started-configure.md)
+ [Step 1: Create your shared account email addresses](step-one.md)
+ [Step 2. Configure and launch your landing zone](step-two.md)
+ [Step 3. Review and set up the landing zone](review-and-set-up.md)
# Expectations for landing zone configuration
The process of setting up your AWS Control Tower landing zone has multiple steps. Certain aspects of your AWS Control Tower landing zone are configurable. Other choices cannot be changed after setup.
**Key items to configure during setup**
+ You can select your top-level OU names during setup, and you also can change OU names after you've set up your landing zone. By default, the top-level OUs are named **Security** and **Sandbox**. For more information, see [Guidelines to set up a well-architected environment](aws-multi-account-landing-zone.md#guidelines-for-multi-account-setup).
+ During setup, you can select customized names for the shared accounts that AWS Control Tower creates, called **log archive** and **audit** by default, but you cannot change these names after setup. (This is a one-time selection.)
+ During setup, you can optionally specify existing AWS accounts for AWS Control Tower to use as audit and log archive accounts. If you plan to specify existing AWS accounts, and if those accounts have existing AWS Config resources, you must delete the existing AWS Config resources before you can enroll the accounts into AWS Control Tower. (This is a one-time selection.)
+ If you are setting up for the first time, or if you're upgrading to landing zone version 3.0, you can choose whether to allow AWS Control Tower to set up an organization-level AWS CloudTrail trail for your organization, or you can opt out of trails that are managed by AWS Control Tower and manage your own CloudTrail trails. You can opt into or opt out of organization-level trails that are managed by AWS Control Tower any time you update your landing zone.
+ You can optionally set a customized retention policy for your Amazon S3 log bucket and log access bucket, when you set up or update your landing zone.
+ You can optionally specify a previously-defined *blueprint* to use for provisioning customized member accounts from the AWS Control Tower console. You can customize accounts later if you do not have a blueprint available. See [Customize accounts with Account Factory Customization (AFC)](af-customization-page.md).
**Configuration choices that cannot be undone**
+ You cannot change your home Region after you've set up your landing zone.
+ If you're provisioning Account Factory accounts with VPCs, VPC CIDRs can't be changed after they are created.
# Step 1: Create your shared account email addresses
If you're setting up your landing zone in a new AWS account, see [Setting up](setting-up.md).
+ To set up your landing zone with *new* shared accounts, AWS Control Tower requires two unique email addresses that aren't already associated with an AWS account. Each of these email addresses will serve as a collaborative inbox -- a shared email account -- intended for the various users in your enterprise that will do specific work related to AWS Control Tower.
+ If you are setting up AWS Control Tower for the first time, and if you are bringing existing security and log archive accounts into AWS Control Tower, you can enter the current email addresses of the existing AWS accounts.
The email addresses are required for:
+ **Audit account** – This account is for your team of users that need access to the audit information made available by AWS Control Tower. You can also use this account as the access point for third-party tools that will perform programmatic auditing of your environment to help you audit for compliance purposes.
+ **Log archive account** – This account is for your team of users that need access to all the logging information for all of your enrolled accounts within registered OUs in your landing zone.
These accounts are set up in the **Security** OU when you create your landing zone. As a best practice, we recommend that when you perform actions in these accounts, you should use an IAM Identity Center user with the appropriately scoped permissions.
**Note**
If you specify existing AWS accounts as your **audit** and **log archive** accounts, the existing accounts must pass some pre-launch checks to ensure that no resources are in conflict with AWS Control Tower requirements. If these checks are not successful, your landing zone setup may not succeed. In particular, the accounts must not have existing AWS Config resources. For more information, see [Considerations for bringing existing security or logging accounts](accounts.md#considerations-for-existing-shared-accounts).
For the sake of clarity, this *User Guide* always refers to the shared accounts by their default names: **log archive** and **audit**. As you read this document, remember to substitute the customized names you give to these accounts initially, if you choose to customize them. You can view your accounts with their customized names on the **Account details** page.
**Note**
We are changing our terminology regarding the default names of some AWS Control Tower organizational units (OUs) to align with the AWS multi-account strategy. You may notice some inconsistencies while we are making a transition to improve the clarity of these names. The Security OU was formerly called the Core OU. The Sandbox OU was formerly called the Custom OU.
# Step 2. Configure and launch your landing zone
Before you launch your AWS Control Tower landing zone, determine the most appropriate home Region. For more information, see [Administrative tips for landing zone setup](tips-for-admin-setup.md).
**Important**
Changing your home Region after you have deployed your AWS Control Tower landing zone requires decommissioning as well as the assistance of AWS Support. This practice is not recommended.
Learn how to configure and launch your landing zone using the AWS CLI in [Get started with AWS Control Tower using APIs](getting-started-apis.md).
To configure and launch your landing zone in the console, perform the following series of steps.
**Prepare: Navigate to the AWS Control Tower console**
1. Open a web browser, and navigate to the AWS Control Tower console at [https://console.aws.amazon.com/controltower](https://console.aws.amazon.com/controltower).
1. In the console, verify that you are working in your desired home Region for AWS Control Tower. Then choose **Set up your landing zone**.
# Step 2a. Review and select your AWS Regions
Be sure you've correctly designated the AWS Region that you select for your home Region. After you've deployed AWS Control Tower, you can't change the home Region.
In this section of the setup process, you can add any additional AWS Regions that you require. You can add more Regions at a later time, if needed, and you can remove Regions from governance.
**To select additional AWS Regions to govern**
1. The panel shows you the current Region selections. Open the dropdown menu to see a list of additional Regions available for governance.
1. Check the box next to each Region to bring into governance by AWS Control Tower. Your home Region selection is not editable.
**To deny access to certain Regions**
To deny access to AWS resources and workloads in certain AWS Regions, select **Enabled** in the section for the Region deny control. By default, the setting for this control is **Not enabled**.
# Step 2b. Configure your organizational units (OUs)
If you accept the default names of these OUs, there's no action you need to take for setup to continue. To change the names of the OUs, enter the new names directly in the form field.
+ **Foundational OU** – AWS Control Tower relies upon a **Foundational OU** that is initially named the **Security OU**. You can change the name of this OU during initial setup and afterward, from the OU details page. This **Security OU** contains your two shared accounts, which by default are called the **log archive** account and the **audit** account.
+ **Additional OU** – AWS Control Tower can set up one or more **Additional OUs** for you. We recommend that you provision at least one **Additional OU** in your landing zone, besides the **Security OU**. If this Additional OU is intended for development projects, we recommend that you name it the **Sandbox OU**, as given in the [Guidelines to set up a well-architected environment](aws-multi-account-landing-zone.md#guidelines-for-multi-account-setup). If you already have an existing OU in AWS Organizations, you may see the option to skip setting up an Additional OU in AWS Control Tower.
# Step 2c. Configure your shared accounts, logging, and encryption
In this section of the setup process, the panel shows the default selections for the names of your shared AWS Control Tower accounts. These accounts are an essential part of your landing zone. **Do not move or delete these shared accounts**. You can choose customized names for the **audit** and **log archive** accounts during setup. Alternatively, you have a one-time option to specify existing AWS accounts as your shared accounts.
You must provide unique email addresses for your log archive and audit accounts, and you can verify the email address that you previously provided for your management account. Choose the **Edit** button to change the editable default values.
**About the shared accounts**
+ **The management account** – The AWS Control Tower management account is part of the Root level. The management account allows for AWS Control Tower billing. The account also has administrator permissions for your landing zone. You cannot create separate accounts for billing and for administrator permissions in AWS Control Tower.
The email address shown for the management account is not editable during this phase of setup. It is shown as a confirmation, so you can check that you're editing the correct management account, in case you have multiple accounts.
+ **The two shared accounts** – You can choose customized names for these two accounts, or bring your own accounts, and you must supply a unique email address for each account, either new or existing. If you choose to have AWS Control Tower create new shared accounts for you, the email addresses must not already have associated AWS accounts.
**To configure the shared accounts, fill in the requested information.**
1. At the console, enter a name for the account initially called the **log archive** account. Many customers decide to keep the default name for this account.
1. Provide a unique email address for this account.
1. Enter a name for the account initially called the **audit** account. Many customers choose to call it the **Security** account.
1. Provide a unique email address for this account.
# Optionally configure log retention
During this phase of setup, you can customize the log retention policy for Amazon S3 buckets that store your AWS CloudTrail logs in AWS Control Tower, in increments of days or years, up to a maximum of 15 years. If you choose not to customize your log retention, the default settings are one year for standard account logging and 10 years for access logging. This feature also is available when you update or reset your landing zone.
# Optionally self-manage AWS account access
You can select whether AWS Control Tower sets up AWS account access with AWS Identity and Access Management (IAM), or whether to self-manage AWS account access—either with AWS IAM Identity Center users, roles, and permissions that you can set up and customize on your own, or with another method *such as an external IdP, either for direct account federation or federation to multiple accounts by means of IAM Identity Center*. You can change this selection later.
By default, AWS Control Tower sets up AWS IAM Identity Center for your landing zone, in alignment with best-practices guidance defined in [Organizing your AWS environment using multiple accounts](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html). Most customers choose the default. Alternative access methods are required sometimes, for regulatory compliance in specific industries or countries, or in AWS Regions where AWS IAM Identity Center is not available.
Selection of identity providers at the account level is not supported. This option applies only for the landing zone as a whole.
For more information, see [IAM Identity Center guidance](sso-guidance.md).
# Optionally configure AWS CloudTrail trails
As a best practice, we recommend that you set up logging. If you wish to allow AWS Control Tower to set up an organization-level CloudTrail trail and manage it for you, choose **Opt in**. If you wish to manage logging with your own CloudTrail trails or a third-party logging tool, choose **Opt out**. Confirm your selection when requested to do so in the console. You can change your selection, and opt into, or opt out of, organization-level trails when you update your landing zone.
You can set up and manage your own CloudTrail trails at any time, including organization-level and account-level trails. If you set up duplicate CloudTrail trails, you may incur duplicate costs when CloudTrail events are logged.
# Optionally configure AWS KMS keys
If you wish to encrypt and decrypt your resources with an AWS KMS encryption key, select the checkbox. If you have existing keys, you'll be able to select them from identifiers displayed in a dropdown menu. You can generate a new key by choosing **Create a key**. You can add or change a KMS key any time you update your landing zone.
When you select **Set up landing zone**, AWS Control Tower performs a pre-check to validate your KMS key. The key must meet these requirements:
+ Enabled
+ Symmetric
+ Not a multi-Region key
+ Has correct permissions added to the policy
+ Key is in the management account
You may see an error banner if the key does not meet these requirements. In that case, choose another key or generate a key. Be sure to edit the key's permissions policy, as described in the next section.
## Update the KMS key policy
Before you can update a KMS key policy, you must create a KMS key. For more information, see [Creating a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html) in the *AWS Key Management Service Developer Guide*.
To use a KMS key with AWS Control Tower, you must update the default KMS key policy by adding the minimum required permissions for AWS Config and AWS CloudTrail. As a best practice, we recommend that you include the minimum required permissions in any policy. When updating a KMS key policy, you can add permissions as a group in a single JSON statement or line by line.
The procedure describes how to update the default KMS key policy in the AWS KMS console by adding policy statements that allow AWS Config and CloudTrail to use AWS KMS for encryption. The policy statements require that you include the following information:
+ **`YOUR-MANAGEMENT-ACCOUNT-ID`** – the ID of the management account in which AWS Control Tower will be set up.
+ **`YOUR-HOME-REGION`** – the home Region that you will select when setting up AWS Control Tower.
+ **`YOUR-KMS-KEY-ID`** – the KMS key ID that will be used with the policy.
**To update the KMS key policy**
1. Open the AWS KMS console at [https://console.aws.amazon.com//kms](https://console.aws.amazon.com//kms)
1. From the navigation pane, choose **Customer managed keys**.
1. In the table, select the key that you want to edit.
1. In the **Key policy** tab, make sure that you can view the key policy. If you can't view the key policy, choose **Switch to policy view**.
1. Choose **Edit**, and update the default KMS key policy by adding the following policy statements for AWS Config and CloudTrail.
**AWS Config policy statement**
```
{
"Sid": "Allow Config to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "config.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:key/YOUR-KMS-KEY-ID"
}
```
**CloudTrail policy statement**
```
{
"Sid": "Allow CloudTrail to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:key/YOUR-KMS-KEY-ID",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:cloudtrail:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:trail/aws-controltower-BaselineCloudTrail"
},
"StringLike": {
"kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:YOUR-MANAGEMENT-ACCOUNT-ID:trail/*"
}
}
}
```
1. Choose **Save changes**.
** Example KMS key policy **
The following example policy shows what your KMS key policy might look like after you add the policy statements that grant AWS Config and CloudTrail the minimum required permissions. The example policy doesn't include your default KMS key policy.
```
{
"Version": "2012-10-17",
"Id": "CustomKMSPolicy",
"Statement": [
{
... YOUR-EXISTING-POLICIES ...
},
{
"Sid": "Allow Config to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "config.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:PARTITION:kms:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:key/YOUR-KMS-KEY-ID"
},
{
"Sid": "Allow CloudTrail to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "arn:PARTITION:kms:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:key/YOUR-KMS-KEY-ID",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:PARTITION:cloudtrail:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:trail/aws-controltower-BaselineCloudTrail"
},
"StringLike": {
"kms:EncryptionContext:aws:cloudtrail:arn": "arn:PARTITION:cloudtrail:*:YOUR-MANAGEMENT-ACCOUNT-ID:trail/*"
}
}
}
]
}
```
To view other example policies, see the following pages:
+ [Granting encrypt permissions](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/create-kms-key-policy-for-cloudtrail.html#create-kms-key-policy-for-cloudtrail-encrypt) in the *AWS CloudTrail User Guide*.
+ [Required Permissions for the KMS Key When Using Service-Linked RolesS3 Bucket Delivery)](https://docs.aws.amazon.com//config/latest/developerguide/s3-kms-key-policy.html#required-permissions-s3-kms-key-using-servicelinkedrole) in the *AWS Config Developer Guide*.
**Protect against attackers**
By adding certain conditions to your policies, you can help prevent a specific type of attack, known as a *confused deputy* attack, which occurs if an entity coerces a more-privileged entity to perform an action, such as with cross-service impersonation. For general information about policy conditions, also see [Specifying conditions in a policy](access-control-overview.md#specifying-conditions).
The AWS Key Management Service (AWS KMS) allows you to create multi-Region KMS keys and asymmetric keys; however, AWS Control Tower does not support multi-Region keys or asymmetric keys. AWS Control Tower performs a pre-check of your existing keys. You may see an error message if you select a multi-Region key or an asymmetric key. In that case, generate another key for use with AWS Control Tower resources.
For more information about AWS KMS, see [ the AWS KMS Developer Guide.](https://docs.aws.amazon.com//kms/latest/developerguide/overview.html)
Note that customer data in AWS Control Tower is encrypted at rest, by default, using SSE-S3.
# Optionally configure auto-enrollment for accounts
When you enable this feature during setup, or later, accounts that are moved between two registered OUs, or moved into your AWS Control Tower environment for the first time, no longer show a state of inheritance drift. The accounts automatically inherit the baselines and controls that are enabled on the new OU. Controls and baselines from the previous OU are removed.
To opt in for auto-enrollment at any time after setup, navigate to the landing zone **Settings** page and choose **Update** landing zone, or call the AWS Control Tower `UpdateLandingZone` API.
You can move an account between OUs by means of the AWS Organizations API, or by means of the AWS Control Tower console. If you move an account outside an OU that's registered, AWS Control Tower removes all deployed baselines and controls, automatically. It essentially unenrolls the account from AWS Control Tower.
**Note**
If you choose to enable the auto-enroll capability after initial setup of the landing zone, AWS Control Tower does not retroactively resolve the inheritance drift that was caused by moving accounts between OUs before the auto-enroll capability was enabled. The automatic drift resolution goes into effect for accounts that are moved after you enable this setting.
# Optionally configure and create customized member accounts
When you follow the **Create account** workflow to add your member accounts, you can optionally specify a previously-defined *blueprint* to use for provisioning customized member accounts from the AWS Control Tower console. You can customize accounts later if you do not have a blueprint available. See [Customize accounts with Account Factory Customization (AFC)](af-customization-page.md).
# Step 3. Review and set up the landing zone
The next section in the setup shows you the permissions that AWS Control Tower requires for your landing zone. Choose a checkbox to expand each topic. You'll be asked to agree to these permissions, which may affect multiple accounts, and to agree to the overall **Terms of Service**.
**To finalize**
1. At the console, review the **Service permissions**, and when you're ready, choose **I understand the permissions AWS Control Tower will use to administer AWS resources and enforce rules on my behalf**.
1. To finalize your selections and initialize launch, choose **Set up landing zone**.
This series of steps starts the process of setting up your landing zone, which can take about thirty minutes to complete. During setup, AWS Control Tower creates your Root level, the Security OU, and the shared accounts. Other AWS resources are created, modified, or deleted.
**Confirm SNS subscriptions**
The email address you provided for the audit account will receive **AWS Notification – Subscription Confirmation** emails from every AWS Region supported by AWS Control Tower. To receive compliance emails in your audit account, you must choose the **Confirm subscription** link within each email from each AWS Region supported by AWS Control Tower.