Field Notes: Cross-account deployments in an AWS Control Tower environment

AWS Feed
Field Notes: Cross-account deployments in an AWS Control Tower environment

AWS Control Tower helps customers put an orchestration layer on top of a multi-account strategy. When customers build applications, they often use separate accounts as part of a deployment pipeline so that they can validate changes before production. This best practice helps reduce blast radius should there be any issues with newer iterations.

With AWS Control Tower, customers can easily provision, govern, and manage AWS accounts at massive scale. Customers tend to build out AWS accounts like these as part of their multi-account strategy:

• Audit (created by AWS Control Tower): This is the account used by the security team to deploy services like Amazon GuardDuty and AWS Security Hub to monitor security alerts and malicious activity across all accounts in their organization.
• Networks: Some customers like to manage all networking aspects of their AWS presence in one AWS account. For example, if AnyCompany has a networking team who owns networking in the cloud, they could own the networking account and the networking components inside. For maintaining connectivity to on-premises data centers, some customers like to connect their AWS Direct Connect connection into the networks account. The connection can then be linked into other accounts through AWS Transit Gateway. The networking team has full control and visibility into networking services used.
• Tools/shared services: This account is commonly created for DevOps teams who want to host shared resources, such as pipelines or code repositories. In this example, the shared services account holds the pipeline responsible for deploying the application to multiple other AWS accounts. The DevOps team would have full ownership of this AWS account.

In this post, I will share how you can configure a cross-account deployment pipeline using AWS CloudFormation templates in the context of an AWS Control Tower environment.

Step 1: Create accounts

Before you begin, you must create multiple AWS accounts to host the resources that make up the pipeline. For instructions, see Provision and manage accounts with Account Factory in the AWS Control Tower User Guide.

Although you can add more and edit the pipeline accordingly, here are the accounts you must use and perform the steps in this post:

• Development: This account will host a repository like AWS CodeCommit where developers push their code. Developers can also use this account to build code in the AWS Cloud9
• Tools: This account will host the pipeline that facilitates the deployment across multiple AWS accounts. After code is pushed to the development account, the pipeline is triggered to push the new versions into test, and then, upon approval, production.
• Test: This account is where the new version of code is deployed for validation.
• Production: This account is where the production resources are deployed after the changes have been approved inside the pipeline in the tools account.

Figure 1: AWS account setup

Step 2: Configure the CLI and obtain credentials from AWS SSO

This step is essential for obtaining credentials for each respective AWS account, so you can easily deploy the CloudFormation template to the account.

If you do not have the AWS CLI installed, follow the steps in the AWS Command Line Interface User Guide.

After you’ve installed the AWS CLI, use the aws configure sso command to configure the AWS CLI to obtain credentials using AWS Single Sign-On. To get the start URL, sign in to the AWS SSO console with the management account.

Set up SSO from the CLI for each AWS account. In the CLI profile name input, this is where you set up the profile (for example, MyDevAccountProfile):

aws configure sso
SSO start URL [None]: https://{{YOUR-ID}}.awsapps.com/start#/ SSO Region [None]: {{REGION-OF-CHOICE}} There are X AWS accounts available to you.
{{CHOOSE ACCOUNT}}
Using the account ID {{ACCOUNT-ID-CHOSEN}}
There are X roles available to you. {{CHOOSE ROLE}}
Using the role name "{{ROLE-CHOSEN}}"
CLI profile name [{{ROLE-CHOSEN}}-{{ACCOUNT-ID-CHOSEN}}]: {{PROFILE-NAME}}

Step 3: Configure profiles and deploy the pipeline

Follow the steps outlined in the GitHub repository to create an AWS CodeCommit resource in your development account. Then push an AWS Serverless Application Model (AWS SAM) application to AWS CodeCommit.

Configure a profile for each AWS account (for example, MyDevAccountProfile, MyTestAccountProfile, and so on).

Use the single-click-cross-account-pipeline.sh script to enter the profiles you created. This script will deploy resources to each of your AWS accounts.

Figure 2: Workflow diagram

Edit the pipeline (optional)

If you would like to deploy to more accounts, you can edit the pipeline configuration files provided in the GitHub repository. The pipeline definition buildspec.yaml file is built to pass parameters to AWS SAM applications. You can edit the file to use other types of applications.

Conclusion

In this post, I’ve shown you how to deploy a cross-account deployment pipeline to an AWS Control Tower environment to ensure you have isolated environments for development, testing, production, and shared tooling. Now you can use a central AWS account that orchestrates the continuous delivery of an application across these AWS accounts.

About the author