Building your multi-Account AWS Organization

In my previous article I explained why it makes sense for most companies using AWS to adopt a multi-Account AWS Organization. Doing so reduces risks related to security, performance, and deployment. I also described a strategy for how you can plan your set of Accounts.

In this article I’m going to carry on this story. You’ll learn:

• How to prepare building your Organization, including choosing whether to create new Accounts or move existing Accounts, and how to decide on root user email addresses.
• How to implement your Organization build-out, including the management Account and Organization; centralizing root user access; creating new member Accounts; and moving existing member Accounts.

Before you can start building out your Organization Accounts there are some things you need to prepare.

Preparation

AWS makes it easy to create Accounts - both for when you start a new Organization, and when you’re adding Accounts to an existing Organization.

However, when you’re either creating a new Organization, or standardizing or extending an existing Organization, there are some key things to prepare first. This will help you avoid a mess and wasted time in the future.

1. Understand whether you’re creating a new management Account, or repurposing an existing Account
2. Be aware of concerns with migrating or inviting existing Accounts to the Organization
3. Decide on a root user email address strategy
4. If you’re using an email alias / group as the target of the root user email addresses, make sure your own email account is subscribed to the alias
5. Know where you’re going to store passwords and MFA for the root user for your management Account
6. Have the best billing and contact details

Are you creating a new management Account?

Reminder: the management Account is the root of your Organization, and includes billing configuration and fundamental security policies.

If you’re about to embark on an Organization standardization exercise then there are quite a few different specific types of journey you might be taking on. But a key question to answer first is: are you creating a new Account to be the management Account of your target Organization, or are you repurposing an existing Account?

Part of my recommendation in the previous article was to minimize the amount of work that happens in a management Account, and run production workloads in member Accounts. There are various reasons for this, but the biggest is for security / role encapsulation. Just because someone may need admin privileges for a particular workload or resource type doesn’t mean they need the same privileges for the whole Organization.

Unless you already have a existing management Account that doesn’t have any production resources, then my typical advice here is to create a new management Account. You can then invite or migrate all of your existing Accounts to the new Organization. The reason for this recommendation is that it’s usually some effort to move production workloads across Accounts, especially if they have any amount of state.

I say “typical” advice here because it’s not always the best idea, since there are some considerations, which I’ll cover next.

Account Invitation / Migration considerations

If your company is creating their very first AWS Account then skip this section and move to the next

As part of this process you may be moving existing member Accounts from one Organization to another (known in AWS as migrating an Account), or you may be moving existing isolated / management Accounts into your Organization (known as inviting an Account). If so then you likely want to think about these points:

Don’t lose credits

It’s possible that before you perform this exercise that you have one or more AWS Accounts that have AWS credits. Many startups, growing companies, and even established companies that are building new products or redesigning workloads, usually have some amount of credits with AWS. Frequently those credits are actually useful - and can be worth thousands of dollars per month or more. You don’t want to lose them!

If you’re creating a new management Account, or changing any existing management Accounts / isolated Accounts into member Accounts of your Organization, then I recommend you first check in with your AWS account manager to give them the heads up that you want to transfer any credits you may have to the target Organization. Depending on what the specific credits are you may not need to do anything, but either way your account manager will at the very least want to know your new management Account’s numeric Account ID so they can join it up with your existing AWS relationship.

Be ready to temporarily give migrating member Accounts their own billing configuration

You may need to move existing member Accounts (without their own billing configuration) from one Organization to your target Organization. I’m going to explain later in this article how to do that, but one thing to understand as you plan this exercise is that any such member Account will temporarily need to be it’s own isolated Account, with billing configuration. It’s only going to be for a short time (hopefully less than a day) but still, it’s a thing to be aware of, and you likely want to discuss with your finance team first as you make preparations.

If you have some standalone Accounts that you’re moving into the Organization then they already have billing Configuration, and so their process will be more simple.

Prepare any configuration changes if you’re already using Organization features

My guess if you’re reading this article is that you’re probably not already using any Organization features beyond shared billing, and if you are that you’re not going to make any significant structural changes. However, just in case…

Once you start using AWS Organizations to their fullest you will use Organization-based configuration in various places. A simple case is for IAM Roles for CI/CD servers - e.g. you can configure an Organization-scoped role for GitHub Actions.

If you’re migrating Accounts to a new Organization, and if you’re already using Organization features beyond billing, then you’ll need to plan how to also migrate related resources, and change configuration. AWS have a three-part blog series on migrating Accounts here, and so in the case where you’re doing some fairly major Organization surgery you may want to scan those articles first.

Picking your root user email addresses

When you create any AWS Account - management or member - you must provide an email address to associate with the root user of the Account. While this may sound simple there are a few gotchas:

• Every AWS Account must have its own unique root user email address, so if you’re creating 5 Accounts, you’re going to need 5 different email addresses. Note that this uniqueness constraint applies within all of AWS, not just within an Organization.
• Account notifications for each Account are sent to the root user’s email - if you want to get your invoices, support alerts, and deprecation alerts then you need to have those notifications sent to an email address you can actually read.
• Password changes for the root user use the root user’s email - similar to the previous point, you need to use an email address you can actually access.
• The root user is the most sensitive, and last resort, access to the Account - which means that you need to think about whose email is actually associated with the Account.

Eventually you’re could well end up with 10 or more Accounts in your Organization, so I recommend that you define a strategy for how you assign email addresses to AWS root users. Here’s what I usually recommend:

1. Use subaddressing / plus-addressing to differentiate multiple AWS Accounts to the one email account / group. In other words, AWS sees user+sheep@example.com and user+cheese@example.com as unique email addresses, but when you use plus-addressing then email to these addresses actually go to the same email account - user@example.com. Most mainstream email servers and services support this behavior, but sometimes you’ll need to have it specifically enabled. This solves the problem of requiring unique email addresses, while not having a proliferation of email accounts or aliases.
2. Always use a group account / alias, rather than an individual account, for the actual target email account. While it’s tempting for me just to use mike+widgetprod@example.com as an email address because it’s easy to use, it means no-one else has access to notifications, and if I’m unavailable no-one can access the root user in emergencies.

For example, say your company is example.com, and your first workload is named Widget. I recommend creating the following Accounts, with something like the associated email addresses:

1. Management Account - aws+management-account@example.com
2. Org Ops Account - aws+org-ops@example.com
3. Widget production Account - aws+widget-prod@example.com
4. Widget test Account - aws+widget-test@example.com

This may all sound obvious, and simple, but when I’ve worked with companies in the past on this kind of thing there’s usually some kind of delay for the IT team to get everything set up on the email side of things.

Make sure you’re subscribed to the root user email

When you create the Account, AWS is going to send an email to the root user’s email address. This may also sound obvious, but make sure you can see emails sent to that address! More than once in the past I’ve been confidently informed that, yes, I will now receive emails sent to abc+xyz@example.com … and it turns out not to be the case. So when I use an email alias for the first time I always send a test email to the address I’m going to use for the root user to make sure I can actually see what is sent there.

Root user password and MFA management

Eventually you’re going to configure human user management for your Organization, at which point you will very rarely need to login with a root user. However it’s still worth having a good process for password management for the root user. Further - AWS now require MFA for the root user of the Organization Management Account, so you’ll need some way of setting up MFA that can be used by other people later.

Companies usually use something like 1Password with “shared vaults” for this kind of thing, and I recommend you do similarly.

Note that you’re only required to have a password and MFA for the root user of the management Account; for member Accounts you can use the Centralize root access for member Accounts feature, which I’ll explain later.

Billing and contact details

When companies kick the tires on AWS they usually just grab a “senior person”’s corporate credit card and use that. I’ve come across startup CTOs using their personal credit card for years, expensing the AWS bills, and having enough airline miles so that they don’t have to pay for their own personal flights!

But usually if you’re going to the effort of setting up an Organization properly then it makes sense to get your Finance team involved and use the best credit card for them.

Also, the management Account of each Organization has various contact details - geographical addresses, phone numbers, etc. You can always change these later but it’s important to have at least one phone number that’s going to actually connect to a company employee, in case of last resort access problems.

The other reason to get billing details is for if you’re migrating any existing member Accounts to a new Organization, as I mentioned earlier.

Implementation

With all the preparation steps complete, you can now start the fun part - defining your Organization and Accounts. The steps are:

1. Create or update an existing management Account
2. Initialize the Organization
3. Centralize root user access
4. Create new member Accounts
5. Invite / migrate existing member Accounts
6. Initialize member Accounts

AWS provide a service and tooling - Control Tower - for managing your entire organization operations, including managing Accounts. I don’t personally use Control Tower, although I know some companies get value from it. To me it starts from a blueprint that’s too complicated for many smaller companies, while at the same time not offering as much flexibility in ways I like. Further - the last time I used Control Tower it proved impossible to completely cleanup from an Organization when I no longer wanted it.

If you’re thinking of using Control Tower I recommend you try it in an entirely clean and unused test management Account / Organization first, so that if you end up not wanting to use it you don’t have any remnants of your test cluttering up your Accounts.

Creating your management Account

If you’ve already created the Account that you’re going to use as the management Account of your Organization then skip to the next step

To create a new management Account you must use the AWS Web Console - the CLI alone is not sufficient. Usually you’re going to do this here , but refer to this support page for specific directions. E.g. at time of writing if you’re in India you’ll need to use a different page.

After going to the Console home page you’ll see a prominent Create Account button which will guide you through the process. Be ready to provide the following:

• Account Name - by default use Management Account, or anything else you want to use. This can be easily changed later.
• Root user email address, billing details, and contact details - as you should have prepared already based on the earlier sections.

You will also need to verify the email address, create a password, and various other things (like picking an initial support plan).

Once you’ve completed the process then make sure to login in a fresh browser session to make sure the password you’ve stored in your password repository is correct. AWS will also require you to configure MFA at this time if you didn’t already.

Updating an existing management Account

If you created a new management Account in the previous step, then skip this step

If you already have a management Account or isolated Account that you want to use as the management Account for your Organization, then there are few things you can do to standardize your Account settings:

• Update the root user email address. The management Account root user’s email address can be updated, and I recommend doing so if your current address is different to that which you planned in the Preparation phase. You’ll need to be able to see emails sent to the old and new email addresses in order to make this change.
• Update and store password. If you don’t already have the root user’s password stored in a shared password repository then do so
• Set MFA on root user. AWS only recently made MFA for root users a requirement, so if your existing management Account is older than that change you may not yet have MFA. If you don’t then I strongly recommend adding MFA.
• Update billing / contact details. If necessary then update the billing and/or contact details as I described in the Preparation phase. Make sure when doing this that the Account’s phone number contact is correct.
• Update Account Name. This is optional, but if the Account name isn’t already something like Management Account then I recommend you change it to be more appropriate.

Initialize Organization

If you’ve already initialized an Organization in your management Account then skip this step

Strictly speaking you don’t actually have an AWS Organization until you’ve initialized it in the web console. If you haven’t already done so, then:

• In the AWS web console, log into the management Account as an administrator (either the root user, or another administrative user if you already have one of those).
• Go to the AWS Organizations console
• Follow the workflow for Create an Organization.

Centralize root user access

This is optional, but I recommend it

Up until late 2024 you needed to manage the root user credentials (password, MFA) for not just your management Account, but also all of the member Accounts in an Organization. Once your Organization is fully setup with useful human user management then it’s going to be very rare that you’ll need to actually use the root user credentials, and for your application workload Accounts you might never need them. Therefore the requirement to manage root user credentials is unnecessary extra work, and an unnecessary security risk.

Fortunately AWS now allows you to centralize root user access - meaning that only the management Account’s root user needs credentials that you need to store.

When you enable centralized root user access:

• Member Accounts that you create from now on won’t have credentials for their own root users
• You can delete credentials for the root users for existing member Accounts
• You can always get root access to a member Account later if you really need it

To make this change:

1. If you’re updating an active Organization make sure no-one is actually using the root user in any member Accounts!
2. Log into the management Account in the AWS Web console as an administrator-level user (either the Account’s own root user, or your own admin user if you already have one)
3. Go to the IAM console
4. In the navigation pane of the console, choose Root access management, and then select Enable. Enable both Root credentials management and Privileged root actions in member Accounts . For now ignore the Delegate administrator option. Choose Enable again.
5. If you already have member Accounts you should now see them under the Root access management page. From each Account you should be able to see if they have Root user credentials and if they do you can delete the credentials.

Create new member Accounts

Pretty soon you’re going to want to create your member Accounts. I recommend you at least create your “org ops” Account at this time.

You can do this using the Web Console, the CLI, or via the API / Infrastructure-as-Code.

Whichever method you pick you’ll have the option to specify an IAM role name for Organizations to use when creating the Account. Unless you have specific requirements just let it use the default value.

Using the Web Console

1. Log into the management Account in the AWS Web console as an administrator-level user (either the Account’s own root user, or your own admin user if you already have one)
2. Go to the AWS Organizations console
3. From the AWS Accounts page, choose Add an AWS Account
4. Enter the Account Name (you can change this later), and also the root user email address as you planned in the Preparation phase.
5. All other configuration is optional
6. Press ‘Create AWS Account’ to execute the change

Using the CLI

Once you get to the point where you’ve configured the AWS CLI (and I’ll describe doing so in a later article) you can easily create a member Account.

1. Make sure your AWS CLI configuration is using the management Account, and you have Administrator permissions
2. Run this command: aws organizations create-account --account-name ACCOUNT_NAME --email ROOT_USER_EMAIL
   • ACCOUNT_NAME should be something useful, which you can change later.
   • ROOT_USER_EMAIL should be as you planned in the Preparation phase

Using Infrastructure-as-Code

You can also manage Accounts using Infrastructure-as-Code (IaC) … kind of. E.g. the AWS Account CloudFormation Resource let’s you create Accounts in an existing Organization. However you can’t later modify the Account Name or root user email address using the same CloudFormation template. Which makes it much less useful.

Once you have IaC managing your Organization resources it probably makes sense for you to use it for creating Accounts, but it’s a far less valuable option than most IaC cases.

Invite and migrate existing Accounts to the Organization

You may have a number of existing Accounts that you want to move into your Organization. There are a few different scenarios here.

In all cases you’ll need administrative access to the target management Account, and to the Account being moved.

Inviting a standalone Account to an Organization

If you already have a standalone Account (one that has its own billing configuration, and has no Organization configured), you can invite the Account to the Organization. To do this:

1. Log into the management Account in the AWS Web console as an administrator-level user (either the Account’s own root user, or your own admin user if you already have one)
2. Go to the AWS Organizations console
3. From the AWS Accounts / Invitations page, choose Invite AWS Account
4. Enter the root user email addresses, or Account IDs, of all of the standalone Accounts you’d like to move to the Organization
5. For each Account being invited:
   1. Log in to the Account as in the AWS Web console as an administrator-level user (either the Account’s own root user, or your own admin user if you already have one)
   2. Go here
   3. Accept the invitation

Migrating an existing member Account to a different Organization

If you’re creating a new Organization, or consolidating multiple Organizations, you will likely want to migrate existing member Accounts from old Organizations to the target Organization. This is a more complicated process. For each Account to be migrated:

1. Perform steps 1 through 4 of the Inviting a standalone Account to an Organization process above
2. Login to the Account to be migrated in the AWS Web console as an administrator-level user (either the Account’s own root user, or your own admin user if you already have one)
3. Go to the AWS Organizations console
4. Choose Leave this Organization
5. Follow all of the workflow to assign temporary billing and contact configuration, and confirm the Account has left its previous Organization
6. Then follow step 5 of the Inviting a standalone Account to an Organization process above

As I mentioned earlier, this will result in a short period of time (less than one day if all goes to plan) where each migrated member account will be responsible for its own billing, and a bill will be sent at the end of the month for each migrated account. So make sure your finance team are aware.

This process is documented more thoroughly by AWS here.

Migrating an existing management Account to a different Organization as a member Account

If merging two Organizations you might want to move an existing management Account to a new Organization as a member Account, but first check this is strictly necessary - e.g. if the management Account to be moved has very little in it then it might make sense just to close it.

This scenario is most often the case when you have a management Account with production application workloads already active, but you want to change to the Organization strategy I’ve outlined in these two articles.

If you want to perform this process then do the following:

1. First, either migrate or close any/all member Accounts in the Organization of the management Account you’re migrating
2. Login to the management Account to be migrated in the AWS Web console as an administrator-level user (either the Account’s own root user, or your own admin user if you already have one)
3. Go to the AWS Organizations console
4. From Settings choose Delete Organization
5. At this point the Account is a standalone Account, and you can follow the Inviting a standalone Account to an Organization process above

Initialize member Accounts

For any Accounts that you have moved into the Organization, you will want to perform a few steps immediately, for each moved Account:

• Update the root user email address. If the root email address is not yet as you planned in the Preparation phase, then update it. You’ll need to be able to see emails sent to the old and new email addresses in order to make this change.
• Update Account Name. This is optional, but change the Account name if it’s no longer correct (e.g. if an old management Account is now a workload member Account)
• Remove root user credentials. If you performed the Centralize root user access step above, then remove root user access for the moved Accounts. You do this from the Organization management Account - in the IAM Web Console, choose Root access management and you should be able to see the Accounts you have moved

For all member Accounts you’ll also want to configure any Organization-scope services and policies, if you already have any configured. I haven’t got onto those yet in this series though, so for now we’ll leave things there!

Next steps

You now have an AWS Organization with multiple Accounts. Next up is to start using the features of AWS Organizations. So in the next article I explain how to use AWS Identity Centre to provide human user management across the Organization.

Summary

In this article I explained how to realize your plan for your multi-Account Organization. Whether you’re starting from scratch, or already had various existing Accounts, you now have a standardized, secured, top-level AWS structure to work from.

You have a minimal management Account, and a set of member Accounts tasked for one type of role. You’ve also configured your root user email addresses and credentials to last into the future. All of your Accounts are billed to AWS through one channel.

Feedback + Questions

If you have any feedback or questions then feel free to email me at mike@symphonia.io, or contact me at @mikebroberts@hachyderm.io on Mastodon, or at @mikebroberts.com on BlueSky.