# How AWS Regions Work With AWS Control Tower
AWS Control Tower is supported in the following AWS Regions:
+ US East (N. Virginia)
+ US East (Ohio)
+ US West (Oregon)
+ Canada (Central)
+ Asia Pacific (Sydney)
+ Asia Pacific (Singapore)
+ Europe (Frankfurt)
+ Europe (Ireland)
+ Europe (London)
+ Europe (Stockholm)
+ Asia Pacific (Mumbai)
+ Asia Pacific (Seoul)
+ Asia Pacific (Tokyo)
+ Europe (Paris)
+ South America (São Paulo)
+ US West (N. California)
+ Asia Pacific (Hong Kong)
+ Asia Pacific (Jakarta)
+ Asia Pacific (Osaka)
+ Europe (Milan)
+ Africa (Cape Town)
+ Middle East (Bahrain)
+ Israel (Tel Aviv)
+ Middle East (UAE)
+ Europe (Spain)
+ Asia Pacific (Hyderabad)
+ Europe (Zurich)
+ Asia Pacific (Melbourne)
+ Canada West (Calgary)
+ Malaysia (Kuala Lumpur)
+ Asia Pacific (Thailand)
+ Mexico (Central)
+ Asia Pacific (Taipei)
**About your home Region**
When you create a landing zone, the Region that you're using for access to the AWS Management console becomes your home AWS Region for AWS Control Tower. During the creation process, some resources are provisioned in the home Region. Other resources, such as OUs and AWS accounts, are global.
After you've selected a home Region, you cannot change it.
** Controls and Regions**
Currently, all preventive controls work globally. Detective and proactive controls, however, only work in Regions where AWS Control Tower is supported. For more information about the behavior of controls when you activate AWS Control Tower in a new Region, see [Configure your AWS Control Tower Regions](#deploying-to-new-region).
## Configure your AWS Control Tower Regions
This section describes the behavior you can expect when you extend your AWS Control Tower landing zone into a new AWS Region, or remove a Region from your landing zone configuration. Generally, this action is performed through the **Update** function of the AWS Control Tower console.
**Note**
We recommend that you avoid expanding your AWS Control Tower landing zone into AWS Regions in which you do not require your workloads to run. Opting out of a Region does not prevent you from deploying resources in that Region, but those resources will remain outside of AWS Control Tower governance.
During configuration of a new Region, AWS Control Tower updates the landing zone, which means that it *baselines* your landing zone —
+ to operate actively in all newly-selected Regions, and
+ to cease governing resources in deselected Regions.
Individual accounts within your organizational units (OUs) that are managed by AWS Control Tower are not updated as part of this landing zone update process. Therefore, you must update your accounts by re-registering your OUs.
When configuring your AWS Control Tower Regions, be aware of the following recommendations and limitations:
+ Select Regions in which you plan to host AWS resources or workloads.
+ Opting out of a Region does not prevent you from deploying resources in that Region, but those resources will remain outside of AWS Control Tower governance.
When you configure your landing zone for new Regions, AWS Control Tower detective controls adhere to the following rules:
+ *What exists stays the same.* Control behavior, detective as well as preventive, is unchanged for existing accounts, in existing OUs, in existing Regions.
+ *You can’t apply new detective controls to existing OUs containing accounts that are not updated.* When you’ve configured your AWS Control Tower landing zone into a new Region (by updating your landing zone), you must update existing accounts in your existing OUs before you can enable new detective controls on those OUs and accounts.
+ *Your existing detective controls begin working in the newly configured Regions as soon as you update the accounts.* When you update your AWS Control Tower landing zone to configure new Regions and then update an account, the detective controls that already are enabled on the OU will begin working on that account in the newly configured Regions.
**Configure AWS Control Tower Regions**
1. Sign in to the AWS Control Tower console at [https://console.aws.amazon.com//controltower](https://console.aws.amazon.com//controltower)
1. In the left-pane navigation menu, choose **Landing zone settings**.
1. On the **Landing zone settings** page,in the **Details** section, choose the **Modify settings** button in the upper right. You are directed to the update landing zone workflow, because governing new Regions, or removing Regions from governance, requires you to update to the latest landing zone version.
1. Under **Additional AWS Regions for governance**, search for the Regions you want to govern (or stop governing). The **State** column indicates which Regions you currently govern, and which ones you don't.
1. Select the checkbox for each additional Region to govern. Deselect the checkbox for each Region from which you are removing governance.
**Note**
If you opt not to govern a Region, you can still deploy resources in that Region, but those resources will remain outside of AWS Control Tower governance.
1. Complete the rest of the workflow, then choose **Update landing zone**.
1. When the landing zone setup completes, **Re-register** the OUs to update the accounts in your new Regions. For more information, see [When to update AWS Control Tower OUs and accounts](update-existing-accounts.md).
An alternative method of provisioning or updating individual accounts after configuring new Regions is by using [the API framework of Service Catalog](https://docs.aws.amazon.com//servicecatalog/latest/dg/API_Reference.html) and [the AWS CLI](https://docs.aws.amazon.com//cli/latest/reference/servicecatalog/index.html) to update the accounts in a batch process. For more information, see [Provision and update accounts using automation](update-accounts-by-script.md).
# Avoid mixed governance when configuring Regions
It is important to update all accounts in an OU after you extend AWS Control Tower governance to a new AWS Region, and after you remove AWS Control Tower governance from a Region.
*Mixed governance* is an undesirable situation that can occur if the controls governing an OU are not a complete match to the controls governing each account within an OU. Mixed governance occurs in an OU if accounts are not updated after AWS Control Tower extends governance to a new AWS Region, or removes governance.
In this situation, certain accounts within an OU may have different controls applied in different Regions, when compared to other accounts in the OU, or when compared to the landing zone's overall governance posture.
In an OU with mixed governance, if you provision a new account, that new account receives the same (updated) Region and OU governance posture as the landing zone. However, existing accounts that are not yet updated do not receive the updated Region governance posture.
In general, mixed governance may create contradictory or inaccurate status indicators in the AWS Control Tower console. For example, during mixed governance, opt-in Regions are shown with **Not governed** status, in registered OUs, for accounts that are not yet updated.
**Note**
AWS Control Tower does not permit controls to be enabled during a state of mixed governance.
**Behavior of controls during mixed governance**
+ During mixed governance, AWS Control Tower cannot consistently deploy controls that are based on AWS Config rules (that is, detective controls) in Regions that the OU already shows as **Governed**, because some accounts in the OU have not been updated. You may receive a `FAILED_TO_ENABLE` error message.
+ During mixed governance, if you extend the landing zone's governance to an opt-in Region while any account in the OU has not yet been updated, the `EnableControl` API operation on the OU fails for detective and proactive controls. You will receive a `FAILED_TO_ENABLE` error message, because non-updated member accounts within the OU have not yet been opted into those Regions.
+ During mixed governance, controls that are part of the **Security Hub CSPM Service-managed Standard: AWS Control Tower** cannot report compliance accurately in Regions where there is a mismatch between the landing zone configuration and the accounts that are not updated.
+ Mixed governance does not change the behavior of SCP-based controls (preventive controls), which apply uniformly to every account in an OU, in every governed Region.
**Note**
Mixed governance is not the same as drift, and it is not reported as drift.
**To repair mixed governance**
+ Customers are now able to repair mixed governance by resetting regional controls. Any non-global controls are regional (detective and proactive controls). You will be alerted that your OU is in a mixed governance through an alert banner.
# Considerations for activating AWS opt-in Regions
Although most AWS Regions are active by default for your AWS account, certain Regions are activated only when you manually select them. This document refers to those Regions as *opt-in Regions*. In contrast, Regions that are active by default, as soon as your AWS account is created, are referred to as *commercial Regions*, *default Regions*, or simply, *Regions*.
The term *opt-in* has a historical basis. Any AWS Regions introduced after March 20, 2019 are deployed as opt-in Regions. In an opt-in Region, your account is not enabled within that Region—and your identity is not replicated to the Region—unless you choose to opt into use of that Region. All of the data managed through the IAM service is considered identity data, including users, groups, roles, policies, identity providers, their associated data (for example, X.509 signing certificates or context-specific credentials), and other account-level settings, such as password policy and the account alias.
You can activate opt-in Regions automatically during landing zone setup, by selecting them. Your landing zone becomes active in all selected Regions.
If you choose to select an opt-in Region as your AWS Control Tower home Region, activate it first by following the steps in [Enabling a Region](https://docs.aws.amazon.com//general/latest/gr/rande-manage.html#rande-manage-enable), when signed in to the AWS Management Console. To bring your own existing Log Archive and Audit accounts from an opt-in Region, manually activate that Region first.
The AWS opt-in Regions include several Regions in which AWS Control Tower is available:
+ Asia Pacific (Hong Kong) Region, ap-east-1
+ Asia Pacific (Jakarta) Region, ap-southeast-3
+ Europe (Milan) Region, eu-south-1
+ Africa (Cape Town) Region, af-south-1
+ Middle East (Bahrain) Region, me-south-1
+ Israel (Tel Aviv), il-central-1
+ Middle East (UAE) Region, me-central-1
+ Europe (Spain) Region, eu-south-2
+ Asia Pacific (Hyderabad) Region, ap-south-2
+ Europe (Zurich) Region, eu-central-2
+ Asia Pacific (Melbourne) Region, ap-southeast-4
+ Canada West (Calgary) Region, ca-west-1
+ Asia Pacific (Thailand), ap-southeast-7
+ Mexico (Central), mx-central-1
+ Asia Pacific (Taipei), ap-east-2
+ Asia Pacific (New Zealand) , ap-southeast-6
AWS Control Tower has some controls that work differently in the opt-in Regions than in the default Regions (other commercial Regions). For more information, see [Control limitations](control-limitations.md). Here are some considerations to keep in mind as you deploy workloads into opt-in Regions.
**Governing or activating?**
Remember that governing a Region is an action that you can select from the AWS Control Tower console, so that controls can be applied in the Region. Activating or deactivating an opt-in Region is a different action that you can choose in the AWS console, which opens the Region to your account, so that you can deploy resources and workloads in the Region.
**Behavioral considerations**
+ If you choose to govern opt-in Regions, we recommend that you do not deactivate (opt-out of) any of your governed opt-in Regions, because it can lead to failure of your workloads. AWS Control Tower does not allow deactivation of a governed Region from within the AWS Control Tower console, but be sure that you do not deactivate governed Regions from a source outside of AWS Control Tower, such as the AWS Billing console or AWS SDK.
+ When AWS Control Tower extends governance to an opt-in Region, it activates (opts-in) to the Region in all member accounts. When you remove a Region from governance, AWS Control Tower does not deactivate (opt-out of) the Region in the member accounts.
+ During Region deselection, AWS Control Tower skips removing resources from an opt-in Region if that Region was deactivated manually for an account from a source outside AWS Control Tower, such as the AWS Billing console or AWS SDK. We recommend that you remove resources from the Regions you’ve deactivated, or you may receive unexpected billing charges for those resources.
+ If your landing zone is decommissioned, AWS Control Tower cleans up resources in all the governed Regions, including the opt-in Regions. However, AWS Control Tower does not deactivate the opt-in Regions. You can deactivate the opt-in Regions as an additional step after decommissioning.
+ If your home Region is an opt-in Region, and if you intend to enroll existing accounts as your Log Archive and Audit accounts, you must manually activate the opt-in Region before you can select it as the home Region for your landing zone. See [Enabling a Region](https://docs.aws.amazon.com//general/latest/gr/rande-manage.html#rande-manage-enable).
+ If AWS Control Tower is set up with an opt-in Region as your home Region, and if you visit the AWS Control Tower service from the AWS console in any other Region, the console does not redirect you automatically to the home Region.
+ The underlying API has capacity limits, which may increase latency from a few minutes to many hours, depending on the number of Regions, accounts, and service load. As a best practice, opt-in only to those the AWS Regions where you will run workloads, and opt-in one Region at a time.
**Important limitations for governance and accounts**
+ If 16 or more commercial Regions where AWS Control Tower is available are governed, including opt-in Regions, the upper limit on the number of accounts per organizational unit (OU), is reduced, when registering an OU. For more information, see [Limitations based on underlying AWS services](https://docs.aws.amazon.com/controltower/latest/userguide/region-stackset-limitations.html).
# Configure the Region deny control
AWS Control Tower offers two Region deny controls. One control, `AWS-GR_REGION_DENY`, when activated, applies to the entire landing zone. Another control, `CT.MULTISERVICE.PV.1`, when activated, can apply to specific OUs that you specify. For more information see [Deny access to AWS based on the requested AWS Region](https://docs.aws.amazon.com//controltower/latest/controlreference/primary-region-deny-policy.html) and [Region deny control applied to the OU](https://docs.aws.amazon.com/controltower/latest/controlreference/ou-region-deny.html).
**Considerations about the Region deny control for the landing zone**
The Region deny control, [https://docs.aws.amazon.com//controltower/latest/controlreference/primary-region-deny-policy.html](https://docs.aws.amazon.com//controltower/latest/controlreference/primary-region-deny-policy.html) is unique, because it applies to the landing zone as a whole, rather than to any specific OU. To configure the Region deny control, go to the **Landing zone settings** page and select **Modify settings**.
+ This setting can be changed at a later time.
+ When enabled, this control applies to all OUs with the `AWSControlTowerBaseline` enabled.
+ This control cannot be configured for individual OUs.
**Note**
Before you enable the Region deny control, be sure that you do not have existing resources in these Regions, because you will not have access to your resources after you apply the control. While the control is enabled, you will not be able to deploy resources in the denied Regions.
When you enable the control, it applies to all top-level OUs with the `AWSControlTowerBaseline` enabled, and it is inherited by OUs lower in the organization hierarchy. When you remove the control, it is removed on all previously applied OUs, all non-governed Regions in AWS Control Tower remain in a **Not governed** status, and you can deploy resources in Regions outside of AWS Control Tower availability.
**Exceptions**
You cannot deny access to your home Region. Certain global AWS services, such as IAM and AWS Organizations, are exempt from the Region deny control. To learn more, see [Deny access to AWS based on the requested AWS Region](https://docs.aws.amazon.com//controltower/latest/controlreference/lz-region-deny.html).
+ Full control name: **Deny access to AWS based on the requested AWS Region for the landing zone**
+ Control description: Disallows access to unlisted operations in global and regional services outside of the specified Regions for the landing zone.
+ This is an elective control with preventive guidance.
To view the template for the Region deny control SCP, see [Deny access to AWS based on the requested AWS Region](https://docs.aws.amazon.com//controltower/latest/controlreference/lz-region-deny.html) in the *AWS Control Tower Control reference*. The AWS Control Tower SCP is similar to [the SCP for AWS Organizations](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-deny-region), but not identical.
You can determine Regional service endpoints on the [Regional services page](https://aws.amazon.com//about-aws/global-infrastructure/regional-product-services).
## Considerations for the OU-level Region deny control
The primary consideration about the OU-level Region deny control is to determine how it will interact with the landing zone Region deny control, if both are activated. For more information, see [Region deny control applied to the OU](https://docs.aws.amazon.com/controltower/latest/controlreference/ou-region-deny.html).
You also may wish to review [Configure the Region deny control](https://docs.aws.amazon.com//controltower/latest/userguide/region-deny.html).