Guidance for creating and modifying AWS Control Tower resources - AWS Control Tower

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 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, which works at the landing zone level, or the control Region deny control applied to the OU, 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_DisableAWSServiceAccess in the AWS Organizations API Reference.

  • 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.

    • 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?.

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.