Help, I've got resources in the management account of my AWS Organization!

Blog Post

At Lambert Labs we advise a lot of different AWS customers across a variety of different industries and geographies on how to get the most out of their AWS infrastructure from a range of perspectives, including security, reliability and cost optimization.

The majority of the bigger AWS customers that we work with already have an AWS Organization structured in a secure and scalable fashion. However, we have also come across a lot of AWS customers of all shapes and sizes who either:

  • Don’t yet have an AWS Organization; or
  • Have lots of infrastructure in the management account (the top level account) of their AWS Organization.

In this blog post we are going to focus on the latter scenario, where you already have infrastructure in the management account of your AWS Organization. If you are in this position this means that unfortunately, you have technical debt. We will explore some options for how to best move forward from this position.

AWS Organizations: the absolute basics

First, let’s cover some basic principles about AWS accounts and AWS Organizations.

When you first sign up for/create an AWS account, it is what we call a standalone AWS account; an AWS account that is not part of an AWS Organization. Some users at a later stage convert their standalone AWS account into an AWS Organization at which point the standalone AWS account becomes the management account of the AWS Organization.

At this point, we should stress the importance of the following two excerpts from the best practices for the management account section of the AWS documentation:

  1. Use the management account only for tasks that require the management account: we recommend that you use the management account and its users and roles for tasks that must be performed only by that account. Store all of your AWS resources in other AWS accounts in the organization and keep them out of the management account.
  1. Avoid deploying workloads to the organization’s management account: privileged operations can be performed within an organization’s management account, and SCPs do not apply to the management account. That’s why you should limit the cloud resources and data contained in the management account to only those that must be managed in the management account.

Essentially, it is best practice to never create any infrastructure in the management account of your AWS Organization. A very simple example of a just-about-acceptable AWS Organization would be to have three accounts made up of a shell/empty management account and two linked/child accounts – one for production infrastructure and one for staging infrastructure.

You can double-check whether you have an AWS Organization by going to the AWS Organizations service in the AWS management console.

If you see a button to ‘Create an organization’ this means that you don’t have an AWS Organization.

But hold fire, don’t create an AWS Organization yet. We suggest that you read to the end of this article before making any decisions.

If, however, you see something like the following, then this means that you are currently in the management account of your AWS Organization:

The AWS Organization in the screenshot above has two AWS accounts, the management account and a child/linked account. The management account is indicated by the ‘management account’ badge and in this example we’ve obfuscated account details for obvious reasons. It is possible that you have a single account AWS Organization where your only AWS account in the AWS Organization is the management account. 

The final possibility is that when you visit the AWS Organizations service you are prompted with the following:

This means that the AWS account that you are logged into is part of an AWS Organization and it is a child account. The management account email address and management account ID will be shown on screen in addition to the Organization ID. Hopefully you recognize the management account email address!

What are the drawbacks of having infrastructure in the management account of my AWS Organization?

These include….

  • Increased security risk. The management account in an AWS Organization holds the highest level of permissions and is responsible for managing the entire organization, including service control policies, account creation, and billing. Deploying infrastructure in this account increases the attack surface. If this account is compromised, an attacker could gain access to sensitive data and control over all member accounts.
  • Operational overhead. The management account already has administrative duties like billing, governance, and organizational management. Adding operational infrastructure increases the complexity and operational overhead of the account, which could slow down responses to both infrastructure and management-related issues.
  • Billing complexity. Having both management and infrastructure resources in the same account complicates the visibility and breakdown of costs. You may find it difficult to attribute specific costs to either administrative activities or operational workloads, which could make budget management and cost optimization more challenging.

Why do I have infrastructure in the management account of my AWS Organization?

We can’t really answer this one for you! However, what we would say is the following:

  • There are multiple places inside the AWS management console that point you in the direction of converting your standalone AWS account into an AWS Organization, even if you have lots of infrastructure in your standalone AWS account already. For example, currently, when you create an IAM user you are encouraged to set up AWS IAM Identity Center, which in turn gives you the option to convert your standalone AWS account into an AWS Organization. This particular IAM/IAM Identity Center pathway, we guesstimate, creates a lot of technical debt across AWS’ millions of customer accounts…..

What are my best options moving forwards?

In our opinion, there are 3 realistic options here:

  1. Move the resources to another account in your AWS Organization.
  2. Restructure your AWS Organization.
  3. Leave things as they are.

We dive into each option in a bit more detail below:


1. Move the resources to another account in your AWS Organization

This option effectively involves migrating your resources from the management account to a child/linked account. If the infrastructure inside your management account is 100% templated using eg Terraform or CloudFormation then this might be just about palatable, but if your infrastructure isn’t templated then this will be more complicated.

Pros:

  • It might create an opportunity for infrastructure modernization at the point of performing the migration. 

Cons:

  • It might be hard to migrate without scheduled application/infrastructure downtime.
  • Could be lots of time/work/resource.

2. Restructure your AWS Organization

If you aren’t making use of many/any AWS Organization-level services, then it is possible to entirely dismantle your AWS Organization and then rebuild it with a new, empty management account at the top. This is a pretty nuclear option so proceed with extreme caution. The steps to take are:

(a) Safely remove each child/linked account from your AWS Organization. To do this, you need to visit the AWS Organizations service and click ‘Leave this Organization’. The key word here is ‘Safely’, so you need to be absolutely certain that the infrastructure in your child/linked account (and indeed in any other AWS accounts) will not be affected when you remove it from the AWS Organization.

It is also worth noting at this point that if you don’t already have a valid payment method and phone number attached to the child/linked account, you will need to add these before you are allowed to remove the account from the AWS Organization. Once the account is removed from the AWS Organization, it temporarily becomes a standalone AWS account.

(b) Delete your single account AWS Organization

This sounds scary. Deleting a single account AWS Organization converts the single account AWS Organization into a standalone AWS account. Don’t do this unless you know exactly what you are doing and are absolutely certain that the infrastructure in this account (and indeed in any other AWS accounts) will not be affected.

(c) Create a new AWS Organization

You’ve now got one or more standalone AWS accounts. Create a new further standalone AWS account and convert it into an AWS Organization. This will now be your shell/empty management account. Then invite each of the existing standalone AWS accounts to join the new AWS Organization.

Pros:

  • You don’t need to migrate the infrastructure in your existing AWS management account to a new account.
  • Speed.

Cons:

  • It can be difficult to fully understand whether or not you are using AWS Organization-level services before deleting your AWS Organization.

3. Leave things as they are

Pros:

  • Cheap, for the time being 🙂

Cons:

  • Not best practice.
  • It is hard to get the most out of AWS Organizations with infrastructure in your management account.
  • You are delaying the inevitable; you will need to set up your AWS Organization adhering to best practices at some point.

What else can I do?

At Lambert Labs we have helped many customers remove AWS infrastructure from their AWS Organization management accounts. If you require assistance with this particular challenge, feel free to get in touch with us today.