Migrating an AWS Account to a Control Tower OU
AWS Control Tower is an essential tool for organizations that want to maintain compliance with a single environment that has multiple accounts attached to it. While maintaining the flexibility and scalability that organizations on AWS will need, everything is contained within the confines of a singular security boundary. Having multiple accounts tethered to a single environment can better help with the allocation of resources and billing purposes, allowing users to better understand which operations are expending certain resources.
Assessing the Account for Migration
Using Assessment Tools
AWS Organizations comes with an automated tool to severely cut down on the amount of time spent evaluating dependencies. This inspects all accounts for identity-based and resource-based policies of AWS Organization origin. It will present any findings on a web UI that will track the resources used in an AWS Organization and the number of active accounts that have dependencies. To make scans complete a bit faster, specific services, accounts, and regions can be scanned.
The process however is not as simple as the press of a button. The Assessment Tool does not verify that any underlying resource-based policies are still correct. It’s the account owners’ responsibility to verify policies work as intended before starting the migration, using existing services such as AWS Identity Access Manager and Access Analyser. Great care should be taken when reviewing condition policy elements and managers should avoid deleting conditions until they understand how it will impact account functionality.
Sharing Resource Access Management
Users will need to share resources using AWS Resource Access Management (RAM) to create a resource share. A resource share has a list of one or more AWS resources to be shared, a list of one or more principals to whom access to the resources is granted, and managed permissions for each type of resource that is included in the share. After creating a resource share, the principals specified in the resource share can be granted access to the share’s resources. An organization can share resources with accounts both inside and outside the organization, but accounts from within will receive those permissions much sooner, which accounts get those resources is simpler to control, and external access will depend on if the resource type supports external access.
Sharing resources is done through the AWS RAM console or AWS Command Line Interface (CLI) to enable sharing with AWS Organizations. When sharing inside an organization, AWS RAM doesn’t send invitations to principals. Principals in the organization gain access to shared resources without exchanging invitations. When sharing resources with the entire organization or OUs is no longer necessary, it is as simple as disabling resource sharing.
Deploying CloudFormation Stacksets
CloudFormation will be how account holders will provide infrastructure as code to work with. A stack is a collection of AWS resources that you can manage as a single unit. A stackset lets users create a multi-regional stack for an AWS account using a single CloudFormation template with additional parameters and capabilities. Defining a stackset can allow for updating, creating, or deleting stacks within a specific region. Additionally, stackset permissions can either be self-managed or service-managed. Self-managed permissions allow for stacksets deployed across accounts and regions, necessary for trust purposes, whereas service-managed permissions automatically generate IAM roles automatically.
Assessing the Account for Migration
Using Assessment Tools
AWS Organizations comes with an automated tool to severely cut down on the amount of time spent evaluating dependencies. This inspects all accounts for identity-based and resource-based policies of AWS Organization origin. It will present any findings on a web UI that will track the resources used in an AWS Organization and the number of active accounts that have dependencies. To make scans complete a bit faster, specific services, accounts, and regions can be scanned.
The process however is not as simple as the press of a button. The Assessment Tool does not verify that any underlying resource-based policies are still correct. It’s the account owners’ responsibility to verify policies work as intended before starting the migration, using existing services such as AWS Identity Access Manager and Access Analyser. Great care should be taken when reviewing condition policy elements and managers should avoid deleting conditions until they understand how it will impact account functionality.
Sharing Resource Access Management
Users will need to share resources using AWS Resource Access Management (RAM) to create a resource share. A resource share has a list of one or more AWS resources to be shared, a list of one or more principals to whom access to the resources is granted, and managed permissions for each type of resource that is included in the share. After creating a resource share, the principals specified in the resource share can be granted access to the share’s resources. An organization can share resources with accounts both inside and outside the organization, but accounts from within will receive those permissions much sooner, which accounts get those resources is simpler to control, and external access will depend on if the resource type supports external access.
Sharing resources is done through the AWS RAM console or AWS Command Line Interface (CLI) to enable sharing with AWS Organizations. When sharing inside an organization, AWS RAM doesn’t send invitations to principals. Principals in the organization gain access to shared resources without exchanging invitations. When sharing resources with the entire organization or OUs is no longer necessary, it is as simple as disabling resource sharing.
Deploying CloudFormation Stacksets
CloudFormation will be how account holders will provide infrastructure as code to work with. A stack is a collection of AWS resources that you can manage as a single unit. A stackset lets users create a multi-regional stack for an AWS account using a single CloudFormation template with additional parameters and capabilities. Defining a stackset can allow for updating, creating, or deleting stacks within a specific region. Additionally, stackset permissions can either be self-managed or service-managed. Self-managed permissions allow for stacksets deployed across accounts and regions, necessary for trust purposes, whereas service-managed permissions automatically generate IAM roles automatically.
Preparing Corresponding Organizational Units
Organizational Units (OUs) are groups of clustered accounts that are tied together under a single peripheral to simplify changes made to the collection as a whole. During the evaluation process, users should be able to procure the existing OU name, parent name, all the necessary essential credential types and the parent type of the AWS accounts to the organization their accounts already belong to. These will be essential for replicating the OU in the new organization. It is crucial that any existing parameters and policies be 1:1 with any policies that the accounts are already adapted to.
The new OU in the destination organizational account will need the exact names and types of the account before. Afterward, it is a matter of creating a new OU with all the previous parameters established in the new location. In anticipation of the migration, make sure the destination account has payment methods in place and proper cost allocation already configured. This will require Cost Usage Reports (CURs), tax setting inheritance set to active, and Simple Storage Service (S3) buckets set to receive the CURs.
Preparing Corresponding Organizational Units
Organizational Units (OUs) are groups of clustered accounts that are tied together under a single peripheral to simplify changes made to the collection as a whole. During the evaluation process, users should be able to procure the existing OU name, parent name, all the necessary essential credential types and the parent type of the AWS accounts to the organization their accounts already belong to. These will be essential for replicating the OU in the new organization. It is crucial that any existing parameters and policies be 1:1 with any policies that the accounts are already adapted to.
The new OU in the destination organizational account will need the exact names and types of the account before. Afterward, it is a matter of creating a new OU with all the previous parameters established in the new location. In anticipation of the migration, make sure the destination account has payment methods in place and proper cost allocation already configured. This will require Cost Usage Reports (CURs), tax setting inheritance set to active, and Simple Storage Service (S3) buckets set to receive the CURs.
The Migration Process
Step 1: Move Everything Out
All accounts that will be moved will each need to receive invitations to the new OU. There are quotas for the maximum number of invitations allowed on an account, so this process will take a considerable amount of time. Each account that does receive an invitation must leave their previous organization first before accepting the invitation and will have fifteen days after receiving the invitation before it expires. Do not forget that in order for an account to be removed from an organization, it must have all the necessary data to function independently. When the invitation is accepted, the account will be placed at the root of the organization and must be implemented into the OU manually. Production developers will be moved to the new account’s Control Tower.
Step 2: Decommissioning and Clean Up
At this point, there is no reason to keep any older infrastructure. Deleting any old OUs can only be done once any accounts on it have been moved out. When deleting an organization, the previous management AWS account will be excised, the rest of the organization is discarded, and the account is now converted into a standalone account. Any policies remaining in the organization will be deleted with it. Prior to deleting an organization, be careful of closing any member accounts as doing so will place those accounts in a suspended status for up to three months, preventing the organization from being deleted.
Step 3: Continued Use of the Manager Account
After the manager account is removed, there is still plenty that can be done with it. Based on the users’ choice, it will be converted into a standalone account, used to create a new organization, or invited to the destination organization. Some services for the former manager’s account might be disabled because those services require an organization to work with. However, the account is no longer responsible for managing expenditures of AWS resources aside from its own. For the sake of this tutorial, the primary action will be the third option mentioned above.
Step 4: Invite the Former Manager Account
Make sure all previous steps are fully met first and that the monthly billing for the previous month is completed. Same as all the other accounts, invite the manager account in as a new member to the organization.
Step 1: Move Everything Out
All accounts that will be moved will each need to receive invitations to the new OU. There are quotas for the maximum number of invitations allowed on an account, so this process will take a considerable amount of time. Each account that does receive an invitation must leave their previous organization first before accepting the invitation and will have fifteen days after receiving the invitation before it expires. Do not forget that in order for an account to be removed from an organization, it must have all the necessary data to function independently. When the invitation is accepted, the account will be placed at the root of the organization and must be implemented into the OU manually. Production developers will be moved to the new account’s Control Tower.
Step 2: Decommissioning and Clean Up
At this point, there is no reason to keep any older infrastructure. Deleting any old OUs can only be done once any accounts on it have been moved out. When deleting an organization, the previous management AWS account will be excised, the rest of the organization is discarded, and the account is now converted into a standalone account. Any policies remaining in the organization will be deleted with it. Prior to deleting an organization, be careful of closing any member accounts as doing so will place those accounts in a suspended status for up to three months, preventing the organization from being deleted.
Step 3: Continued Use of the Manager Account
After the manager account is removed, there is still plenty that can be done with it. Based on the users’ choice, it will be converted into a standalone account, used to create a new organization, or invited to the destination organization. Some services for the former manager’s account might be disabled because those services require an organization to work with. However, the account is no longer responsible for managing expenditures of AWS resources aside from its own. For the sake of this tutorial, the primary action will be the third option mentioned above.
Step 4: Invite the Former Manager Account
Make sure all previous steps are fully met first and that the monthly billing for the previous month is completed. Same as all the other accounts, invite the manager account in as a new member to the organization.
Validation and Verification
All that is left is to make sure the protocols and policies still work in the new organization. Even if planning was done thoroughly in advance, now would be a good time to check that all procedures still work with the new accounts brought on board. Since all the accounts that were migrated are unorganized at the root, they will need to be manually sorted into the hierarchy of the new OU. Ideally, if all steps were taken to prepare and move all needed components to the new OU, everything should work upon completion of the migration.
Validation and Verification
All that is left is to make sure the protocols and policies still work in the new organization. Even if planning was done thoroughly in advance, now would be a good time to check that all procedures still work with the new accounts brought on board. Since all the accounts that were migrated are unorganized at the root, they will need to be manually sorted into the hierarchy of the new OU. Ideally, if all steps were taken to prepare and move all needed components to the new OU, everything should work upon completion of the migration.