Build a Multi-Account Strategy on AWS with Best Practices

Deploying your AWS infrastructure into multiple AWS accounts is a best practice and for good reason. This blog post will help you set up your multi-account strategy in AWS and explain why you should do it. A multi-account strategy prevents infrastructure from getting entangled and allows you to manage different parts of your infrastructure independently. The most important benefits of a multi-account strategy are:

Reducing the complexity of your AWS infrastructure makes it easier to manage and understand.
Improve security by isolating different parts.
Better cost management by separating environments or workloads.
Enhanced reliability by isolating failures.

These reasons are why almost all companies eventually adopt a multi-account strategy. Adopting it early in your AWS journey will ensure you do not build up technical debt that typically takes years to pay off. At the same time, it costs very little to adopt initially and has immediate benefits.

Why adopt a multi-account strategy?

Reduce complexity

In software development, you add classes, functions, and modules as abstractions to reduce complexity. You couple related functionality together and create clear boundaries. These abstractions help you to manage complexity and make your code easier to understand and maintain. You only have to reason about the functionality inside the abstraction.

The concept of reducing complexity by creating boundaries is also true for your AWS infrastructure. A multi-account strategy helps by providing abstractions and helps you decouple AWS infrastructure. Inside an AWS account, you can deploy resources that are related to a specific workload, environment, or purpose. You only have to reason about the resources inside the account.

A clear example of this is already in naming, one of the most critical aspects of software development. By using an account to couple your resources, you can apply a name to the account, and it is implied to all resources. You don’t have to repeat the name of the workload and environment in every resource.

Improve security

Security is a critical aspect of any infrastructure, and we want to make applying security as easy as possible. Security should be a default, not an afterthought or a burden.

A multi-account strategy helps you to improve security by providing clear and default security boundaries through AWS accounts. They are easy to work with and are always in place.

Multiple AWS accounts provide many hard security boundaries around your resources. Restricting access is no longer an afterthought, but a default. You will always have to allow access to the security boundary explicitly.

However, providing access is also easier. The AWS Accounts become clear trust boundaries: resources inside the account are trusted and resources outside the account are not trusted. So you have to put less work in restricting access inside your own account because resources are trusted. Giving access is simpler because you can give other accounts access instead of specific resources.

An AWS account is especially good for isolating different data residency requirements. For example, you can have a member account for your European customers and a member account for your US customers. This way, you can ensure that data is stored in the correct region and comply with local regulations.

Better cost management

Having good cost insights helps you to identify where you can save costs. If all the cost of your AWS infrastructure is on one big bill, it is harder to spot where you are spending too much money.

A multi-account strategy helps you to manage costs because accounts can easily track costs individually. You can track the costs of every workload and environment separately. This allows you to identify where you can save costs and where you are spending too much money.

Enhanced reliability

The more reliable your infrastructure is, the better your customers’ experience. You can improve reliability by reducing the blast radius of failures and changes. Incidents will still happen, but they will have less impact and impact fewer customers.

A multi-account strategy helps you to reduce the blast radius of failures and changes by isolating workloads. Introducing changes becomes more targeted and isolated. You can deploy changes to a specific workload or environment without affecting other workloads or environments. There is also lower risks of data flowing into the wrong place or being deleted by accident.

Every AWS account comes with its limits on how much and many AWS resources you can use. By having more accounts, each part of your infrastructure has its own limits. This means that if you hit a limit in one account, it does not affect the other accounts

Setting up a multi-account strategy in AWS

Create a management account

The first step in setting up a multi-account strategy is to create a management account. The management account manages all your other AWS accounts. The management account serves as the root of your multi-account strategy and has several key characteristics:

Administrative control: Creates and governs your AWS accounts
Billing responsibility: Pays for all accounts.
Security policies: Applies security policies to member accounts.

An AWS account is a logical container boundary on many layers between other AWS Accounts. The management account is nothing different from any other AWS account, except that you only use it to create and manage your other AWS accounts. As such, you should not deploy any other AWS resources, like EC2 machines or S3 buckets, into the management account to keep it clean. This is because when you later apply security policies, these are not applied to the management account. So you want to lock it down and keep it as simple as possible.

Ideally, you create the management account as a first step, and afterward, you add additional member accounts. However, often developers used the first AWS account to deploy resources. There are two options to clean up the management account:

You can create a new AWS account and invite the existing AWS accounts into the new AWS Organization if you do not have an extensive AWS organization yet.
Migrate the resources to a new account and thus clean up the management account if it is easy to move.

Set up AWS Organization

Now that you have a management account, you can set up an AWS Organization. AWS Organizations is a service that allows you to manage multiple AWS accounts, organize them into Organizational Units, and apply policies across those accounts.

AWS Organization

Inside the management account, you create and manage your other AWS accounts, called member accounts. Member accounts are the AWS accounts where you deploy your actual AWS resources. You can create member accounts directly in the management account using AWS Organizations or invite existing AWS accounts to join your organization.

Introduce a member account per workload.

In AWS, the term workload is a logical grouping of resources that provide a specific service or functionality. Your developers and business leaders often talk about a workload as a single unit and identify it separately in your strategy. As such, a frontend and backend that work together can be both in the same workload, but sometimes a single backend is also a workload. It varies per company, and can also evolve over time as your company grows and your strategy changes. Applying bounded context from Domain Driven Design (DDD) can help you identify the boundaries of your workloads.

Member Accounts

In a multi-account strategy, every workload gets its own member account. The member account provides a boundary around the workloads and helps you enforce your strategy. It simplifies working on the workload:

Complexity: everything in the account is related to the workload, making it easier to understand and manage.
Security: you can give access to the workload by simply providing access to the member account.
Cost Management: You can easily track the costs of a workload by looking at the cost of the member account.

Create a member account per environment.

We take this concept of using AWS accounts to create boundaries further by introducing a member account per environment. This helps to isolate your environments to prevent changes in one environment from affecting another.

Member Accounts

So in a multi-account strategy, you also add a member account per development environment. In turn, every workload gets its own member account per environment. This means you have a member account for development, staging, and production for every workload.

Create a member account per region.

Additionally, we might service customers in other regions, and we want to make sure these regions are isolated from each other. We also want to make sure that we never mix data from one data residency region with another. For example, customer data from the European Union should not be stored in the United States, and vice versa.

Regions

So we create a member account for every production region. Adding so many accounts might seem like overkill, but it helps you to create good boundaries between regions and ensures you never make changes to the wrong regions.

Checklist

Set up a Management Account
Set up AWS Organisation
Add AWS Member Accounts per Workload
Add AWS Member Accounts per Environment
Add AWS Member Accounts per Region
Ensure your Management Account is clean and does not contain any AWS resources.

Conclusion

A multi-account strategy is a best practice for AWS infrastructure. It helps you to reduce complexity, improve security, better cost management, and enhance reliability.

Rocketleap can help you set up your multi-account strategy in days. We have a proven track record of helping companies move to a multi-account strategy and avoid common pitfalls.