# Best practices for AWS Control Tower administrators This topic is intended primarily for management account administrators. Management account administrators are responsible for explaining some tasks that AWS Control Tower controls prevent their member account administrators from doing. This topic describes some best practices and procedures for transferring this knowledge, and it gives other tips for setting up and maintaining your AWS Control Tower environment efficiently. ## Explaining access to users The AWS Control Tower console is available only to users with the management account administrator permissions. Only these users can perform administrative work within your landing zone. In accordance with best practices, this means that the majority of your users and member account administrators will never see the AWS Control Tower console. As a member of the management account administrator group, it's your responsibility to explain the following information to the users and administrators of your member accounts, as appropriate. + Explain which AWS resources that users and administrators have access to within the landing zone. + List the preventive controls that apply to each organizational unit (OU) so that the other administrators can plan and execute their AWS workloads accordingly. ## Explaining resource access Some administrators and other users may need an explanation of the AWS resources to which they have access to within your landing zone. This access can include programmatic access and console-based access. Generally speaking, read access and write access for AWS resources is allowed. To perform work within AWS, your users require some level of access to the specific services they need to do their jobs. Some users, such as your AWS developers, may need to know about the resources to which they have access, so they can create engineering solutions. Other users, such as the end users of the applications that run on AWS services, do not need to know about AWS resources within your landing zone. AWS offers tools to identify the scope of a user's AWS resource access. After you identify the scope of a user's access, you can share that information with the user, in accordance with your organization's information management policies. For more information about these tools, see the links that follow. + **AWS access advisor** – The AWS Identity and Access Management (IAM) access advisor tool lets you determine the permissions that your developers have by analyzing the last timestamp when an IAM entity, such as a user, role, or group, called an AWS service. You can audit service access and remove unnecessary permissions, and you can automate the process if needed. For more information, see [our AWS Security blog post](https://aws.amazon.com/blogs/security/automate-analyzing-permissions-using-iam-access-advisor). + **IAM policy simulator** – With the IAM policy simulator, you can test and troubleshoot IAM-based and resource-based policies. For more information, see [Testing IAM Policies with the IAM Policy Simulator](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_testing-policies.html). + **AWS CloudTrail logs** – You can review AWS CloudTrail logs to see actions taken by a user, role, or AWS service. For more information about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Actions taken by AWS Control Tower landing zone administrators are viewable in the landing zone management account. Actions taken by member account administrators and users are viewable in the shared log archive account. You can view a summary table of AWS Control Tower events in the [Activities page.](https://console.aws.amazon.com/) ## Explaining preventive controls A preventive control ensures that your organization's accounts maintain compliance with your corporate policies. The status of a preventive control is either **enforced** or **not-enabled**. A preventive control prevents policy violations by using service control policies (SCPs), resource control policies (RCPs), or declarative policies. In comparison, a detective control informs you of various events or states that exist, by means of defined AWS Config rules. Some of your users, such as AWS developers, may need to know about the preventive controls that apply to any accounts and OUs they use, so they can create engineering solutions. The following procedure offers some guidance on how to provide this information for the right users, according to your organization's information management policies. **Note** This procedure assumes you've already created at least one child OU within your landing zone, as well as at least one AWS IAM Identity Center user. **Example: To show preventive controls for users with a need to know** 1. Sign in to the AWS Control Tower console at [https://console.aws.amazon.com/controltower/](https://console.aws.amazon.com/controltower/). 1. From the left navigation, choose **Organization**. 1. From the table, choose the **name** of one of the OUs for which your user needs information about the applicable controls. 1. Note the name of the OU and the controls that apply to this OU. 1. Repeat the previous two steps for each OU about which your user needs information. For detailed information about the controls and their functions, see [About controls in AWS Control Tower](https://docs.aws.amazon.com//controltower/latest/userguide/controls.html). # Plan your AWS Control Tower landing zone When you go through the setup process, AWS Control Tower launches a key resource associated with your account, called a *landing zone*, which serves as a home for your organizations and their accounts. **Note** You can have one landing zone per organization. For information about some best practices to follow when you plan and set up your landing zone, see [AWS multi-account strategy for your AWS Control Tower landing zone](aws-multi-account-landing-zone.md). **Ways to Set Up AWS Control Tower** You can set up an AWS Control Tower landing zone in an existing organization, or you can start by creating a new organization that contains your AWS Control Tower landing zone. + [Launch AWS Control Tower in an Existing Organization](#deploy-with-existing-orgs): This section is for customers who have existing AWS Organizations ready to bring into governance by AWS Control Tower. + [Launch AWS Control Tower in a New Organization](#fresh-deployment-no-existing-orgs): This section is for customers without existing AWS Organizations, OUs, and accounts. **Note** If you already have an AWS Organizations landing zone, you can extend AWS Control Tower governance from the existing landing zone to some or all of your existing OUs and accounts within an organization. See [Govern existing organizations and accounts](https://docs.aws.amazon.com//controltower/latest/userguide/importing-existing.html). ## Compare functionality Here's a brief comparison of the differences between adding AWS Control Tower to an existing organization or extending AWS Control Tower governance to OUs and accounts. Also, some special considerations apply if you are moving to AWS Control Tower from the AWS Landing Zone solution. **About Adding to an Existing Organization:** Adding AWS Control Tower to an existing organization is something you can accomplish within the AWS console. In this case, you’ve already got an organization that you’ve created in the AWS Organizations service, that organization is not currently registered with AWS Control Tower, and you want to *add a landing zone afterward*. When you *add* a landing zone to an existing organization, AWS Control Tower sets up a parallel structure, at the AWS Organizations level. It doesn’t change the OUs and accounts within your existing organization. **About Extending Governance:** Extending governance applies to specific OUs and accounts *within a single organization that's already registered* with AWS Control Tower, which means that a landing zone already exists for that organization. Extending governance means that AWS Control Tower controls are extended so that their constraints apply to the specific OUs and accounts within that registered organization. In this case, you're not launching a new landing zone, you're only expanding the current landing zone for your organization. **Important** Special consideration: If you currently are using the [AWS Landing Zone solution (ALZ)](https://aws.amazon.com//solutions/implementations/aws-landing-zone/) for AWS Organizations, check with your AWS solutions architect before you try to enable AWS Control Tower in your organization. AWS Control Tower cannot perform pre-checks that determine whether AWS Control Tower may interfere with your current landing zone deployment. For more information, see [Walkthrough: Move from ALZ to AWS Control Tower](alz-to-control-tower.md). Also, for information about moving accounts from one landing zone to another, see [If the account does not meet the prerequisites](fulfill-prerequisites.md) ## Launch AWS Control Tower in an Existing Organization By setting up an AWS Control Tower landing zone in an existing organization, you can start working immediately, in parallel with your existing AWS Organizations environment. Your other OUs created within AWS Organizations are unchanged, because they are not registered with AWS Control Tower. You can continue to use those OUs and accounts exactly as they are. AWS Control Tower consolidates by using the management account from your existing organization as its management account. No new management account is needed. You can launch your AWS Control Tower landing zone from your existing management account. **Note** To set up AWS Control Tower on an existing organization, your service limits must allow for the creation of at least two additional accounts. **Effects of adding AWS Control Tower to your existing organization** AWS Control Tower creates two accounts in your organization: an audit account and a logging account. These accounts keep a record of actions taken by your team, in their individual end-user accounts. The **Audit** and **Log archive** accounts appear in the **Security** OU within your AWS Control Tower landing zone. When you set up your landing zone, the accounts added by AWS Control Tower become part of your existing AWS Organizations, and as such they become part of the billing for your existing organization. ### Summary of capabilities Enabling AWS Control Tower on an existing AWS Organizations organization provides several major enhancements to the organization. + It allows for unified billing across your organization’s groups, because accounts added by AWS Control Tower will become part of your existing organization. + It gives you the ability to administer all accounts from one management account in your OU. + It simplifies how you apply and enforce controls that cover security and compliance for existing and new accounts. **Important** Launching your AWS Control Tower landing zone in an existing AWS Organizations organization does not enable you to extend AWS Control Tower governance from that organization to other OUs or accounts that are not registered with AWS Control Tower. To launch AWS Control Tower in your existing organization, follow the process outlined in [Getting started with AWS Control Tower](getting-started-with-control-tower.md). For more information about how AWS Control Tower interacts with existing AWS Organizations organizations, see [Govern organizations and accounts with AWS Control Tower](existing-orgs.md). ## Launch AWS Control Tower in a New Organization If you're new to AWS Control Tower and you haven't worked with AWS Organizations, the best place to begin is with our [Setting up](setting-up.md) document. AWS Control Tower sets up an organization for you automatically when you don't have one set up. # AWS multi-account strategy for your AWS Control Tower landing zone AWS Control Tower customers often seek guidance about how to set up their AWS environment and accounts for best results. AWS has created a unified set of recommendations, called the *multi-account strategy*, to help you make the best use of your AWS resources, including your AWS Control Tower landing zone. Essentially, AWS Control Tower acts as an orchestration layer that works with other AWS services, which assist you with implementing the AWS multi-account recommendations for AWS accounts and AWS Organizations. After your landing zone is set up, AWS Control Tower continues to assist you with maintaining your corporate policies and security practices across multiple accounts and workloads. Most landing zones develop over time. As the number of organizational units (OUs) and accounts in your AWS Control Tower landing zone increases, you can extend your AWS Control Tower deployment in ways that help organize your workloads effectively. This chapter provides prescriptive guidance on how to plan and set up your AWS Control Tower landing zone, in alignment with the AWS multi-account strategy, and extend it over time. For a general discussion about best practices for organizational units, see [Best Practices for Organizational Units with AWS Organizations](https://aws.amazon.com//blogs/mt/best-practices-for-organizational-units-with-aws-organizations/). ## AWS multi-account strategy: Best practices guidance AWS best practices for a well-architected environment recommend that you should separate your resources and workloads into multiple AWS accounts. You can think of AWS accounts as isolated resource containers: they offer workload categorization, as well as blast radius reduction when things go wrong. **Definition of an AWS account** *An AWS account acts as a resource container and resource isolation boundary.* **Note** An AWS account is not the same as a user account, which is set up through Federation or AWS Identity and Access Management (IAM). **More about AWS accounts** An AWS account provides the ability to isolate resources and to contain security threats for your AWS workloads. An account also provides a mechanism for billing and for governance of a workload environment. The AWS account is the primary implementation mechanism to provide a resource container for your workloads. If your environment is well-architected, you can manage multiple AWS accounts effectively, and thus, manage multiple workloads and environments. AWS Control Tower sets up a well-architected environment. It relies upon AWS accounts, along with AWS Organizations, which help govern changes to your environment that can extend across multiple accounts. **Definition of a well-architected environment** *AWS defines a well-architected environment as one that begins with a landing zone.* AWS Control Tower offers a landing zone that is set up automatically. It enforces controls to ensure compliance with your corporate guidelines, across multiple accounts in your environment. **Definition of a landing zone** *The landing zone is a cloud environment that offers a recommended starting point, including default accounts, account structure, network and security layouts, and so forth. From a landing zone, you can deploy workloads that utilize your solutions and applications.* ## Guidelines to set up a well-architected environment The three key components of a well-architected environment, explained in the following sections, are: + Multiple AWS accounts + Multiple organizational units (OUs) + A well-planned structure **Use multiple AWS accounts** One account isn’t enough to set up a well-architected environment. By using multiple accounts, you can best support your security goals and business processes. Here are some benefits of using a multi-account approach: + **Security controls** – Applications have different security profiles, so they require different control policies and mechanisms. For example, it’s far easier to talk to an auditor and point to a single account hosting the payment card industry (PCI) workload. + **Isolation** – An account is a unit of security protection. Potential risks and security threats can be contained within an account without affecting others. Therefore, security needs may require you to isolate accounts from one another. For example, you may have teams with different security profiles. + **Many teams** – Teams have different responsibilities and resource needs. By setting up multiple accounts, the teams cannot interfere with one another, as they might when using the same account. + **Data Isolation** – Isolating data stores to an account helps limit the number of people who have access to data and can manage the data store. This isolation helps prevent unauthorized exposure of highly private data. For example, data isolation helps support compliance with the General Data Protection Regulation (GDPR). + **Business process** – Business units or products often have completely different purposes and processes. Individual accounts can be established to serve business-specific needs. + **Billing** – An account is the only way to separate items at a billing level, including things like transfer charges and so forth. The multi-account strategy helps create separate billable items across business units, functional teams, or individual users. + **Quota allocation** – AWS quotas are set up on a per-account basis. Separating workloads into different accounts gives each account (such as a project) a well-defined, individual quota. **Use multiple organizational units** AWS Control Tower and other account orchestration frameworks can make changes that cross account boundaries. Therefore, the AWS best practices address cross-account changes, which potentially can break an environment or undermine its security. In some cases, changes can affect the overall environment, beyond policies. As a result, we recommend that you should set up at least two mandatory accounts, Production and Staging. Furthermore, AWS accounts often are grouped into organizational units (OUs), for purposes of governance and control. OUs are designed to handle enforcement of policies across multiple accounts. Our recommendation is that, at a minimum, you create a pre-production (or Staging) environment that is distinct from your Production environment—with distinct controls and policies. The Production and Staging environments can be created and governed as separate OUs, and billed as separate accounts. In addition, you may want to set up a Sandbox OU for code testing. **Use a well-planned structure for OUs in your landing zone** AWS Control Tower sets up some OUs for you automatically. As your workloads and requirements expand over time, you can extend the original landing zone configuration to suit your needs. **Note** The names given in the examples follow the suggested AWS naming conventions for setting up a multi-account AWS environment. You can rename your OUs after you've set up your landing zone, by selecting **Edit** on the OU detail page. **Recommendations** After AWS Control Tower sets up the first, required OU for you — the Security OU — we recommend creating some additional OUs in your landing zone. We recommend that you allow AWS Control Tower to create at least one additional OU, called the Sandbox OU. This OU is for your software development environments. AWS Control Tower can set up the Sandbox OU for you during landing zone creation, if you select it. Two recommended other OUs you can set up on your own: the Infrastructure OU, to contain your shared services and networking accounts, and an OU to contain your production workloads, called the Workloads OU. You can add additional OUs in your landing zone through the AWS Control Tower console on the **Organizational units** page. **Recommended OUs besides the ones set up automatically** + **Infrastructure OU** – Contains your shared services and networking accounts. **Note** AWS Control Tower does not set up the Infrastructure OU for you. + **Sandbox OU** – A software development OU. For example, it may have a fixed spending limit, or it may not be connected to the production network. **Note** AWS Control Tower recommends that you set up the Sandbox OU, but it is optional. It can be set up automatically as part of configuring your landing zone. + **Workloads OU** – Contains accounts that run your workloads. **Note** AWS Control Tower does not set up the Workloads OU for you. For more information see [Production starter organization with AWS Control Tower](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/production-starter-organization.html#production-starter-organization-with-aws-control-tower). ## Example of AWS Control Tower with a complete multi-account OU structure AWS Control Tower supports a nested OU hierarchy, which means that you can create a hierarchical OU structure that meets your organization's requirements. You can build an AWS Control Tower environment to match the AWS multi-account strategy guidance. You also can build a simpler, flat OU structure that performs well and aligns with the AWS multi-account guidance. Just because you can build a hierarchical OU structure, it does not mean that you must do so. + To view a diagram that shows an example set of OUs in an expanded, flat AWS Control Tower environment with AWS multi-account guidance, see [ Example: Workloads in a Flat OU Structure](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/appendix-e-establish-multi-account.html#example-workloads-flat-structure). + For more information about how AWS Control Tower works with nested OU structures, see [Nested OUs in AWS Control Tower](nested-ous.md). + For more information about how AWS Control Tower aligns with the AWS guidance, see the AWS white paper, [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/appendix-e-establish-multi-account.html). The diagram on the linked page shows that more Foundational OUs and more Additional OUs have been created. These OUs serve the additional needs of a larger deployment. In the Foundational OUs column, two OUs have been added to the basic structure: + **Security\$1Prod OU** – Provides a read-only area for security policies, as well as a break-glass security audit area. + **Infrastructure OU** – You may wish to separate the Infrastructure OU, recommended previously, into two OUs, Infrastructure\$1Test (for pre-production infrastructure) and Infrastructure\$1Prod (for production infrastructure). In the Additional OUs area, several more OUs have been added to the basic structure. These following are the next recommended OUs to create as your environment grows: + **Workloads OU** – The Workloads OU, recommended previously but optional, has been separated into two OUs, Workloads\$1Test (for pre-production workloads) and Workloads\$1Prod (for production workloads). + **PolicyStaging OU** – Allows system administrators to test their changes to controls and policies before fully applying them. + **Suspended OU** – Offers a location for accounts that may have been disabled temporarily. ## About the Root The Root is not an OU. It is a container for the management account, and for all OUs and accounts in your organization. Conceptually, the Root contains all of the OUs. It cannot be deleted. You cannot govern enrolled accounts at the Root level within AWS Control Tower. Instead, govern enrolled accounts within your OUs. For a helpful diagram, see [the AWS Organizations documentation](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_getting-started_concepts.html). # Administrative tips for landing zone setup Here are some tips for setting up and configuring your landing zone. + The AWS Region where you do the most work should be your home Region. + Set up your landing zone and deploy your Account Factory accounts from within your home Region. + If you’re investing in several AWS Regions, be sure that your cloud resources are in the Region where you’ll do most of your cloud administrative work and run your workloads. + By keeping your workloads and logs in the same AWS Region, you reduce the cost that would be associated with moving and retrieving log information across regions. + The audit and other Amazon S3 buckets are created in the same AWS Region from which you launch AWS Control Tower. We recommend that you do not move these buckets. + You can make your own log buckets in the Log Archive account, but it is not recommended. Be sure to leave the buckets created by AWS Control Tower. + Your Amazon S3 access logs must be in the same AWS Region as the source buckets. + When launching, AWS Security Token Service (STS) endpoints must be activated in the management account, for all Regions supported by AWS Control Tower. Otherwise, the launch may fail midway through the configuration process. + *AWS Control Tower supports tagging for enabled controls only.* For more information, see [AWS Control Tower control tagging APIs](2023-all.md#control-tagging-apis). + We recommend enabling multi-factor authentication (MFA) for every account that AWS Control Tower manages. + Alternatively, you can use the AWS Root Access Management feature, which allows root actions to be performed on member accounts, and removes the need to enable MFA for every account. For more information, see [Centrally managing root access for customers using AWS Organizations](https://aws.amazon.com/blogs/aws/centrally-managing-root-access-for-customers-using-aws-organizations/). **Considerations about VPCs** + The VPC created by AWS Control Tower is limited to the AWS Regions in which AWS Control Tower is available. Some customers whose workloads run in non-supported Regions may want to disable the VPC that is created with your Account Factory account. They may prefer to create a new VPC using the Service Catalog portfolio, or to create a custom VPC that runs only in the required Regions. + The VPC created by AWS Control Tower is not the same as the default VPC that is created for all AWS accounts. In Regions where AWS Control Tower is supported, AWS Control Tower deletes the default VPC when it creates the AWS Control Tower VPC. + If you delete your default VPC in your home AWS Region, it's best to delete it in all other AWS Regions. # Landing Zone v4.0 migration guide AWS Control Tower Landing Zone 4.0 introduces a major overhaul of the landing zone architecture, offering a flexible dedicated controls experience and fully optional service integrations. Key enhancements include the ability to selectively enable AWS Config, AWS CloudTrail, SecurityRoles, and AWS Backup integrations, with dedicated resources for AWS Config and AWS CloudTrail for improved isolation. The release removes mandatory organizational structure requirements, allowing customers to define their own, while introducing a new `ConfigBaseline` for detective controls support without the requiring the comprehensive `AWSControlTowerBaseline`. A service-linked Config Aggregator replaces previous aggregation methods, streamlining compliance data collection. Additionally, the manifest field becomes optional, enabling minimalist landing zone deployments focused solely on AWS Organizations integration and control enablement. These changes provide greater customization options while maintaining robust governance capabilities, allowing customers to tailor AWS Control Tower to their specific needs more effectively. **Topics** + [Key changes](key-changes-lz-v4.md) + [AWS Config Updates](config-updates-v4.md) + [Feature comparison with and without AWS Config integration](config-integration-feature-comparison.md) # Key changes **Note** The definition of “registered” and “enrolled” have shifted with this new version of AWS Control Tower. When your account/OU has any AWS Control Tower resource enabled on it (e.g. control or baseline), it will be considered a governed resource. The definition will no longer be driven by the presence of the `AWSControlTowerBaseline` baseline. Service-Linked Roles are retained across all landing zone versions and are no longer deleted when OUs become "unregistered" Service-Linked Roles can only be deleted manually by customers after landing zone decommissioning **Upgrading from version 3.3 or earlier to version 4.0** Do not disable service integrations (AWS Config, SecurityRoles) as part of the version upgrade. In landing zone versions 3.3 and earlier, AWS Config and SecurityRoles were always enabled implicitly. Version 4.0 surfaces these integrations as configurable options for the first time. After successfully upgrading to version 4.0, you can disable service integrations as desired. + **Pre-requisite for Landing Zone 4.0: **When upgrading to version 4.0 via API, ensure the `AWSControlTowerCloudTrailRole` service role uses the new managed policy `AWSControlTowerCloudTrailRolePolicy` instead of the existing inline policy. Detach the current inline policy and attach the new managed policy as described in the [documentation](https://docs.aws.amazon.com//controltower/latest/userguide/access-control-managing-permissions.html#AWSControlTowerCloudTrailRolePolicy). + **Optional Manifest:** Manifest field in the landing zone API is now optional. Customers can create Landing Zones without any service integrations. There is no impact for existing customers that are already using the manifest field. + **Optional Organization Structure:** AWS Control Tower no longer enforces or manages the Security OU creation so customers can define and manage their own organization structure. However, AWS Control Tower will require all accounts that are configured for each AWS service integration to be under the same parent OU. There is no impact for customers that have already set-up the AWS Control Tower and have the Security OU. AWS Control Tower automatically deploys the resources and controls necessary to manage service integration accounts in the Security OU. For example, when AWS Config integration is enabled, AWS Config recording is enabled in all service integration accounts. The AWS Control Tower Baseline and the AWS Config Baseline are not applicable to the Security OU and integration accounts. To change service integrations, update landing zone settings. **Note** The organization structure setup for AWS Control Tower landing zone 4.0 has changed from previous landing zone versions. AWS Control Tower will no longer create the designated Security OU. The OU with the service integration accounts will be the designated Security OU. If member accounts move into the OU where the accounts for each integration reside, enabled controls on that OU are drifted regardless of whether auto-enrollment is turned on or off. **Baseline status for the Security OU:** The AWS Control Tower Baseline and the AWS Config Baseline cannot be applied to the Security OU. The Security OU displays a baseline status of "Not Applicable" for these baselines. This status is expected. The BackupBaseline can be applied to the Security OU. AWS Control Tower manages service integration accounts through the landing zone, not through OU-level baselines. If a service integration account displays a baseline status of "Not Enabled" and the associated service integration is disabled, AWS Control Tower no longer manages that account. Accounts in the Security OU that are not designated as service integration accounts do not receive baseline resources. To govern these accounts, move them to a managed OU and extend governance. **IAM Identity Center permission sets for service integration accounts:** AWS Control Tower provisions IAM Identity Center permission sets for the Logging account and the SecurityRoles account. AWS Control Tower does not provision permission sets for the Config account or the Backup account. To access the Config or Backup account through IAM Identity Center, create permission sets manually using the IAM Identity Center resources that AWS Control Tower deployed. + **Drift Notifications:** AWS Control Tower will stop sending drift notifications to SNS topic for all customers on landing zone 4.0 without the `AWSControlTowerBaseline` enabled, and will start sending drift notifications to EventBridge in the management account instead. To review sample events and guidance on how to receive drift notifications through EventBridge, please check [this guide](https://docs.aws.amazon.com/controltower/latest/userguide/governance-drift.html). + **Optional Service Integrations: **You now have the ability to enable/disable all AWS Control Tower integrations including AWS Config, AWS CloudTrail, SecurityRoles, and AWS Backup. These integrations also now have optionally required `enabled` flags in the API. The baselines that may apply to your landing zone or shared accounts now have dependencies on one another. The Integrations specific dependencies are: + Enablement: + `CentralSecurityRolesBaseline` → requires `CentralConfigBaseline` to be enabled + `IdentityCenterBaseline` → requires `CentralSecurityRolesBaseline` to be enabled + `BackupCentralVaultBaseline` → requires `CentralSecurityRolesBaseline` to be enabled + `BackupAdminBaseline` → requires `CentralSecurityRolesBaseline` to be enabled + `LogArchiveBaseline` → independent (no dependencies) + `CentralConfigBaseline` → independent (no dependencies) + Disablement: + `CentralConfigBaseline` can only be disabled if `CentralSecurityRolesBaseline`, `IdentityCenterBaseline`, `BackupAdminBaseline` and `BackupCentralVaultBaseline` baselines are disabled first. + `CentralSecurityRolesBaseline` can only be disabled if `IdentityCenterBaseline`, `BackupAdminBaseline` and `BackupCentralVaultBaseline` baselines are disabled first. + `IdentityCenterBaseline` can be disabled independently. + `BackupAdminBaseline` and `BackupCentralVaultBaseline` baselines can be disabled independently + `LogArchiveBaseline` can be disabled independently **Scope of AWS Config service integration enablement** Enabling the AWS Config service integration at the landing zone level deploys Config recording resources to service integration accounts only. To deploy AWS Config resources (Config Recorder, Delivery Channel) to member accounts, enable the AWS Config baseline on each managed OU individually. Enabling the Config integration at the landing zone level is a prerequisite for enabling the Config baseline on OUs. The landing zone-level setting alone does not deploy Config resources to member accounts. **CentralizedLogging behavior change in version 4.0** In landing zone versions 3.3 and earlier, disabling CentralizedLogging toggled the Organization CloudTrail to off and retained all deployed resources. In version 4.0, disabling CentralizedLogging deletes all associated resources from the logging account. These resources include the Config Recorder, Delivery Channel, and CloudTrail-related stack instances. After disablement, AWS Control Tower no longer manages the logging account. To restore management of the logging account, re-enable CentralizedLogging or move the account to a managed OU and extend governance. # AWS Config Updates + **Dedicated resources for AWS Config and AWS CloudTrail: ** AWS Config and AWS CloudTrail now use separate dedicated S3 buckets and SNS topics instead of shared resources. Customers have restricted flexibility to use a single or separate accounts for multiple integrations. + When upgrading to AWS Control Tower landing zone version 4.0, existing data and S3 buckets are not moved. AWS CloudTrail integration continues to use the existing S3 bucket with prefix `aws-controltower-logs`. The new AWS Config data post the update operation will be stored in a new S3 bucket with prefix `aws-controltower-config` that AWS Control Tower creates in the account designated for the CentralConfigBaseline. **Note** Enabling AWS CloudTrail integration on landing zone 4.0 for the first time will create new S3 buckets each time with prefix `aws-controltower-cloudtrail` + Data Location Changes: Existing customers upgrading from previously shared to dedicated resources will have AWS Config and AWS CloudTrail data in different S3 buckets. Established customer workflows and tools may need updates to access data from new bucket locations. + AWS CloudTrail will continue to stay in the same existing bucket, but AWS Config data will be in a new S3 bucket created by AWS Control Tower. + Customers can set-up cross-bucket replication if they wish to centralize different logs to a single bucket. Please see [ S3 documentation ](https://docs.aws.amazon.com//AmazonS3/latest/userguide/replication.html) for more information. + If you have enrolled accounts with pre-existing AWS Config Delivery Channels not created by AWS Control Tower in Regions governed by AWS Control Tower, update the Delivery Channels' S3 bucket name to the new S3 bucket with prefix `aws-controltower-config-logs-` in the AWS Config integration account to be consistent with AWS Control Tower configurations on landing zone 4.0. See more details in [Enroll accounts that have existing AWS Config resources](existing-config-resources.md). + **AWS Config integration on landing zone version 4.0: ** When migrating to landing zone 4.0 with AWS Config integration enabled, customers would see the following changes - 1. The existing Audit account is registered as a delegated admin for AWS Config. 1. Service-Linked Config Aggregator is deployed into the Audit account (AWS Config central aggregator account for new customers and Audit account for existing customers). The new aggregator can aggregate data from any AWS Config Recorder in the organization, including non-Control Tower managed accounts. 1. Existing aggregators will be deleted - Organization aggregator in management account (`aws-controltower-ConfigAggregatorForOrganizations`) and account aggregator in Audit account (`aws-controltower-GuardRailsComplianceAggregator`) will be deleted. 1. Since Configuration Aggregator is service-linked, controls associated with deleted aggregators will be automatically removed. 1. [Disallow Changes to Tags Created by AWS Control Tower for AWS Config Resources](https://docs.aws.amazon.com//controltower/latest/controlreference/mandatory-controls.html#cloudwatch-disallow-config-changes) 1. [Disallow Deletion of AWS Config Aggregation Authorizations Created by AWS Control Tower](https://docs.aws.amazon.com//controltower/latest/controlreference/mandatory-controls.html#config-aggregation-authorization-policy) + **New `ConfigBaseline` baseline: ** There is now a separate `ConfigBaseline` at the OU level for detective controls support without requiring the comprehensive `AWSControlTowerBaseline`. See list of [ baseline types at the OU level](https://docs.aws.amazon.com//controltower/latest/userguide/types-of-baselines.html#ou-baseline-types) for more information. For existing customers that are using the default landing zone, all service integrations are now optional, with the caveat of dependency requirements outlined in [Key changes](key-changes-lz-v4.md). + **Service-Linked Config Aggregator: **Replaces organization and account aggregators in the AWS Config central aggregator account. + When upgrading to landing zone 4.0 with AWS Config integration enabled, customers need to have `organizations:ListDelegatedAdministrators` permissions ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "backup:UpdateGlobalSettings", "controltower:CreateLandingZone", "controltower:UpdateLandingZone", "controltower:ResetLandingZone", "controltower:DeleteLandingZone", "controltower:GetLandingZoneOperation", "controltower:GetLandingZone", "controltower:ListLandingZones", "controltower:ListLandingZoneOperations", "controltower:ListTagsForResource", "controltower:TagResource", "controltower:UntagResource", "servicecatalog:*", "organizations:*", "organizations:RegisterDelegatedAdministrator", "organizations:EnableAWSServiceAccess", "organizations:DeregisterDelegatedAdministrator", "organizations:ListDelegatedAdministrators", "sso:*", "sso-directory:*", "logs:*", "cloudformation:*", "kms:*", "iam:GetRole", "iam:CreateRole", "iam:GetSAMLProvider", "iam:CreateSAMLProvider", "iam:CreateServiceLinkedRole", "iam:ListRolePolicies", "iam:PutRolePolicy", "iam:ListAttachedRolePolicies", "iam:AttachRolePolicy", "iam:DeleteRole", "iam:DeleteRolePolicy", "iam:DetachRolePolicy" ], "Resource": "*" } ] } ``` # Feature comparison with and without AWS Config integration With Landing Zone 4.0, you can disable the AWS Config integration. The following table summarizes the AWS Control Tower features that are available with and without the AWS Config integration enabled on the landing zone. | Features | AWS Config Integration Enabled | AWS Config Integration Disabled | | --- | --- | --- | | [Preventive controls](https://docs.aws.amazon.com//controltower/latest/controlreference/preventive-controls.html) | ✓ | ✓ | | [Proactive controls](https://docs.aws.amazon.com//controltower/latest/controlreference/proactive-controls.html) | ✓ | ✓ | | [Region Deny control applied to OUs](https://docs.aws.amazon.com//controltower/latest/controlreference/ou-region-deny.html) | ✓ | ✓ | | [Region Deny control applied to landing zone](https://docs.aws.amazon.com//controltower/latest/userguide/region-deny.html) | ✓ | | | [Detective controls](https://docs.aws.amazon.com//controltower/latest/controlreference/detective-controls.html) | ✓ | | | [Account Factory](https://docs.aws.amazon.com//controltower/latest/userguide/account-factory.html) | ✓ | See alternative | | [Account Factory for Terraform (AFT)](https://docs.aws.amazon.com//controltower/latest/userguide/aft-overview.html) | ✓ | | | [Account Factory Customizations (AFC)](https://docs.aws.amazon.com//controltower/latest/userguide/af-customization-page.html) | ✓ | | | [AWS Service Catalog integration](https://docs.aws.amazon.com//controltower/latest/userguide/service-catalog.html) with [Account Factory](https://docs.aws.amazon.com//controltower/latest/userguide/account-factory.html) | ✓ | | | [Customizations for AWS Control Tower (CfCT)](https://docs.aws.amazon.com//controltower/latest/userguide/cfct-customizations-dev-guide.html) | ✓ | | | [Baselines applied to OUs](https://docs.aws.amazon.com//controltower/latest/userguide/types-of-baselines.html#ou-baseline-types) | ✓ | | | [AWS CloudTrail integration and baselines](https://docs.aws.amazon.com//controltower/latest/userguide/cloudtrail.html) | ✓ | ✓ | | [AWS Backup integration and baselines](https://docs.aws.amazon.com//controltower/latest/userguide/with-backup.html) | ✓ | | | [AWS IAM Identity Center integration and baselines](https://docs.aws.amazon.com//controltower/latest/userguide/sso.html) | ✓ | | | [AWS SNS integration for drift notifications](https://docs.aws.amazon.com//controltower/latest/userguide/sns.html) | ✓ | | | [Amazon EventBridge integration for drift notifications](https://docs.aws.amazon.com//controltower/latest/userguide/governance-drift.html#eventbridge-creation) | ✓ | ✓ | | [Register OU](https://docs.aws.amazon.com//controltower/latest/userguide/importing-existing.html) | ✓ | See alternative | **Alternatives** **Account Factory** If you have the AWS Config integration disabled, you can enable [auto-enrollment](https://docs.aws.amazon.com//controltower/latest/userguide/account-auto-enrollment.html) and use AWS Organizations to create and move accounts. The accounts will inherit the controls applied to the parent OU. **Register OU** If you have the AWS Config integration disabled, you can use AWS Organizations to create OUs. Then, enable controls through the Control Catalog page in the AWS Control Tower console, reset controls on the Organization page, or use AWS Control Tower APIs. # Recommendations for setting up groups, roles, and policies As you set up your landing zone, it's a good idea to decide ahead of time which users will require access to certain accounts and why. For example, a security account should be accessible only to the security team, the management account should be accessible only to the cloud administrators' team, and so forth. For more information about this topic, see [Identity and access management in AWS Control Tower](auth-access.md). **Recommended restrictions** You can restrict the scope of administrative access to your organizations by setting up an IAM role or policy that allows administrators to manage AWS Control Tower actions only. The recommended approach is to use the IAM policy `arn:aws:iam::aws:policy/service-role/AWSControlTowerServiceRolePolicy`. With the `AWSControlTowerServiceRolePolicy` role enabled, an administrator can manage AWS Control Tower only. Be sure to include appropriate access to AWS Organizations for managing your preventive controls, and SCPs, and access to AWS Config, for managing detective controls, in each account. When you're setting up the shared audit account in your landing zone, we recommend that you assign the `AWSSecurityAuditors` group to any third-party auditors of your accounts. This group gives its members read-only permission. An account must not have write permissions on the environment that it is auditing, because it can violate compliance with Separation of Duty requirements for auditors. You can impose conditions in your role trust policies, to restrict the accounts and resources that interact with certain roles in AWS Control Tower. We strongly recommend that you restrict access to the `AWSControlTowerAdmin` role, because it allows wide access permissions. for more information, see [Optional conditions for your role trust relationships](https://docs.aws.amazon.com//controltower/latest/userguide/conditions-for-role-trust.html). # Guidance for creating and modifying AWS Control Tower resources We recommend the following best practices as you create and modify resources in AWS Control Tower. This guidance might change as the service is updated. Remember that the [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to your AWS Control Tower environment. **General Guidance** + Do not modify or delete any resources created by AWS Control Tower, including resources in the management account, in the shared accounts, and in member accounts. If you modify these resources, you may be required to update your landing zone or re-register an OU, and modification can result in inaccurate compliance reporting. **In particular:** + Keep an active AWS Config recorder. If you delete your Config recorder, detective controls cannot detect and report drift. Non-compliant resources may be reported as** Compliant** due to insufficient information. + Do not modify or delete the AWS Identity and Access Management (IAM) roles created within the shared accounts in the Security organizational unit (OU). Modification of these roles can require an update to your landing zone. + Do not delete the `AWSControlTowerExecution` role from your member accounts, even in unenrolled accounts. If you do, you will not be able to enroll these accounts with AWS Control Tower, or register their immediate parent OUs. + Do not disallow usage of any AWS Regions through either SCPs or AWS Security Token Service (AWS STS). Doing so will cause AWS Control Tower to enter an undefined state. If you disallow Regions with AWS STS, your functionality will fail in those Regions, because authentication would be unavailable in those Regions. Instead, rely on the AWS Control Tower Region deny capability, as shown in the control, [Deny access to AWS based on the requested AWS Region](https://docs.aws.amazon.com//controltower/latest/userguide/primary-region-deny-policy.html), which works at the landing zone level, or the control [Region deny control applied to the OU](https://docs.aws.amazon.com//controltower/latest/userguide/ou-region-deny.html), which works at the OU level to restrict access to Regions. + The AWS Organizations `FullAWSAccess` SCP must be applied and should not be merged with other SCPs. Change to this SCP is not reported as drift; however, some changes may affect AWS Control Tower functionality in unpredictable ways, if access to certain resources is denied. For example, if the SCP is detached, or modified, an account may lose access to an AWS Config recorder or create a gap in CloudTrail logging. + Do not use the AWS Organizations `DisableAWSServiceAccess` API to turn off AWS Control Tower service access to the organization where you’ve set up your landing zone. If you do so, certain AWS Control Tower drift detection features may not function properly without messaging support from AWS Organizations. These drift detection features help guarantee that AWS Control Tower can report the compliance status of of organizational units, accounts, and controls in your organization accurately. For more information, see [API\$1DisableAWSServiceAccess in the AWS Organizations API Reference](https://docs.aws.amazon.com//organizations/latest/APIReference/API_DisableAWSServiceAccess.html). + In general, AWS Control Tower performs a single action at a time, which must be completed before another action can begin. For example, if you attempt to provision an account while the process of enabling a control is already in operation, account provisioning will fail. **Exception:** + AWS Control Tower allows concurrent actions to deploy optional controls. For more information, see [Concurrent deployment for optional controls](https://docs.aws.amazon.com//controltower/latest/userguide/enable-controls-on-ou.html#concurrent-optional-controls). + AWS Control Tower allows up to ten concurrent create, update, or enroll actions on accounts, with Account Factory. **Note** For more information about the resources created by AWS Control Tower, see [What are the shared accounts?](what-shared.md). **Tips about accounts and OUs** + We recommend that you keep each registered OU to a maximum of 1000 accounts, so that you can update those accounts with the **Re-register OU** capability whenever account updates are required, such as when you configure new Regions for governance. + To reduce the time required when registering an OU, we recommend that you keep the number of accounts per OU to around 680, even though the limit is 1000 accounts per OU. As a general rule, the time required to register an OU increases according to the number of Regions in which your OU is operating, multiplied by the number of accounts in the OU. + As an estimate, an OU with 680 accounts may require up to 2 hours to register and enable controls, and up to 1 hour to re-register. Also, an OU that has many controls takes longer to register than an OU with few controls. + One concern about allowing a longer timeframe for registering an OU is that this process blocks other actions. Some customers are comfortable allowing longer times to register or re-register an OU, because they prefer to allow more accounts in each OU. # When to sign in as a root user Certain administrative tasks require that you must sign in as a root user. You can sign in as a root user to an AWS account that was created by account factory in AWS Control Tower. **You must sign in as a root user to perform the following actions:** + Change certain account settings, including the account name, root user password, or email address. For more information, see [Update and move accounts with AWS Control Tower](updating-account-factory-accounts.md). + To [close an AWS account](https://docs.aws.amazon.com//awsaccountbilling/latest/aboutv2/close-account.html). + For more information about actions that require root user login credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html) in the *AWS Account Management Reference Guide*. **Note** To change or enable your [AWS Support plan, you must be signed in as the root user *or* be a user with the appropriate IAM permissions. ](https://docs.aws.amazon.com//controltower/latest/userguide/troubleshooting.html#getting-support). **To sign in as root user** 1. Open the AWS sign-in page. If you don't have the email address of the AWS account to which you require access, you can get it from AWS Control Tower. Open the console for the management account, choose **Accounts**, and look for the email address. 1. Enter the email address of the AWS account to which you require access, and then choose **Next**. 1. Choose **Forgot password?** to have password reset instructions sent to the root user email address. 1. Open the password reset email message from the root user mailbox, then follow the instructions to reset your password. 1. Open the AWS sign-in page, then sign in with your reset password. Alternatively, you can use the AWS Root Access Management feature, which allows root actions to be performed on member accounts, without needing to sign in as Root. For more information, see [Centrally managing root access for customers using AWS Organizations](https://aws.amazon.com/blogs/aws/centrally-managing-root-access-for-customers-using-aws-organizations/). # AWS Organizations guidance AWS Control Tower is closely associated with AWS Organizations. Here is some specific guidance about how they work together best to protect your AWS environment. + You can find guidance about best practices to protect the security of your AWS Control Tower management account and member accounts in the AWS Organizations documentation. + [Best practices for the management account](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) + [Best practices for member accounts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_member-acct.html) + Do not update existing service control policies (SCPs) attached to an OU that is registered with AWS Control Tower. Doing so could result in the controls entering an unknown state, which will require you to reset your landing zone or re-register your OU in AWS Control Tower. Instead, you can use AWS Organizations to create new SCPs and attach those to the OUs rather than editing the SCPs that AWS Control Tower has created. + Moving individual, already enrolled, accounts into AWS Control Tower, from outside of a registered OU, causes drift that must be resolved. See [Types of governance drift](governance-drift.md). + If you use AWS Organizations to create, invite, or move accounts within an organization registered with AWS Control Tower, those accounts are not enrolled by AWS Control Tower and those changes are not recorded. If you need access to these accounts through SSO, see [Member Account Access](https://aws.amazon.com//premiumsupport/knowledge-center/organizations-member-account-access/). + If you use AWS Organizations to move an OU into an organization created by AWS Control Tower, the external OU is not registered by AWS Control Tower. + AWS Control Tower handles permission filtering differently than AWS Organizations does. If your accounts are provisioned with AWS Control Tower account factory, end-users can see the names and parents of all OUs in the AWS Control Tower console, even if they don't have permission to retrieve those names and parents from AWS Organizations directly. + AWS Control Tower does not support mixed permissions on organizations, such as permission to view an OU's parent but not to view OU names. For this reason, AWS Control Tower administrators are expected to have full permissions. + The AWS Organizations `FullAWSAccess` SCP must be applied and should not be merged with other SCPs. Change to this SCP is not reported as drift; however, some changes may affect AWS Control Tower functionality in unpredictable ways, if access to certain resources is denied. For example, if the SCP is detached, or modified, an account may lose access to an AWS Config recorder or create a gap in CloudTrail logging. + Don't use the AWS Organizations `DisableAWSServiceAccess` API to turn off AWS Control Tower service access to the organization where you’ve set up your landing zone. If you do so, certain AWS Control Tower drift detection features may not function properly without messaging support from AWS Organizations. These drift detection features help guarantee that AWS Control Tower can report the compliance status of of organizational units, accounts, and controls in your organization accurately. For more information, see [API\$1DisableAWSServiceAccess in the AWS Organizations API Reference](https://docs.aws.amazon.com//organizations/latest/APIReference/API_DisableAWSServiceAccess.html). # IAM Identity Center guidance AWS Control Tower recommends that you use AWS Identity and Access Management (IAM) to regulate access to your AWS accounts. However, you have the option to choose whether AWS Control Tower sets up IAM Identity Center for you, whether you set up IAM Identity Center for yourself, in a way that meets your business requirements most effectively, or whether to select another method for account access. **Note** **SSO** is an abbreviation used in the technology industry to denote *single sign-on*. In general terms, SSO is a session and user authentication service. It permits someone to use one set of login credentials for access to many applications. When referring to the single-sign on capability in AWS, we are referring to the AWS service called **AWS Identity and Access Management**, and abbreviated as **IAM** or **IAM Identity Center**. 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. **Choosing an option** From the console, you can choose to self-manage IAM Identity Center during the landing zone set up process, rather than allowing AWS Control Tower to set it up for you. At any time later, you can choose to change this selection, by modifying the landing zone settings and updating your landing zone on the landing zone **Settings** page. **To discontinue AWS IAM Identity Center in AWS Control Tower, or to begin using AWS IAM Identity Center** 1. Navigate to the landing zone **Settings** page 1. Select the **Configurations** tab 1. Then choose the appropriate radio button, to change your selection for AWS IAM Identity Center. After you choose to self-manage AWS IAM Identity Center as your IdP, AWS Control Tower creates only those roles and policies needed to manage AWS Control Tower, such as `AWSControlTowerAdmin` and `AWSControlTowerAdminPolicy`. For landing zones that self-manage, AWS Control Tower no longer creates IAM roles and groupings for customer-specific use — not during the landing zone set-up process, nor during account provisioning with Account Factory. **Note** If you remove AWS IAM Identity Center from your AWS Control Tower landing zone, the users, groups, and permission sets that AWS Control Tower created are not removed. We recommend that you remove these resources. Account Factory customers with alternative identity providers (IdPs) such as Azure AD, Ping, or Okta, can follow the AWS IAM Identity Center [process](https://docs.aws.amazon.com//singlesignon/latest/userguide/manage-your-identity-source-idp.html) to connect to an external identity provider and onboard their IdP. You can return to having AWS Control Tower generate your groupings and roles at any time, by modifying the landing zone settings. + For specific information about how AWS Control Tower works with IAM Identity Center based on your identity source, see **Considerations for AWS IAM Identity Center customers** in the [Pre-launch checks](https://docs.aws.amazon.com//controltower/latest/userguide/getting-started-prereqs.html#sso-considerations) section of the *Getting Started* page of this User Guide. + For additional information about how the behavior of AWS Control Tower interacts with IAM Identity Center and different identity sources, refer to [Considerations for Changing Your Identity Source](https://docs.aws.amazon.com//singlesignon/latest/userguide/manage-your-identity-source-considerations.html) in the *IAM Identity Center User Guide*. + See [Working with AWS IAM Identity Center and AWS Control Tower](sso.md) for more information about working with AWS Control Tower and IAM Identity Center. # Account Factory guidance **Note** Single account provision, update and customization must target an organizational unit (OU) with AWSControlTowerBaseline enabled. If an OU does not have the AWSControlTowerBaseline enabled, you can activate account auto-enrollment or use ResetEnabledBaseline and ResetEnabledControl APIs on EnabledBaselines and EnabledControls on that OU to enroll accounts. For details of AWSControlTowerBaseline, see: [Baseline types that apply at the OU level](types-of-baselines.md#ou-baseline-types). You can encounter issues when using Account Factory to provision a new account in AWS Control Tower. For information about how to troubleshoot these issues, see the section [New Account Provisioning Failed](troubleshooting.md#account-provisioning-failed) in [Troubleshooting](https://docs.aws.amazon.com/controltower/latest/userguide/troubleshooting.html) of the *AWS Control Tower User Guide*. We recommend that you create federated users or IAM roles instead of IAM users. Federated users and IAM roles provide you with temporary credentials. IAM users have long-term credentials that can be difficult to manage. For more information, see [IAM identities (users, user groups, and roles)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) in the *IAM User Guide*. If you're authenticated as an IAM user or IAM Identity Center user when provisioning a new account in Account Factory or when using the *Enroll account* feature AWS Control Tower, verify that your user has access to your AWS Service Catalog portfolio. Otherwise, you might receive an error message from Service Catalog. For more information, see [No Launch Paths Found Error](troubleshooting.md#no-launch-paths-found) in [the Troubleshooting section](https://docs.aws.amazon.com/controltower/latest/userguide/troubleshooting.html) of the *AWS Control Tower User Guide*. **Note** **With auto-enrollment disabled:** Up to five accounts can be provisioned simultaneously. **With auto-enrollment enabled:** Up to 5 accounts can be provisioned simultaneously, but any active account move operation for the destination OU blocks all provisioning on the same OU until it completes. # Guidance on subscribing to SNS Topics Subscribe to SNS topics to get information about your AWS Control Tower environment. **Note** AWS Control Tower will stop sending drift notifications to SNS topic for all customers on LZ4.0\$1. + The `aws-controltower-AllConfigNotifications` SNS topic receives all events published by AWS Config, including compliance notifications and Amazon CloudWatch event notifications. For example, this topic informs you if a control violation has occurred. It also gives information about other types of events. (Learn more from [AWS Config](https://docs.aws.amazon.com//config/latest/developerguide/notifications-for-AWS-Config.html) about what they publish when this topic is configured.) + [Data Events](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html?icmpid=docs_cloudtrail_console#logging-data-events) from the `aws-controltower-BaselineCloudTrail` trail are set to publish to the `aws-controltower-AllConfigNotifications` SNS topic as well. + To receive detailed compliance notifications, we recommend that you subscribe to the `aws-controltower-AllConfigNotifications` SNS topic. This topic aggregates compliance notifications from all child accounts. + To receive drift notifications and other notifications as well as compliance notifications, but fewer notifications overall, we recommend that you subscribe to the `aws-controltower-AggregateSecurityNotifications` SNS topic. + To receive notifications about AWS Control Tower Account Factory for Terraform (AFT) errors, you can subscribe to an SNS topic called [https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/0f2caea57e37a1a58dc305e2f342e9c28aeb9c41/modules/aft-account-request-framework/sns.tf](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/0f2caea57e37a1a58dc305e2f342e9c28aeb9c41/modules/aft-account-request-framework/sns.tf), shown in the AFT repository. For example: ``` resource "aws_sns_topic" "aft_failure_notifications" { name = "aft-failure-notifications" kms_master_key_id = "alias/aws/sns" } ``` + All SNS topics are encrypted at rest with disk encryption. for more information, see [Data encryption](https://docs.aws.amazon.com//sns/latest/dg/sns-data-encryption.html). For more information about SNS topics and compliance, see [Prevention and notification](https://docs.aws.amazon.com//controltower/latest/userguide/prevention-and-notification.html). # Guidance for KMS keys AWS Control Tower works with AWS Key Management Service (AWS KMS). Optionally, if you wish to encrypt and decrypt your AWS Control Tower resources with an encryption key that you manage, you can generate and configure AWS KMS keys. You can add or change a KMS key any time you update your landing zone. As a best practice, we recommend using your own KMS keys and changing them from time to time. 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 customers who operate an AWS CloudHSM cluster:* Create a custom key store associated with your CloudHSM cluster. Then you can create a KMS key, which resides in the CloudHSM custom key store you created. You can add this KMS key to AWS Control Tower. You must make a specific update to the permissions policy of a KMS key to make it work with AWS Control Tower. For details, refer to the section called [Update the KMS key policy](configure-kms-keys.md#kms-key-policy-update). # Best practices for landing zone updates This section gives some considerations and best practices to keep in mind when you are considering an upgrade of your landing zone version in AWS Control Tower. The change from the 2.0 landing zone version series into the 3.0 landing zone version series is especially important. When you upgrade your landing zone, AWS Control Tower automatically moves you to the latest available version. **Note** It is a best practice to update to the latest version of the landing zone. **Summary of best practices explained in this section** + **Best practice:** For security and audit reasons, we strongly recommend that you enable logging across the board, for all accounts, and send logging information to a centralized location. In AWS Control Tower, this centralized location is the **Log archive** account, which provides an Amazon S3 logging bucket. + **Best practice:** If you opt out of the organization-level CloudTrail trail in AWS Control Tower, set up and manage your own trails. + **Best practice:** When operating your AWS Control Tower environment, set up a testing environment. **Benefits for moving from 2.x landing zone versions to 3.x landing zone versions** + Record AWS Config resources only in the home Region, which creates cost savings when you manage global resources + Encrypt your AWS CloudTrail trail with your own KMS key + Customize your log retention timeframe + Enhanced mandatory controls + Increased number of controls available + Integrated with AWS Security Hub CSPM + Python runtime updates **Caveats for moving from 2.x landing zone versions to 3.x landing zone versions** + With landing zone 3.0 and later, AWS Control Tower no longer supports account-level AWS CloudTrail trails that AWS manages. + You have an option to choose an organization-level trail managed by AWS Control Tower, or to opt out of it and manage your own CloudTrail trails. + Some potential exists for double costs, especially if some accounts within an OU are not enrolled in AWS Control Tower and have account-level trails of their own that you want to keep. **Considerations about choosing organization-level CloudTrail trails** + When you upgrade to 3.0 or later, AWS Control Tower deletes the account-level trails that it originally created, after 24 hours. [[Exception]](https://docs.aws.amazon.com//controltower/latest/userguide/retain-account-trails.html) + No data from these trails is lost. Your existing logs are preserved even when the trails are removed. + AWS Control Tower creates a new path in the same Amazon S3 bucket for the trails, to differentiate account-level trails from organization-level trails. + An account trail log path is of this form: `/orgId/AWSLogs/...` + An organization trail log path is of this form: `/orgId/AWSLogs/orgId/...` + Additional CloudTrail trails that you have deployed, trails not deployed by AWS Control Tower, are not touched. + All accounts are included in the organization-level trail—including accounts not enrolled in AWS Control Tower—if the unenrolled accounts are part of a registered OU. + Amazon CloudWatch alarms in linked accounts are not triggered. + If you opt out of an organization-level trail, AWS Control Tower still creates the trail, but sets its status to **Off**. + As a best practice, if you opt out of the organization-level trail in AWS Control Tower, you should set up and manage your own CloudTrail trails, **Benefits of organization-level trails** + The organization trail works across all accounts in the OU. + The logged items are standardized and cannot be modified by account users. **Consider a testing environment** When you upgrade your landing zone, AWS Control Tower makes changes only to the shared accounts and the Foundational OU. It does not make changes to your workload accounts or OUs. *However, as a best practice, when operating your AWS Control Tower environment, we recommend that you set up a testing environment.* Within the isolated testing environment, you can test the AWS Control Tower landing zone upgrades, as well as any changes you may make to service control policies (SCPs), and you can test the controls that you wish to apply to the environment. This recommendation is especially helpful if you are operating in a regulated industry. **Checklist for common errors when updating** Here is a short list of tasks you can perform to avoid common errors when updating your AWS Control Tower landing zone from 2.x versions to 3.x versions. **Basic update checklist** + Check your landing zone: – Go to the AWS Control Tower service, review the **Organizational units** and **Accounts** pages, and then confirm that your account state is set to **Registered** and **Enrolled**. – If applicable, verify and confirm that the last run of your customizations pipeline was successful. – Check the Amazon S3 centralized logging bucket in the **Audit** account, because any changes previously made to the bucket policy will be overwritten. + Validate that any SCPs not owned by AWS Control Tower will not restrict the `AWSControlTowerExecution` role from performing actions in member accounts, or actions in the management account, for the administrative role that's performing the update. # AI-based services and AWS Control Tower You can create service control policies (SCPs) that allow you to opt out of having your data stored by AI-based services on AWS. These SCP policies specify that AI-based services, such as Amazon Rekognition or Amazon CodeWhisperer, cannot store and use your data to improve other AI-based AWS services. These AI opt-out SCP policies can apply to your entire organization, to an OU, or to a specific account. The policies are global in effect. You can find more information about these policies at [AI services opt-out policies](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html), in the AWS Organizations documentation. For a list of AWS services that use AI, along with examples of policies, see [AI services opt-out policy syntax and examples](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_ai-opt-out_syntax.html), in the *AWS Organizations User Guide*.