Migrating to a multi-account strategy for public sector customers

A multi-account strategy is important for Amazon Web Services (AWS) public sector customers because it is the foundation of cloud governance and compliance. Public sector customers using a shared account model can improve security and operational efficiency by adopting a multi-account strategy. In this post, we explore methods for existing AWS public sector customers to prepare for and migrate to a multi-account environment.

Benefits of a multi-account AWS environment

Using multiple AWS accounts helps isolate workloads and data, establishes a secure framework for workloads, and aligns with the AWS Well-Architected Framework. A multi-account strategy is a core AWS best practice. AWS best practice is to deploy workloads into separate accounts, one account per software development lifecycle (SDLC) environment.

A multi-account strategy is important because:

• Each AWS account is an explicit security boundary, improving enterprise security.
• Different security controls can be implemented for different workloads and different SDLC environments.
• Compliance controls (such as FedRAMP or GDPR) can be implemented as required for different workloads or sets of workloads.
• Separating workloads into different accounts isolates risk and simplifies protective controls such as IAM policies and Service Control Policies, enabling innovation.
• Accounts can be dedicated to training, lab environments, experimenting with emerging technologies, and similar requirements.
• Billing reporting can be simplified with separate cost reporting based on workload and SDLC environment.

Multi-account environments can be built using several frameworks, including AWS Control Tower and Landing Zone Accelerator on AWS.

Planning for a multi-account environment

The central element in an AWS multi-account strategy is AWS Organizations. Organizations is a management service that helps you centrally govern your multi-account environment. An organization is an entity that you create to consolidate a collection of accounts and administer them as a single unit. Each organization is composed of a central management account and member accounts. Within each organization, you can organize the accounts in a hierarchical structure with a root at the top that contains nested organizational units (OUs). OUs are useful for grouping similar accounts based on function, applying similar policies, and sharing or provisioning common resources. Public sector customers can use guidance such as Best Practices for Organizational Units with AWS Organizations when considering how to implement the service. Organizations is provided at no additional cost to AWS customers.

The management account is established as the consolidated billing account for Organizations. Each central billing (that is, payer) account can only have one organization, so careful planning is critical to make sure future requirements can be accommodated. Most public sector customers are best served by managing their accounts in a single organization. Bills for member accounts are consolidated into the management account, resulting in advantages such as combined usage for potential volume discounts. The bills for member accounts can also be viewed or reported on separately as needed. Use of the management account should be limited to functions such as consolidated billing and configuration of centralized services, such as AWS Organizations.

While planning an organization structure, public sector customers should consider shared services such as network, identity and access management, security, and logging. AWS provides best practice recommendations for recommended OUs and accounts, which include shared services. Customers with compliance requirements, such as public sector customers, should also plan how to implement service control policies (SCPs). SCPs are a powerful type of protective policy you can use to manage the maximum permissions available in Organizations accounts. Public sector customers can, for example, use SCPs to deny access to any AWS services that are not authorized by a compliance program.

Setting up a multi-account environment

Public sector customers operating in AWS US East and US West Regions should first consider implementing AWS Control Tower in the management account to establish a multi-account environment. AWS Control Tower is an AWS service designed to help customers implement and govern multi-account environments. AWS Control Tower is provided at no additional cost to AWS customers.

AWS Control Tower automates the creation of a landing zone based on the AWS Well-Architected Framework to establish a secure, compliant environment for customers. AWS Control Tower features automated deployments of key AWS services, including Organizations, AWS IAM Identity Center for identity management, AWS CloudTrail for centralized logging, and AWS Config for configuration management. AWS Control Tower also features an account factory, which automates the provisioning of new accounts using templates to standardize account creation. Customers that want to use the Terraform infrastructure as code (IaC) tool can use AWS Control Tower Account Factory for Terraform (AFT).

Public sector customers with more complex requirements, those customers with more technical experience, and those customers operating in the AWS GovCloud (US) Regions should consider the Landing Zone Accelerator solution. Landing Zone Accelerator is an open source project using the AWS Cloud Development Kit (AWS CDK) and integrates with more than 35 AWS services. While using AWS Control Tower by default, Landing Zone Accelerator can be used to implement additional functionality, such as managing a centralized network topology or implementing security services such as AWS Security Hub. The Landing Zone Accelerator solution is provided at no additional cost to AWS customers.

Customers who wish to work with those who have specialized skills in deploying AWS Control Tower or Landing Zone Accelerator can engage AWS Professional Services or AWS Partners to find expertise in multi-account environment deployment.

Prepare workloads for migration

Using automation to deploy workloads is a critical aspect of effective cloud governance and migrating to a multi-account environment. Public sector customers with resources deployed in shared accounts can use AWS CloudFormation as an IaC tool. CloudFormation supports generating templates for existing resources as an automated method of creating IaC templates from resources provisioned in your account. This feature is supported in both commercial AWS Regions and AWS GovCloud (US) Regions. Similar functionality is available in open source repositories for other IaC products, such as HashiCorp Terraform. AWS Control Tower also the native use of Terraform code with the AWS Control Tower Account Factory for Terraform (ATF).

IaC templates should be created for all workload resources that will be migrated to a multi-account environment if the IaC does not already exist. Existing data required for each workload should be replicated, at least in part, to test the automated deployment of workloads into separate AWS accounts. If a continuous integration and continuous delivery (CI/CD) pipeline is used to deploy code, the pipeline can be replicated or forked to create a temporary pipeline for testing workload deployment into separate AWS accounts.

We recommend creating a discrete OU with a descriptive name, such as Migrations, to test the migration of workloads. Limited SCPs should be applied to the Migrations OU for initial testing. Accounts aligning with the best practices outlined in this post should be created in the Migrations OU. When IaC, data, and CI/CD preparation has been completed, workload resources should be deployed, data migrated, and applications deployed in the new accounts.

Figure 1. Example AWS Organizations deployment, including Migrations OU.

Integration testing with shared services and other workloads can begin after functional workload testing has been completed. As a final migration preparation step, required SCPs should be implemented and tested at an account or OU level.

Migrate workloads to multi-account environment

To migrate your workloads to the new multi-account environment, follow these high-level steps:

1. Migrate data.
2. Deploy new resources in the SDLC account under an OU named Workloads using IaC. (Alternatively, you can move the test account into the SDLC OU.)
3. Test new resources.
4. Move traffic to the new environment (using DNS, for example).

Migrating workloads from an existing AWS account into a multi-account environment will entail the migration of data and resources. If the resources were deployed using IaC, such as AWS CloudFormation or Terraform, they can be easily redeveloped in the target AWS account. AWS Elastic Disaster Recovery can also be used to migrate workloads.

Data migration from the source to the target can use multiple mechanisms depending on the resources that need to be migrated. AWS provides prescriptive guidance on replicating resources between AWS accounts. Additional guidance is also provided in the AWS Architecture Blog post Migrate Resources between AWS Accounts.

As recommended in the “Prepare workloads for migration” section of this post, use a discrete, descriptively named OU (such as Migrations) to test the migration of workloads. Deploy the workloads in the target AWS account under the Migration OU and set up the appropriate network connectivity, DNS, security, and monitoring components.

Blue/green testing of your migrated workload can use the Amazon Route 53 service through DNS record updates by using a weighted routing. The weighted routing feature of Route 53 simplifies distributing traffic across multiple resources to test new application versions. By testing a small percentage of traffic, you can limit the impact and address any issues encountered. Refer to the AWS whitepaper on blue/green deployments for additional details. The following image shows the high-level architecture for blue/green testing using Amazon Route 53 weighted distribution.

Figure 2. Blue/green testing using Amazon Route 53 weighted distribution.

Once the workload has been fully tested, the AWS account can be moved to the appropriate AWS Organizations OU, allowing all the applicable governance guardrails, security, and compliance controls to take effect.

Conclusion

In this post, we’ve shown how public sector customers can migrate to a multi-account architecture on AWS. This architecture helps public sector customers maintain security and compliance requirements and manage billing, enabling the ability to deploy emerging technologies. Engage your AWS account team or AWS Professional Services to learn more about migrating to a multi-account environment.