Building a well architected AWS GovCloud (US) environment with AWS Control Tower

Using AWS Control Tower in the AWS GovCloud (US) Regions

The recent announcement of AWS Control Tower achieves FedRAMP High authorization in AWS GovCloud (US) Regions reminds us that it is a good time to review how to implement a well-architected multi-account strategy. This helps customers quickly build a baseline multi-account environment while having access to the same Control Tower functionality as other AWS Regions.

AWS GovCloud (US) supports customers who must adhere to US regulated, security, and compliance requirements. This includes the International Traffic in Arms Regulations (ITAR) regulations, the Federal Risk and Authorization Management Program (FedRAMP) requirements, Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG) Impact Levels 2 and 4 and 5, and several others. Workloads that don’t adhere to these compliance requirements can be deployed in the AWS standard partitions. To build the foundational environment that will host these workloads in the AWS GovCloud (US) Regions we often start the conversation with AWS Control Tower. AWS Control Tower helps customers build and align to practices outlined in the AWS multi-account strategy.

In this blog, we will offer recommendations for setting up your governance in the AWS GovCloud (US) Regions. This will include governing your AWS workloads using Organizational Units (OUs), AWS accounts, and offer guidance on provisioning and enrolling new accounts and enrolling them into AWS Control Tower governance in the AWS GovCloud (US) Regions.

Security considerations

As a reminder, security and compliance are a shared responsibility between AWS and the customer. AWS GovCloud (US) is an isolated partition of AWS with internet access and its own AWS Identity and Access Management (IAM). While the AWS Control Tower service has achieved the FedRAMP High authorization, organizations with compliance requirements should carefully consider the impact of implementing these patterns. For more information about compliance in AWS GovCloud (US), see the Compliance documentation for AWS GovCloud (US).

Background

Before we dive into patterns for designing your foundational AWS GovCloud (US) (US) environment, we should cover some related terminology.

A Landing Zone is a well-architected multi-account environment that’s based on security and compliance. AWS best practices for a well-architected environment involve separating your resources and workloads into multiple AWS accounts. This strategy creates isolated resource boundaries, and limits impact of adverse advents.

AWS Control Tower orchestrates AWS services to build a landing zone preconfigured with your security guardrails. It offers a consistent way to set up and govern a secure, compliant, multi-account AWS environment.

Organizational units (OUs) are a container for accounts within a root. You can use OUs to group accounts together to administer as a single unit that simplifies the management of accounts. AWS recommends that customers create multiple organizational units (OUs), based on business purpose or ownership to simplify management and governance across similar environments. This helps you to apply distinct security controls aligned to your specific workloads across each environment.

AWS Control Tower creates a foundational landing zone with the following resources:

• Two Organizational units: Security, and Sandbox (optional), contained within the organizational root structure.
• Two shared accounts in the Security OU: the Log Archive account, and the Audit account. The Audit account is also referred to as the Security Tooling account.
  • The Log Archive account works as a repository for logs of activities and resource configurations from all accounts in the landing zone.
  • The Audit account – is a restricted account that’s designed to give your security and compliance teams the necessary access to all accounts in your Organization. From the audit account, you have programmatic access to review accounts. However, it does not provide the ability for you to log in to other accounts manually.
• An optional cloud-native directory in AWS IAM Identity Center. This helps customers to manage users centrally across their AWS Organization and connect to existing external identity providers.
• Mandatory, preventive, and detective controls to enforce policies and detect configuration violations.

Multi Account Strategy for the AWS GovCloud (US) Regions

AWS GovCloud (US) Regions are designed to address specific regulatory and compliance requirements of US government agencies at the federal, state, and local level. The AWS GovCloud (US) Regions are physically isolated and have logical network isolation from all other AWS Regions. AWS GovCloud (US) accounts are associated 1:1 with accounts in standard AWS Regions for billing, service, and support purposes. Customers are required to have an existing account before signing up for an AWS GovCloud (US) account. Despite this requirement, AWS GovCloud (US) organizations are separate from standard AWS Region organizations and are managed independently of one another.

Typically, customers want to use the AWS GovCloud (US) account mapped to your standard AWS Region organization management account to create your AWS GovCloud (US) organization. This maintains the relationship between the two organizations’ management accounts for administration. This is visualized in Figure 1.

Figure 1: shows typical mapping of standard AWS Region accounts to AWS GovCloud (US) accounts.

For more examples and a deeper explanation of AWS GovCloud (US) Organizations, visit our Security Blogs.

Control Tower on the AWS GovCloud (US)

Customers are encouraged to use similar design principles for their multi-account strategy for AWS GovCloud (US) organizations. However, you should be aware of some differences when deciding how to structure your accounts.

We recommend creating an AWS GovCloud (US) OU in your standard AWS Region organization. This will contain all standard accounts paired with your AWS GovCloud (US) accounts (except for your management account). We also recommend that the standard AWS Regions accounts paired to AWS GovCloud (US) accounts are not used for workloads. This gives you the ability to transfer your AWS GovCloud (US) accounts, or fully close them without affecting your other workloads.

Launching Control Tower in the AWS GovCloud (US)

To build your foundational organization in AWS GovCloud (US), you must be an individual or entity that meets the requirement of AWS GovCloud (US) (Refer to AWS documentation to review the requirements). The following diagram assumes you have set up Control Tower in your existing organization, and that you have been granted access to AWS GovCloud (US).

Figure 2: Displays the steps in building your foundational organization in the AWS GovCloud (US)

1. Create AWS GovCloud (US) accounts from your existing management account
   a. AWS GovCloud (US) management account
   b. AWS GovCloud (US) LogArchive account
   c. AWS GovCloud (US) Audit accountField Note: This can be done via the create-govcloud-account API, CLI.
   
   Customers can leverage AWS CloudShell a browser-based shell to run scripts with the AWS Command Line Interface (CLI) against their environments.Example command to create an AWS GovCloud (US) (US) Accountaws organizations create-gov-cloud-account --email <mycompany>-ct-govcloud-mgmt@<mycompany.com> —account-name <mycompany>-ct-govcloud-mgmt —role-name AWSControlTowerExecutionYou can also use the CLI or CloudShell to check the status of your AWS GovCloud (US) account creation, and retrieve your GovCloudAccountID.aws organizations list-create-account-status

   Which will return:

   {
   "CreateAccountStatuses": [
   {
   "Id": "car-543c789658174bb297793e884521d5e9",
   "AccountName": "<mycompany>-ct-govcloud-mgmt",
   "State": "SUCCEEDED",
   "RequestedTimestamp": "2023-06-21T19:13:40.442000+00:00",
   "CompletedTimestamp": "2023-06-21T19:14:45.932000+00:00",
   "AccountId": "111111111111",
   "GovCloudAccountId": "222222222222"
   },

2. While still in the existing management account, Create a AWS GovCloud (US) OU and extend Control Tower governance to these new paired accounts.
3. In the AWS GovCloud (US) management account: Create an organization and invite the newly created LogArchive and Audit Accounts into the AWS GovCloud (US) organization. From the LogArchive and Audit accounts, accept that invitation.
   
   Field Note: Accepting the invitation can be done by switching roles into the LogArchive and Audit accounts from the AWS GovCloud (US) management account. To do this, you will be using the role specified during the creation and account from the preceding command.
   
4. In the AWS GovCloud (US) management account: Follow the procedure to set up AWS Control Tower in an existing organization and specify the two accounts created previouslyField Note: Although it is an optional configuration during Control Tower launch, AWS Key Management Service (KMS) encryption is highly recommended to meet compliance requirements. When configuring your KMS key policy, remember that AWS GovCloud (US) ARNs are different than those in other AWS Region.

The following is a key policy using KMS within standard AWS Regions. Notice the ARN within the Resource item:

"Resource": "arn:aws:kms:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:key/YOUR-KMS-KEY-ID",
"Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:cloudtrail:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:trail/aws-controltower-BaselineCloudTrail" },
"StringLike": { "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:YOUR-MANAGEMENT-ACCOUNT-ID:trail/*"

The following is a key policy using KMS within AWS GovCloud (US) regions. The ARN uses a different syntax:

"Resource": "arn:aws-us-gov:kms:YOUR-GOVCLOUD-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:key/YOUR-KMS-KEY-ID",
"Condition": { "StringEquals": { "aws:SourceArn": "arn:aws-us-gov:cloudtrail:YOUR-GOVCLOUD-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:trail/aws-controltower-BaselineCloudTrail" },
"StringLike": { "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws-us-gov:cloudtrail:*:YOUR-MANAGEMENT-ACCOUNT-ID:trail/*"

Patterns for organizing your AWS Accounts

It’s common for customers to start with a basic multi-account structure and incrementally expand it as their needs evolve and their experience with AWS grows. The AWS Control Tower landing zone provides a foundational security OU, and designates two AWS accounts to centralize log information and provide read-only audit mechanisms for security teams. You can expand the overall set of OUs to align toward common use cases from business and technical users within your organization. In this section, we will introduce an Infrastructure OU to our landing zone. We will also show steps to enroll a shared services account into governance using AWS Control Tower.

The Infrastructure OU is a foundational OU that contains shared infrastructure services. Generally, these AWS accounts are managed by infrastructure and operations teams, and are responsible for maintaining services shared by your entire organization. Common use cases for the Infrastructure OU include the following designated AWS Accounts:

• Networking Account – manages networking resources and routes traffic between accounts in your environment, on premises, and egress/ingress traffic to the internet.  Network considerations for AWS GovCloud (US) can be found in our hybrid Direct Connect with AWS GovCloud (US) blog. 
• Shared Services Account – manages resources provided to the entire organization, and shared across all AWS accounts. For instance, Identity management services, single sign-on capabilities (AWS IAM Identity Center) are considered shared resources. In addition, buying and sharing software licenses across your organization, remote desktop management, and endpoint security management are also shared.

Figure 3: illustrates a sample relationship between standard AWS Regions and AWS GovCloud (US) OUs and accounts

See here for more Recommended OUs and accounts.

Create your shared services account and enroll into governance

In this section, we will create a shared services account within an Infrastructure OU for demonstration purposes. We will demonstrate how to create a new AWS account with access to the AWS GovCloud (US) Regions. We will then enroll the account into governance using AWS Control Tower.

Follow steps 1-3 in the preceding section to create a new AWS account for shared services. Make sure you provide a unique email address when calling the create-govcloud-account API, and specify the role name AWSControlTowerExecution.

1. Navigate to the AWS Control Tower dashboard from the AWS GovCloud (US) management account
2. Select your sandbox account and click Enroll.
3. You will be prompted to select a registered OU for the account to reside in. Select Enroll.

Now let’s enroll our standard AWS Region account into governance:

1. In the standard AWS Region management account, navigate to the AWS Control Tower dashboard
2. Select your sandbox account and click Enroll
3. When prompted to select a registered OU, select your AWS GovCloud (US) OU and select Enroll

Congratulations! You have created a new AWS account and enrolled into AWS Control Tower governance.

Automated customizations

Customers looking to scale their account enrollment have a few options to consider:

• Within AWS Control Tower, you can enroll multiple accounts into a single OU.
• You can customize your landing zone, using automation, to provision and customize member accounts automatically to meet your governance needs. You can use a GitOps-style, automated process to extend the capabilities of your landing zone. Examples of this include solutions like Customizations for AWS Control Tower (CfCT), Account Factory Customization, Account Factory for Terraform (AFT), and Landing Zone Accelerator on AWS.
• You can use the Service Catalog API operations in your US GovCloud (US) Regions to automate enrollment of your AWS accounts into governance. Refer to this blog for a step-by-step tutorial.

Conclusion

In this post, we discussed patterns for setting up a multi-account Landing Zone in the AWS GovCloud (US) Regions. This was done by using the FedRAMP High authorized service AWS Control Tower. In addition to achieving FedRAMP High authorization in the AWS GovCloud (US-East and US-West) Regions, AWS Control Tower is in scope for numerous compliance programs and standards. It provides a way to set up a multi-account AWS environment based on AWS best practices. We demonstrated the steps to provision the AWS GovCloud (US) accounts, how to govern linked accounts used for billing, and discussed patterns for building a foundational Landing Zone.

We encourage users to customize this to fit their business and compliance needs. You can reference the multi-account and security reference architecture whitepapers for a deeper understanding. You can also use additional tools, such as CfCT and the Landing Zone Accelerator to customize your Landing Zone to meet your needs.

Additional resources

AWS GovCloud (US) Organizations
Understanding account linking
Differences in AWS GovCloud (US) Control Tower
AWS Hybrid Connectivity: Sharing AWS Direct Connect with AWS GovCloud (US) and commercial Regions
Identity management patterns in AWS GovCloud (US)
The Landing Zone Accelerator
Multi-Organization considerations
Walkthrough: Automate Account Provisioning in AWS Control Tower by Service Catalog APIs