Strategies for consolidating AWS environments

Organizations undergoing mergers and acquisitions (M&A) are looking for ways to simplify and standardize the governance of their AWS cloud environments. M&As can become complex as different IT departments between the acquirer and the acquiree attempt to merge and operate as a single entity.

Customers are increasingly using multiple accounts within an organization built and governed by services such as AWS Organizations and AWS Control Tower. They include a defined account structure, governance tools, and network/security configurations. These services make it easier to integrate separate organizations. However, customers are still looking for guidance to effectively merge and operate their AWS environments.

This post discusses approaches and considerations that organizations can utilize to decide on the appropriate strategy for merging their organizations.  We provide high-level guidance and critical considerations for merging AWS environments. Furthermore, this post points the audience toward a solution approach for consolidating AWS environments.

M&A complexity matrix

Customers have setup their multi account environment using the AWS recommended approach of using AWS Control Tower or natively using Organizations. Some customers have other bespoke environments using third-party infrastructure-as-code tools, such as Terraform, or they still use the earlier AWS Landing Zone solution. These different approaches adds complexities when organizations try to merge their AWS environments during M&A.

Merging cloud environments built using AWS Control Tower and Organizations is relatively straightforward as compared to merging environments which use custom solutions outside of the native AWS services. In that case, it requires additional considerations to make sure of a smooth transition when bringing together multiple organizations.. The following table shows the complexity level involved in consolidating the two environments based on their current state.

*Custom or deprecated AWS Landing Zone. If you want guidance on moving from AWS Landing Zone solution to AWS Control Tower, see Transitioning from AWS Landing Zone to AWS Control Tower guide for more details.

Key considerations before merging the two organizations

Organizations

Organizations is an account management service that lets you consolidate multiple AWS accounts into an organization that you create and centrally manage. AWS Control Tower is built on Organizations and other services (AWS Service Catalog, AWS Single Sign-on (SSO)) to automate and govern your multi-account environment. For example, using AWS Control Tower builds your organization and adds accounts using Organizations.

In the context of M&As, Organizations can assist you with transferring accounts to and from separate organizations. AWS accounts can detach from either the acquiree and attach themselves to the acquirer, or vice versa, depending on the use case. The acquirer or the acquiree can use their existing AWS Control Tower setup or create a new one to benefit from the security and governance guardrails.

Your organization’s management account is sometimes referred to as the payer account, as it’s responsible for paying all of the charges accrued by the member (linked) accounts. You can have only one management account in an organization. The management account within the acquirer organization can continue to be the management account in the new unified organization. The member accounts from one organization must leave and join the other organization in either case. Suppose you have a delegated administrator account for any of the AWS services. In that case, it must be released before leaving and joining the new organization.

Once all of the member accounts leave, the organization can be deleted. Afterward, the old management account can be deleted or moved to the new organization as a member account. For more information on deleting the organization, see Deleting the organization by removing the management account. For additional information and considerations on moving accounts between organizations, see How do I move accounts between organizations in AWS Organizations?

Suppose you plan on combining an organization managed via AWS Control Tower with another organization that has its own native governance model. In that case, you should consider which model you plan to use in the combined organization. This approach is particularly worthwhile because changes made in your organization will impact all of the accounts. After merging into a single organization, you can easily extend AWS Control Tower governance to other accounts. Alternatively, you can manage accounts in your environment natively using the underlying AWS services if you already have a custom governance model.

Service Control Policies (SCP)

Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all of the accounts in your organization. SCPs help you ensure that your accounts stay within your organization’s access control guidelines.

In the case of multiple organizations or landing zones, you must verify if there are requirements (regulatory or compliance) to align with different SCP sets. We recommend that you have consistent governance and compliance policies as much as possible. Suppose there’s a requirement to keep distinct governance structures and policies. In that case, it may make sense to use organizational units (OUs) to separate the two formerly separate organizations. This will let you attach SCPs in compliance with the organizational requirements.

Carefully review the Backup and Tagging policies for both the acquirer and the acquiree organizations to ensure that the accounts under the resulting organization have the appropriate access to the services.

Regions

Suppose you’re trying to combine two AWS Control Tower organizations from different Regions. In that case, you must decide which Region the merged/consolidated AWS Control Tower landing zone should be based. Next, decommission the other landing zone and add the accounts to the consolidated AWS Control Tower landing zone.

Identity Provider

AWS SSO is a cloud-based service that simplifies how you manage SSO access to AWS accounts and business applications. In AWS Control Tower, AWS SSO allows central cloud administrators and end-users to manage access to multiple AWS accounts and business applications.

Suppose you have multiple identity stores and identity federations. In that case, you must decide whether your organization wants to merge the identity stores or keep them separately. You can have only one directory or one SAML 2.0 identity provider connected to AWS SSO at any given time. However, you can change the identity source connected to a different one. Therefore, if you want to consolidate identities in a single identity source, you can configure AWS SSO accordingly. But if you’re going to keep two identity stores, you must have two organizations.

Suppose any AWS Identity and Access Management (IAM) policies or resources reference an organization ID. In that case, ensure that the policies are updated, or you must remove the org-based dependency if you plan to merge organizations.

Logging

The org trail stops functioning for member accounts when you leave one organization and join a new organization under AWS Control Tower. This situation is because AWS CloudTrail can’t access the previous organization. When you enroll an account in AWS Control Tower, your account is governed by the CloudTrail trail for the AWS Control Tower organization. The AWS Control Tower creates a logging account under the security (previously core) OU for the centralized CloudTrail and AWS Config logs. If you’re combining two organizations without AWS Control Tower, ensure that the org CloudTrail is turned on. All of the accounts brought into the environment store logs in a central location for your organization. Be mindful of cost implications while enabling any additional CloudTrail trails.

Moreover, determine the requirements for storing logs for the organization that will be merged. For example, suppose the need is to store the logs from the landing zone, which will be merged. In that case, you can do so by archiving the log files in a separate Amazon Simple Storage Service (Amazon S3) bucket, archiving the logs in Amazon Glacier, or storing the logs in a log management platform. If there are no requirements to keep the logs, you can delete them while merging the landing zones.

Suppose Amazon CloudWatch Metrics and Logs are streamed centrally to a subscriber. In that case, you must revisit the solution to align with the unified organization’s logging strategy.

Network

We recommend consolidating your network setup, such as DirectConnect connections, VPN connections, DX Gateways, and Transit Gateways (TGW). This approach will optimize the network architecture and save costs.

Identity and Access Management

You may have cross-account or service-linked roles across your organization. You can evaluate how to manage these roles after consolidation. You may not need to make any changes, as governance would extend automatically as you migrate accounts into the organization. The IAM Policy and AWS CloudFormation can have references (such as AWS:PrincipalOrgID) to the Organizations and OUs. These must be carefully reviewed and updated to reflect the new organizations.

Enterprise Agreements and Support Plans

Moving accounts between the acquiree and the acquirer may impact the AWS Enterprise Support Agreement. If you have multiple payer accounts, you must determine if you want to keep multiple payer accounts or consolidate payer accounts. Consider reducing multiple environments, payer accounts, and enterprise agreements. You may get better volume discounts, and you won’t pay for redundant enterprise support plans. Suppose you have any private pricing agreements or savings plans across different environments. In that case, you should work with your account teams to discuss any potential impact.

Billing History

Suppose you want to store the billing history of an acquiree payer account. In that case, you must manually save its billing history before moving the acquiree accounts to a new organization. Otherwise, the billing history disappears. You can download or print your previous bills as described.

Tax Registration Number and Business Legal Address

Ensure that you update the tax registration number and/or legal business address if they’ve changed post-merger by following the process mentioned.

Commercial and GovCloud Partitions

Suppose any of the organizations has AWS accounts across Commercial and GovCloud partitions. In that case, the organizations must operate as separate entities, and they can’t merge into a single organization.

Solution Overview

AWS Control Tower in both the acquirer and acquiree

High-level steps

1. Choose the management account after reviewing the critical considerations regarding merging the two Organizations. For this example, we consider that the acquiree joins the acquirer’s organization. Before you begin make a note of any networking or other shared services for the AWS accounts that you want to move, as these must be addressed to avoid service disruptions.
2. Suppose you created an account in Account Factory that you no longer want to have managed by AWS Control Tower in a landing zone. In that case, you can unmanage the account. Go to Service Catalog, and stop managing the member account from Account Factory (Service Catalog provisioned product).
3. Decommission the AWS Control Tower Landing Zone in the acquiree’s organization.
4. Move accounts by leaving the acquiree’s organization and joining the acquirer’s organization.
5. Enroll the moved accounts with the AWS Control Tower to enforce guardrails. Verify the acquirer’s guardrails to validate if the services in the acquiree’s organization continue to function correctly.
6. Migrate users, roles/groups, and business applications from the acquiree’s SSO Identity Provider to the acquirer’s SSO Identity Provider.
7. Consolidate CloudTrail, AWS Config, and CloudWatch Logs under the acquirer’s AWS Control Tower.

AWS Control Tower in either the acquirer or acquiree

High-level steps

1. Choose the management account after reviewing the critical considerations regarding merging the two Organizations. For this example, the acquirer joins the acquiree’s organization.
2. Move accounts by leaving the acquirer’s organization and joining the acquiree’s organization.
3. Enroll the moved accounts with the AWS Control Tower to enforce guardrails. Verify the acquiree’s guardrails to validate if the services in the acquiree’s organization continue to function correctly.
4. Migrate users, roles/groups, and business applications from the acquirer’s SSO Identity Provider to the acquiree’s SSO Identity Provider.
5. Consolidate CloudTrail, AWS Config, and CloudWatch Logs under the acquiree’s AWS Control Tower.

Unified environment

For the example in this post, the following diagram shows what the unified organization would look like after the merger. The account movement from one organization to the other also creates an opportunity to structure the accounts and organize them into OUs. These help manage and govern groups of accounts in an organization based on your use case.

AWS Control Tower now supports nested OUs. Nested OUs provide further customization between groups of accounts within OUs, which offers more flexibility when applying policies for different workloads or applications. This support for nested OUs lets you easily organize accounts in your AWS Control Tower environment into hierarchical, tree-like structures.

Conclusion

In this post, we provided approaches and considerations that organizations attempting to merge can consider based on the type of AWS environment and landing zone setup. There is much to consider when merging organizations. Still, ultimately the tools and mechanisms exist for you to do so once you align on these needs.

Engage with your AWS Account team for demo and guidance on AWS Control Tower to enable your organization to better manage and govern your environment. Moreover, refer to the organizing your AWS environment using multiple accounts whitepaper along with the pre-requisites & considerations for setting up AWS Control Tower.

Authors: