Supporting Data Residency Requirements by Extending AWS Control Tower Governance to Non-supported Regions

In today’s complex computing environment, organizations continually have new requirements for maintaining data. In essence, data residency is established on multiple levels, and AWS offers different features and services to support it. This post focuses on utilizing the AWS Control Tower governance model to support data residency requirements in regions where AWS Control Tower isn’t available yet.

AWS Control Tower automates the setup of your multi-account AWS environment with a few clicks. The setup employs blueprints that capture AWS best practices for configuring AWS security and management services to govern your environment. It also provides mandatory and strongly recommended high-level rules, called guardrails. Guardrails help enforce your policies by using service control policies (SCPs), or detect and report policy violations by using AWS Config rules. These rules remain in effect as you create new accounts or make changes to existing accounts. Furthermore, AWS Control Tower provides a summary report of how each account conforms to your enabled policies.

For non-governed regions, AWS Control Tower governance won’t be extended to these regions by default. In this post, we will guide you on how to leverage automation using AWS Service Catalog, AWS CloudFormation templates, and AWS Lambda functions to first extend AWS Control Tower support in the required region, and then customize the region of the centralized logs to Amazon Simple Storage Service (Amazon S3) buckets. Once AWS Control Tower governance is extended, additional guardrails can be deployed on the Organization or Organizational Unit (OU) level to further enforce data residency policies.

An important factor for the direction of this deployment is the AWS CloudFormation StackSets feature support. AWS CloudFormation StackSets play a critical role in pre-deploying resource stacks across different regions and accounts. The focus here is to deploy this solution in regions where AWS CloudFormation StackSets is not supported or where regions are disabled by default.

In cases where the AWS CloudFormation StackSets feature is available and the region is enabled by default, this solution can be deployed using the AWS Control Tower customization framework. This use case will be outside of the scope of the current discussion.

There are two main advantages from following this post’s guidelines:

• The ability to extend mandatory (preventative and detective) guardrails to accounts created in non-supported regions.
• The option to create local S3 buckets for hosting logs to comply with any data localization requirements.

Things to Consider

Here is a summary of certain areas that are important to consider before deploying this solution:

• This procedure starts by enabling AWS Control Tower in a supported home region that can’t be changed at a later stage.
• Upon launching AWS Control Tower, two S3 buckets are created in the Log Archive account by default in the home region. These buckets can’t be deleted.
• As AWS CloudFormation StackSets aren’t supported in the regions discussed in the post, this process must be repeated for every new account created in the desired region.
• For any services/products launched through AWS Service Catalog, changes and modification must be conducted through the “provisioned products” menu and not directly on these resources.
• This post provides the possibility of creating new S3 buckets in the central Log Archive account. If this isn’t needed, then feel free to customize the CloudFormation templates as needed for your setup.
• A special OU will be created for the purpose of baselining new accounts. This OU shouldn’t have any SCPs attached to it, otherwise the baseline will fail. Once a new account is baselined, it can be moved to its final OU and it will inherit all of the enabled SCPs.
• For any tasks other than launching AWS Control Tower and creating new accounts in Account Factory, the region should always be changed to the preferred non-supported region.
• Every time an account is created, verify that the region is enabled. For some regions like me-south-1, allocate 10 mins to enable the region for the first time.
• Cleanup for all of these steps must be done from AWS CloudFormation templates by deleting the stack or by terminating the provisioned product from the AWS Service Catalog. For accounts closure, follow “Unmanaging a member account procedure”.
• When AWS Control Tower is available in a new region, customers get a notification to update the AWS Control Tower. Before you update AWS Control Tower, you must delete the AWS CloudFormation Stacks for these newly supported regions. The required steps are mentioned later.
• During the time period in which you delete the AWS CloudFormation Stacks and upgrade AWS Control Tower, the traceability of any configuration changes won’t be captured. We recommend performing the deletion of stack instances and upgrading at a time window when minimum changes to your resource configuration are expected.
• Any logging and access data stored in the Centralized Amazon S3 buckets in the Log Archive account must be archived or stored, as these buckets will be deleted during the cleanup process. These buckets will be recreated by AWS Control Tower once the upgrade process finishes.
• Once the AWS Control Tower Landing Zone is upgraded successfully, you will have the continuity of the AWS Config data, which is collected in the centralized log archive account.

Solution Overview

The solution uses a nested AWS CloudFormation stack that is pushed as an AWS Service Catalog product across the whole organization to maintain reproducibility and consistency across all AWS Organizations member accounts. Once AWS Control Tower is deployed, the management account will be used to deploy the resources required to govern a non-supported region. The solution has multiple steps, but it is composed of two phases. First, the security accounts (Log archive and Audit) get prepared with the required AWS services, and for the second phase all of the organizations’ member accounts get baselined to start using these AWS services, such as sending logs to the audit account, extending guardrails, etc. The following diagrams highlight these main phases:

The following are services that will be used as part of the solution:

• AWS Control Tower
• AWS Organizations
• AWS CloudFormation templates
• AWS Service Catalog
• AWS Lambda
• AWS CloudTrail
• AWS Config
• AWS Identity and Access Management (IAM)
• Amazon Simple Notification Service (SNS)
• Amazon Simple Storage Service (S3)
• Amazon CloudWatch
• Amazon Virtual Private Cloud (VPC)

Procedure

Prerequisites

The following are prerequisite steps for the solution:

1. Prepare a list of email addresses to be used for AWS Control Tower implementation as follows:
   1. An email address for the Log Archive account (Default-managed account)
   2. An email address for the Audit account (Default managed account)
   3. An email address for the Shared Services account (To host all solutions configuration templates that will be referenced in later stages)
   4. An email address for any Workload accounts that must be created and baselined
2. Launch AWS Control Tower from a supported Home Region
   1. At this step, a Log Archive and Audit accounts will be created under the security OU
3. Create the needed OUs for your setup in addition to a PolicyStagingCustom OU that will be used temporarily to baseline the new accounts
4. Detach SCP from the PolicyStagingCustom OU
5. Create a Shared Services account and any other accounts using one of these options:
   1. AWS Control Tower Account Factory
   2. The automation solution referenced in this AWS Post: “How to automate the creation of multiple accounts in AWS Control Tower”

Deployment Phases and Steps

The following phases and steps will be deployed in the provided order to conduct these activities.

Phase 1 of the Deployment

Navigate to the region that must be governed by AWS Control Tower, and run the following steps there.

Step 1: Create a new Amazon S3 bucket in the Shared Service account to host all of the reference AWS CloudFormation templates and Lambda functions that are used throughout the deployment.

• Access the GitHub repository to download all of the needed templates
• Log-in to the Shared Services account
• Enable the required (non-supported) region of choice
• Create an Amazon S3 bucket to host the solution templates
  • Navigate to the AWS CloudFormation console and choose Create stack. The YAML file to create a shared Amazon S3 bucket with the required bucket policy and to host all of the code templates.”regional-deployment-bucket.template.yml”
  • Use the organization ID created in the prerequisite steps
• Upload the required templates to the created Amazon S3 bucket in their corresponding folders. Follow the same folder structure, similar to the following diagram.

Note the following parameters:

Step 2: In the audit account, run the following from AWS CloudFormation referencing the Amazon S3 bucket created in the Shared Services account in Step 1. Fill in the following Parameters:

This template will be accomplishing the following:

1. AWS Config Aggregator is configured for guardrail compliance. For each workload account, the Control Tower Detective Guardrails is used to achieve this baseline.
2. SNS Topics are configured for the Audit Account. Workload accounts will be subscribing to these SNS Topics during the account baseline.

Step 3: In the Log Archive account, create a new stack using the AWSControlTowerLoggingResources.yml template, from the AWS CloudFormation console. Reference the Amazon S3 bucket created in the Shared Services account in Step 1. This template will create two Amazon S3 buckets that will be used for hosting logs and access logs for all of the organization accounts.

Phase 2 of the Deployment

 Step 4: Create a standard workload baseline AWS Service Catalog product to be pushed across the entire organization.

1. Log in to the management account, switch to the non-supported region. (Or delegate the Shared Services account to become the administrator account for AWS Service Catalog)
2. Navigate to the AWS Organizations console, note the Organization ID, and then navigate to the AWS Services Catalog console.
3. Choose Portfolio from the left-side menu, then choose Create portfolio to create a portfolio with the following details:

4. Create a product to be attached to the portfolio that was created in the previous step to be shared across the whole organization with the following details:

5. Attach the product created to the right portfolio, access the product, and from the Actions -> choose to add product to portfolio.
6. Access the created portfolio, from Actions -> choose Share -> and fill in the following details:

Note: If you get a message to enable organization share, please accept.

Step 5: At this step, enable the non-supported region (if applicable) in a given account and accept the Organization Shared AWS Service Catalog products to be launched in this account. Repeat this step for Log Archive, Audit, and any other workload accounts.

Estimated time ~15 min (10 min for enabling a new region if applicable)

1. Use AWS Single Sign-On or assume a role to access the required workload account.
2. Switch to the region to be used in this account going forward.
3. From the AWS Management Console, navigate to AWS Service Catalog
   1. Under AWS Service Catalog  Administrator
      1. Navigate to Portfolios from the left-side menu
      2. Switch to the Imported panel
      3. You should see the portfolio pushed from the management account as follows
         1. New Account Baseline
      4. Select the New Account Baseline portfolio
         1. Choose Group, roles and users
            1. Add roles that should be allowed to run this baseline. Once added, verify that the “New Account Baseline” is accessible from the AWS Service Catalog product list

Step 6: Launch the New Account Baseline product to start the baseline process in the non-supported region. Repeat this step for Log Archive, Audit, and any other workload accounts.

1. In the newly created workload account, navigate to the AWS Service Catalog console and select Products on the left-side menu
2. Choose the New Account Baseline product, then choose Launch product
3. Fill in the following details
   • Provisioned product name: Enter a unique name or select Generate name to provide a name automatically, use (account name-baseline) as a suggestion for naming convention
   • Product version: Latest
   • Log retention in days: Specifies the number of days to retain CloudTrail log events in the CloudWatch Logs. This value is also used to retain notification forwarding log events in the Lambda log group (default one year)
   • AWSLogsS3KeyPrefix: Enter organization ID.
   • AuditAccountID: To reference the Security Audit account, for cross-account access
   • AuditBucketName: Enter S3 Audit Bucket name starting with aws-controltower-logs-xxxxx that was created in the Log Archive account after Step 3
   • BucketName: Use the Shared Services Template Bucket name where templates are stored
   • CTHomeRegion: Enter the home region where Control Tower is deployed
   • HomeRegionName: Enter the region to extend the governance
     
4. To verify the progress, navigate to provisioned products from the left-side menu
5. Once the account baseline is done successfully, log back in to the management account
6. Navigate to the AWS Service Catalog console, choose Provisioned products, and select the newly baselined account
   1. Note all of the account details, such as Account name, Account email, SSO name, and SSO email
   2. Choose Update from the actions drop-down menu
   3. For the required parameters, fill in the account details as created earlier, except for the ManagedOrganizationalUnit parameter
   4. For the ManagedOrganizationalUnit, choose the right designated OU (PRD, DEV, etc.)
   5. Verify the status of the account update in the Provision Accounts
7. Once done, access the Control Tower dashboard to check the overall organization structure
8. In the account itself, verify the following:
   1. Navigate to the Amazon VPC console and verify that default VPC was deleted.
   2. Navigate to the AWS CloudTrail console and verify that the trail is sending logs to the newly created Amazon S3 bucket, created locally to the preferred Region.

9. At this point, account baseline is done successfully and you can start launching the required products and services

Repeat Step 5 and 6 for Log Archive, Audit, and any other workload accounts.

Step 7: Update all account; Audit, Log archive, and Shared Services OU, and move them to their respective OU as follows:

1. For default accounts, such as Security and Log Archive, change their OU from AWS Organization console
2. For Created accounts, such as Shared Services, update the AWS Services Catalog Provision Product

At this point, the environment is ready to start extending AWS Control Tower Governance to any newly created accounts.

Rollback and Cleanup Steps

The following steps describe how to rollback the deployed configuration:

1. Move the Audit and Log Archive and any baselined Workload accounts back to the PolicyStagingCustom OU
2. Log in to the Workload account, navigate to the AWS Service Catalog console, and choose Provisioned products from the left-side menu
3. Choose the Account Baseline product and terminate it
4. Log in to the Log Archive account, navigate to the AWS Service Catalog console, and choose Provisioned products from the left-side menu
5. Choose the Account Baseline product and terminate it
6. Log in to the Audit account, navigate to the AWS Service Catalog console, and choose Provisioned products from the left-side menu
7. Choose the Account Baseline product and terminate it
8. Log in to the Log Archive account and navigate to the Amazon S3 console:
   1. If you want to store you logs, archive the logs and empty the Amazon S3 buckets created in Phase 1 Step 3
   2. Navigate to the AWS CloudFormation console, and then delete the Logging Resources CloudFormation stack
9. Log in to the Audit account, navigate to the AWS CloudFormation console, and delete the Audit account CloudFormation stack
10. Log in to the ShareServices account and empty the S3 bucket with the templates
11. Navigate to the AWS CloudFormation console and delete the stack used to create the Amazon S3 bucket with the templates

Conclusion

In this post, we have showed you how to extend AWs Control Tower governance to non-supported regions that don’t support CloudFormation StackSets. The solution provides the following features that can be customized based on specific use cases:

1. Create a template source S3 bucket in a Shared Service account
2. Create new S3 buckets in the preferred new region to host logging data from all of the created accounts in the log archive account
3. For the Audit Account, it configures AWS Config Aggregator for Guardrail compliance, and it configures the SNS Topics for the Audit Account in the new region
4. In each of the workload accounts, the following was applied:
   1. Extend mandatory guardrails to non-supported regions that don’t have the StackSets feature enabled
   2. Stop CloudTrail and AWS Config Logs from being sent to the default created buckets in the home region
   3. Force CloudTrail and AWS Config Logs to be sent to the newly created buckets in the desired region to support data localization requirements if applicable
   4. Delete the default VPC
   5. Enforce S3 Block Public Access (BPA) policy by default on an account level

About the authors