Setting up AWS Control Tower with existing production account as 'management' account

Hi friends

We have a single existing aws account which we are using for our production workload. Now we are in the process of scaling and require a new aws account for our test workload.

We want to setup AWS Control Tower to help us manage our organisation and AWS accounts. This would involve setting up AWS Control Tower via our existing account.

Are there any downside to having the management account in AWS Control Tower be the existng account we have been using and will continue to use for production?

We already have AWS Identity Centre setup in this existing account, if we were to have a separate management account, i think that would involve us having to recreate all of our identity resources inside the management account.

What I would recommend is to create a new management account, set up the Organizations/Control Tower in there, and then invite your existing prod account and create the test account. That way you don’t have anything other than management activities running in your management account (which is what you want)

ye that makes sense to me, but what if we already these AWS services setup such as AWS Identity Centre which need to be attached to the management account?

If i understand correctly, the AWS Identity Centre users can be replicated to multiple aws accounts via the aws management account. Which is what we want

as an aside to this, are there a list of top level services that ought to be created in the management account (we might be using other services already, good to know what we might need to migrate over)?

Avoid deploying workload to AWS management account

Is it even possible to like you said invite our existing prod account (which has the management label under the root aws organisation) under control of a new aws account with aws control tower? would there not be conflicts of services like aws identity centre?

If you're moving the management account of an organization, then you must delete the organization and make the management account a standalone account. When you've removed all of the member accounts, follow the approach for deleting the organization from the Organizations User Guide.

Before you remove the management account, capture any cost allocation tags that you may have configured to track your AWS costs on a detailed level. In the target organization, apply and activate any AWS generated and user-defined cost allocation tags. Consider that all tags can take up to 24 hours to appear in the Billing and Cost Management console.```


```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.```


For what other resources to include in the management account, you could check out the Landing Zone Accelerator implementation guid

If you wanted to migrate your SSO setup, you could use CLI to list and describe your existing rules and groups so they’re easy to recreate in the new management account. It looks like the url might change (unless you want to use a custom one maybe?). SSO does propagate to the managed accounts.

What do you mean by SSO does propagate to the managed accounts.?

When you set up SSO in your management account, then you can use it to manage SSO access for all managed accounts in that organization

Right ye thats waht ive read also

From what im reading here and i could be wrong, once you disassociate an AWS Account from an existing aws organisation. the AWS Identity Centre will not work.

If you have enabled trusted access for AWS IAM Identity Center (successor to AWS Single Sign-On), you can pick multiple AWS accounts whose users need single sign-on (SSO) access AWS accounts and cloud applications. When an account leaves the organization, IAM Identity Center will no longer, enumerate the account, or be able to deploy common sets of permissions, and manage access from the management or a delegated administrator account. IAM Identity Center automatically cleans up the account of any metadata and resources, including the IAM Identity Center service-linked role. The account no longer works with IAM Identity Center and you can no longer access the account using the AWS Access Portal for any configured identity source.

When an account joins the target organization, you will need to configure required permissions or assignments to users and groups in IAM Identity Center for the account.```

Which means i will have to have AWS Identity centre recreated under the new management account before doing this

Then hopefully i can dissociate and associate with the new account and apply the propagation?

Your current prod account, you’re not managing any other accounts through it already are you?

No We just have 1 prod account with an aws identity centre setup

Ok that’s good lol that makes it a little easier :slightly_smiling_face: