Migrating accounts between AWS Organizations with consolidated billing to all features

AWS Feed
Migrating accounts between AWS Organizations with consolidated billing to all features

Customers start their cloud journey with one AWS account, and over time they deploy many resources within it before utilizing more accounts. Prior to the launch of AWS Organizations in 2017, customers received a consolidated bill for all of these accounts. The launch of AWS Organizations meant these customers were provided with an organization that had a limited ‘Consolidated Billing’ feature set, as well as an optional ‘All features’ feature set. When you enable “all features” in your organizations, you can benefit from the advanced account management features available in AWS Organizations, such as integration with supported AWS services and organization management policies. When you create a new organization, it is created in all features by default, as it is the preferred way to work with AWS Organizations. Learn more about the feature sets in the documentation for AWS Organizations.

Many customers who have been utilizing organizations with consolidated billing have deployed resources in order to support workloads in their management accounts. If there are any resources in the management account of your organization, then we recommend that you migrate them to a member account within the organization. If the resources cannot be migrated between the accounts without disruption, then we recommend you move the existing management account to a new organization as a member account. This requires a full migration of every AWS account from the existing organization to the new one. The main reason for isolating the management account is to improve your organization security by limiting the management account usage for administrative actions and users only.

Solution overview

If your organization is only configured with consolidated billing, and you cannot move your workloads from the management account to a member account without disruption, then this post outlines the steps for migrating accounts to a new organization that has all features. Before you implement the steps, we recommend you review the considerations and prerequisites below.

Considerations

If you have a consolidated billing organization without any resources supporting workloads in your management account, and you want to utilize the advanced account management features from AWS Organizations, then you can enable all features in your existing organization. Learn more about this process in the AWS Organizations documentation.

However, if you have a consolidated billing organization containing resources supporting workloads in the management account, then we recommend you follow the steps outlined in this post and migrate to a new organization with all features enabled.

Many of the steps from this blog also apply to a migration between two organizations that are already enabled with all features. However, it requires more assessment from the existing organization, such as applied policies or AWS services activated across accounts in order to ensure that there is no disruption during the migration process. We do not provide steps regarding those dependencies in this post.

Prerequisites

Ensure that the following steps are completed for a safe migration of accounts.

• AWS accounts require a valid payment method before leaving an organization. The easiest way to manage this across multiple accounts in an organization is to ensure that the payment method of each account (including the management account) is set to Invoice.
  • To change the payment method to invoice for an account, create a support case with the following information from the management account:
    • AWS Account number, Company Name, Contact Name, Contact Phone, Contact Email, Address, City, State or Province, Zip, and Country.
• AWS CLI can be utilized to list all accounts in an organization by using the ListAccounts API. This information must be provided for every account that the customer wants to change the payment method to invoice. If a support case is to be opened for multiple accounts, then list every account number and outline the information above in order to change the payment method to invoice.
• If you have savings plans, reserved instances (RIs), or enterprise agreements, then we recommend working with your account manager to determine if there are any additional programs that your accounts/organization can utilize to leverage the existing pricing discounts applied to the new organization during the migration.

Architecture

Figure 1: Architecture diagram

Steps for Migration

Step 1: Assess your current environment in order to identify organization conditions in identity and resource-based policies. This will help you come up with a list of remediations for resources before migrating to the new organization.

Consider the follow in order to assess the AWS accounts to be migrated from the existing organization to the new organization:

1. Analyze the AWS services that are utilized in every AWS Account in the organization.

For every AWS resource supporting resource-based policies,

• • Check for organization conditions in the policies that can have global condition context keys and values specific to an organization, such as aws:PrincipalOrgID and aws:PrincipalOrgPaths.
  • AWS resources with organization conditions in the resource-based policies would require remediation in the new organization. To better understand this, let’s take an example of an Amazon S3 bucket that has an S3 bucket policy allowing access to the resources in the existing organization with organization ID o-1234xxxxxxx.

{ "Version": "2012-10-17", "Statement": { "Sid": "AllowPutObject", "Effect": "Allow", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::policy-dev/*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": [ "o-abx1341cy0" ] } } }
}

• • When this S3 bucket moves to the new organization, this S3 bucket policy must be updated to allow access to resources in the new organization with the organization ID as o-abx1341cy0. Similarly, there can be other AWS resources, such as Amazon SNS topics or Amazon SQS queues, with resource policies that have organization conditions in the policies. These must be remediated so that the resources don’t lose the access as required.

2. Check for the usage of AWS global condition context keys (aws:PrincipalOrgID and aws:PrincipalOrgPaths) in the AWS IAM roles and IAM policies of all accounts in the organization.
3. Check for any AWS Lambda functions making AWS Organizations API calls. These functions would become erroneous since the AWS Lambda functions can make Organizations API calls only in the organization management account.
4. Check for AWS CloudFormation Stack Policies if the global condition context keys aws:PrincipalOrgID and aws:PrincipalOrgPaths are present.
5. Check for AWS Organizations API calls made in AWS CloudTrail logs. Utilize Amazon Athena to query AWS CloudTrail logs. Create or utilize an existing Athena table of organization trail with partitions like account, region, year, month. Execute queries for the last three months, and generate reports to analyze if any calls have been made to organization API calls.

Overall, the assessment will provide the following:

• Resource-based policies to be remediated with the new aws:PrincipalOrgID and aws:PrincipalOrgPaths in the new organization.
• Any other resources like AWS IAM policies and AWS CloudFormation Stack policies must be remediated with the new aws:PrincipalOrgID and aws:PrincipalOrgPaths in the new organization.
• Any AWS Lambda functions that will need to move to the new management account in the new organization.
• Any potential impact from the AWS CloudTrail log analysis report must be remediated.
• Now you can identify organizational dependencies between the accounts in an organization before they are moved to the new organization.

Step 2: Review the existing organization and save the following details:

• Root Id of the organization
• For every Organizational Unit (OU)
  • OU Name
  • OU Parent Name
  • OU Parent Type
    • “ROOT” for the OUs immediately under the root of the organization
    • “ORGANIZATIONAL_UNIT” for the OUs that are part of another OU (also known as nested OUs)
  • For every AWS account in the existing organization
    • Account Id
    • Account Name
    • Account Email
    • Account Parent Name
    • Account Parent Type
      • “ROOT” for the management account and the accounts that are not part of any OU
      • “ORGANIZATIONAL_UNIT” for accounts that are part of an OU

These will be utilized after the migration to ensure that the new organization structure reflects your existing organization. Note that if you are migrating to a new organization and intend to utilize a new OU structure, then you can learn more about our recommended best practices for OUs and accounts.

Step 3: Create a new AWS account within you existing organization.

1. Ensure that the payment method for the newly created AWS account is set to invoice. If not, then follow the steps in the prerequisites in order to set the payment method to invoice.
2. Once the payment method is set to invoice, it can be removed from the existing organization.

Step 4: After the newly created AWS account leaves the existing organization, create an organization in that account utilizing AWS Organizations with “all features”. Now, the newly created AWS account becomes the management account of the new organization.

1. Verify the email address for the management account. AWS Organizations requires email address verification in order to invite accounts to an organization.
2. Create Cost and Usage Reports (CUR) to get the most comprehensive set of cost and usage data.
3. Activate User-Defined and AWS-Generated cost allocation tags in order to organize your resource costs on your cost allocation report, as well as to make it easier for you to categorize and track your AWS costs.
   • Retrieve existing cost allocation tag keys that are approved on the existing management account.
   • Apply this list of tag keys with null value to the S3 bucket storing the CUR data within the new management account.
   • It can take up to 24 hours to propagate these tags into the approval list.
4. Turn on tax setting inheritance in order to add your tax registration information to other AWS Organizations accounts.
5. To retain the Cost and Usage Reports (CUR) from the existing organization, copy the CUR files to the new organization by replicating from the source Amazon Simple Storage Service (Amazon S3) bucket in the management account of the existing organization to an Amazon S3 bucket in the management account of the new organization. Instructions to set up rules to replicate objects between buckets.
   Note: Once you remove the organization from the existing management account, you will lose access to your billing history via Cost Explorer, and CUR files stored in the S3 bucket will be retained.
6. Now your new organization is ready to invite and accept member accounts.

Step 5: Migrate accounts from the existing organization to the new organization.

1. Create OU Structure: Utilize the OU names, respective parent names, and types from Step 2 in order to replicate the OU structure in the new organization.
2. Send Invitations to the member accounts: Utilize the Account Id or Account Email from Step 2 in order to invite every member account from the existing organization to join the new organization. Please review the service quotas for the maximum number of invitations allowed in your organization.
3. Member accounts leave the existing organization and accept invitations: Each member account must leave the existing organization before accepting the invitation to join the new organization.
   1. Once the invitation is accepted from each account individually, all of the activity of each member account is billed to the new management account.
   2. Invitations have up to 15 days to respond before they expire.
4. Move Accounts: By default, when a member account accepts the invitation from the new organization, the account will be placed under the root of the organization and not automatically moved to an OU.
   1. Move the accounts to the appropriate OUs by using the OU structure of accounts captured in Step 2 from your existing organization.

Step 6: Move the Management Account from the existing organization to the new organization.

1. Before moving the management account, ensure that
   1. All of the member accounts have been successfully migrated.
   2. The month-end billing process is completed.
   3. The existing organization has been deleted.
2. Utilize the Account Id or Account Email of the management account from Step 2 to invite the management account to join the new organization.
3. Accept the invitation to join the new organization. After this step, the management account of the existing organization becomes a member account of the new organization.

• If you apply policies to the new organization, then you can avoid interruptions for the applications running in the management account of the existing organization by creating a transitional OU without any policies applied to it, then move the account into that OU.

Conclusion

We recommend that you do not run any workloads in your management account. In the event that you do have workloads running in your management account, and you require a migration to a new organization, this post has provided detailed steps to assess the state of your existing consolidated billing only organization and its dependencies, as well as how to migrate accounts to a new all features enabled organization. This solution can be utilized when you have resources running in your management account, which cannot be migrated to other member accounts of your existing organization without disruption.

About the authors