AWS Field Notes

Enabling guardrails in new AWS Regions the AWS Control Tower supports

Note: Updated in November 2020 to support additional five regions (Canada, Frankfurt, Stockholm, London, Singapore) that AWS Control Tower supports now. Though the blog content refers to Sydney region, the instructions provided below are applicable to the new supported regions as well.

For the first time since the launch of AWS Control Tower, we are happy to add support for the AWS Sydney Region. The AWS Control Tower service is releasing a new version with additional AWS Region Support. In order to enable the newly supported AWS Regions, existing customers will need to update their AWS Control Tower landing zone to the most current version.

Version 2.3 of the AWS Control Tower landing zone extends AWS Control Tower support to the Sydney Region. If you already have an AWS Control Tower setup and you plan on running workloads in the Sydney Region, you must update your AWS Control Tower landing zone to version 2.3, via the Settings page of AWS Control Tower. If you have launched AWS Control Tower after the launch of the Sydney Region support (March 6, 2020), then you will be automatically running on the latest version of the AWS Control Tower landing zone, which supports the Sydney Region (as of this writing – Version 2.3).

If you launched AWS Control Tower’s landing zone before March 6, 2020, and would like to immediately take advantage of the Sydney Region and apply new detective guardrails to your existing AWS Organizations organizational units (OUs) that are under AWS Control Tower management. Then you must also update all existing Account Factory accounts in your AWS Control Tower environment.

In this blog, I show you how to update your accounts in an automated fashion.


Here’s a quick review of some terms used in this post:

  • An update script is a Python program that interacts with multiple AWS services, identify, and update the existing account factory accounts in AWS Control Tower environment.
  • An AWS Account Factory account is an AWS account provisioned using account factory in AWS Control Tower.
  • Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides secure, resizable compute capacity in the cloud.
  • The tag is a custom attribute label that you add to an AWS resource to make it easier to identify, organize, and search for resources.
  • AWS Service Catalog allows you to centrally manage commonly deployed IT services. In the context of this blog, account factory uses AWS Service Catalog to provision new AWS Accounts.
  • A provisioned product is an instance of the product that is provisioned by AWS Service Catalog. In this post, any new AWS account created used account factory is a provisioned product.
  • AWS Organizations helps you centrally govern your environment as you grow and scale your workloads on AWS.
  • AWS Single Sign-On (SSO) makes it easy to centrally manage access to multiple AWS accounts. It also provides users with single sign-on access to all their assigned accounts from one place.


  • You need to log into the AWS Control Tower master account with AWSAdministratorAccess role if using AWS SSO or equivalent permissions, if you are using other federations.
  • Optionally, launch Amazon EC2 instance using the template provided in Prepare your compute environment step below under How it works section.
  • This solution uses a dummy AWS SSO user while it updates the provisioned products. Alternatively, you could use your own secured email address. If you decide to go with latter, you must Identify a secure SSO user with restricted access.

IMPORTANT: The AWS SSO user you use while deploying this solution is given AWSAdminstratorAccess to all the accounts that are updated. We highly recommend deleting the user once your accounts have been updated.

Following are few additional things you need to know about this solution.

  • As mentioned in the prerequisites, this solution creates a dummy SSO user. The cleanup steps section of this blog walks you through the deletion of the dummy SSO user. However, the SSO user will have Administrator access to all the updated account factory accounts while updating the remaining account factory accounts as part of this solution.
  • Once successfully updated, the account will have an additional tag with a key: value pair ACCT_UPDATE:TRUE. This tag helps in identifying the accounts that are not updated successfully. Please do not delete this tag, while the accounts are still being updated.
  • In addition, the account tags mentioned above will not be automatically removed after the update process completes. You may choose to delete them manually using the instructions provided at the cleanup steps section of this post.

How it works

The following diagram shows the overview of the solution.

It takes up to 30 minutes to update each existing AWS account in AWS Control Tower. The accounts can be updated only one at a time. Depending on number of accounts that you have in your organizations, you must keep the session open long enough. In this section, you see one way of keeping these long running jobs uninterrupted using Amazon EC2 using the screen tool.

Optionally, you may use your own compute environment where you could handle the session timeouts. If you go with your own environment, make sure you have python3, screen and a latest version of boto3 installed.

  • Prepare your compute environment:
    • Log in to your AWS Control Tower as Administrator.
    • Switch to the Region where you deployed your AWS Control Tower.
    • If necessary, launch a VPC using the stack here and wait for the stack to COMPLETE.
    • Use the quick link to launch the CloudFormation template. The template configures:
      • Launches an EC2 instance with required software packages and the Update Script.
      • Creates and attaches an Instance profile with permissions to update the existing accounts.
      • Add the Instance profile role as Authorized role for Account Factory portfolio to grant required access to the AWS Service Catalog product that Account Factory uses.
  • Connect to the compute environment (one-way):
    • Go to the EC2 Dashboard, and choose Instances (running).
    • Select the EC2 instance that you just created and choose Connect.
    • Follow the instructions on the screen to connect to the EC2 instance.
  • Start a screen session in daemon mode. If your session gets timed out, you can open a new session and attach back to the screen session.
$ screen -dmS AccountUpdate
$ screen -ls
There is a screen on:
1 Socket in /var/run/screen/S-ssm-user.
$ screen -dr 585.AccountUpdate
  • Execute the Update script to update all the existing Account Factory accounts, one at a time in your AWS Control Tower environment.
$ python3 
  • Each account update takes up to 30 minutes. Depending on the number of accounts you have in your environment, the script could run for a longer duration. Wait for the script to complete updating all the accounts.
  • If the script is interrupted for some reason, wait for the last provisioned product status change from UNDER_CHANGE to AVAILABLE or TAINTED before restarting the script. Restarting the script while an account is actively updated, will result in following message and the script will exit.
$ python3
Update in progress. Allow UNDER_CHANGE or PLAN_IN_PROGRESS stacks to complete:['SC-Launch-for-Sandbox33']
  • When you restart an interrupted script, it will check and skip the previously updated accounts based of the resource tag ACCT_UPDATE on each account.
$ python3
Account – 111122223333 Skipped, Updated already
Account – 444455556666 Skipped, Updated already
Account – 777788889999 Skipped, Updated already
Updating Provisioned Account : 666666666666
Status: UNDER_CHANGE. Waiting for: 6.0 minutes before checking back 
SUCCESS: 666666666666 updated
Tagged resource 666666666666
Updating Provisioned Account : 777777777777
Status: UNDER_CHANGE. Waiting for: 6.0 minutes before checking back 

To check the tag on each account, go to AWS Organizations Console, choose the AWS account you want to check, and look under tags section on the right side bar.

Congratulations! You have successfully updated all your existing account factory accounts and enabled guardrails on the new Region that AWS Control Tower supported. You could verify this by using below steps:

  • Go to AWS CloudFormation StackSet console, and choose the StackSet that starts with AWSControlTowerGuardrailAWS, and select the Stack Instances tab.
  • You could see the guardrails enabled on the newly supported Region for one of your account factory accounts.

Cleanup steps

On successful completion of updating the existing account factory accounts, you could clean up the below resources used for this solution.

  • Delete the CloudFormation stack you launched to run update script. This will remote the instance profile role you created and also prevent any future billing charges.
  • Delete the AWS SSO user (default:
    • Go to AWS SSO Console, and choose Users.
    • Select the user you want to delete and choose Delete users.
  • You could optionally delete the tags on AWS accounts that are set by the update process. Please note, that if you rerun the script, the accounts without the ACCT_UPDATE tag will be whitelisted for another update.


In this post, I have shown you how to enable your AWS Control Tower accounts to recognize and support a new Region implementation. As AWS Control Tower continues to add additional Region support, there is a need to update your AWS Control Tower landing zone. When you update the landing zone version, the update process will baseline your accounts to operate actively in the new Region. It will not update the existing Account Factory accounts within your organizational units (OUs) that are managed by AWS Control Tower. By using the procedure in this post, you now have an automated method for updating your accounts.


Kishore Vinjam

Kishore Vinjam

Kishore Vinjam is a partner solutions architect focusing on AWS Service Catalog, AWS Control Tower, and AWS Marketplace. He is passionate about working in cloud technologies, and working with customers and building solutions for them. When not working, he likes to spend time with his family, hike, and play volleyball and ping-pong.

Rick Wiggins

Rick Wiggins

Rick Wiggins is a Senior Consultant with AWS Professional Services. His specialty is in Migrations and Multi-Account Architecture for large Enterprise customers in the US Government. His passion is building and automating Infrastructure and Operations to allow customers to focus more on their business. In his spare time, he can be found hanging out with his wife and three kids or tinkering with some new Alexa skill.