Organizing Your AWS Environment Using Multiple Accounts

Publication date: March 28, 2024 (Document history)

Abstract

Businesses that are starting to adopt Amazon Web Services (AWS), expanding their footprint on AWS, or planning to enhance an established AWS environment need to ensure they have a foundation on AWS for their cloud environment. One important aspect of their foundation is organizing their AWS environment following a multi-account strategy.

Using multiple AWS accounts to help isolate and manage your business applications and data can help you optimize across most of the AWS Well-Architected Framework pillars, including operational excellence, security, reliability, and cost optimization. This paper provides best practices and current recommendations for organizing your overall AWS environment. The extent to which you use these best practices depends on your stage of the cloud adoption journey and specific business needs.

Are you Well-Architected?

The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.

For more expert guidance and best practices for your cloud architecture—reference architecture deployments, diagrams, and whitepapers—refer to the AWS Architecture Center.

Introduction

Using multiple AWS accounts to help isolate and manage your business applications and data can help you optimize across most of the AWS Well-Architected Framework pillars including operational excellence, security, reliability, and cost optimization.

Multi-account strategy best practices and recommendations

Businesses can benefit from considering the latest guidance for organizing their AWS environments. A multi-account strategy is key to succeed when customers are starting to adopt AWS, expanding their footprint on AWS, or planning to enhance an established AWS environment.

Customers might have multiple teams with different security and compliance controls that need to be isolated from one another. Some might have different business processes entirely or be part of different business lines that need clarity around costs incurred.

Customers need explicit security boundaries, a mechanism to have direct control and visibility of their limits and any throttling, and a billing separation to directly map costs to underlying projects. The isolation designed into an AWS account can help you meet these needs.

Using multiple AWS accounts to help isolate and manage your business applications and data can help you optimize across most of the AWS Well-Architected Framework pillars including operational excellence, security, reliability, and cost optimization.

AWS accounts

Your cloud resources and data are contained in an AWS account. An account acts as an identity and access management isolation boundary. When you need to share resources and data between two accounts, you must explicitly allow this access.

By default, no access is allowed between accounts. For example, if you designate different accounts to contain your production and non-production resources and data, no access is allowed between those environments by default.

The number of accounts that best meets your needs can range from a few to hundreds or even thousands. Management of many accounts requires use of automation to help minimize your operational complexity and ensure efficient alignment with your security, governance, and operational requirements. AWS does not charge per account. Rather, you incur charges based on resources used, regardless of account quantity.

Stages of adoption

Through experience working with thousands of customers, AWS has outlined a common set of stages of cloud adoption. These best practices are designed to help you meet your needs throughout your cloud adoption journey. You can start with a small AWS environment and progressively grow and evolve it as you gain experience and expand your adoption.

When your organization is new to AWS, you might start by creating one or more personal or team-managed accounts for initial experimentation. This work is usually done informally and before more concerted efforts are made to evaluate the value of AWS. In this experimental and often informal stage, there’s usually little investment made in organizing and rationalizing the number and purpose of accounts.

Stages of cloud adoption

In the project stage of adoption, you begin to formally plan for your first few production deployments on AWS. It’s common to establish an initial cloud foundation that meets your security, governance, and operational requirements.

A workload identifies a set of components that deliver business value together. A workload is usually the level of detail that business and technology leaders communicate about. Some examples of workloads are:

• Marketing websites

• Ecommerce websites

• Mobile app backends

• Analytic platforms

Workloads vary in levels of architectural complexity, from static websites to complex microservices, each with potentially different requirements on cost or billing identification.

Rather than using a single account, we recommend that you use several accounts to separate your workloads. This approach is designed to make it easier for you to meet your requirements, even in the early project stage of adoption. Based on the success of those first few workloads, you might want to gain further business benefits by expanding your adoption of AWS. This motivation often leads to the foundation stage of adoption. In this stage, you invest in evolving your cloud foundational capabilities before greatly expanding adoption.

Evolving your foundation in AWS often includes formalizing and expanding the structure of your accounts to meet the needs of onboarding more teams and workloads. At this stage, it’s important for you to design and prepare to manage your AWS environment so that it can scale to meet your needs without the need for a corresponding linear increase in headcount. As you plan for and perform large-scale migrations and deploy net new cloud native workloads, you can continue to adjust and enhance your approach to using multiple accounts.

Best practices

The best practices described in this paper are designed to help you more easily achieve your security, governance, and operational requirements through multiple accounts. The best practices were assembled based on the experiences of thousands of customers who have progressed through their cloud adoption journeys.

The best practices can help you quickly establish the initial right-sized scope of your AWS environment, and adjust and expand your AWS environment as you gain experience both with the AWS services and how you work with the AWS Cloud.

Although your needs will likely be similar to the needs of other organizations, each organization also has some unique requirements. Accordingly, these best practices are intended to offer guidance rather than a one-size-fits-all solution to organizing your AWS environment. As a result, the design of your AWS environment might differ from the examples provided in this document. However, these best practices will help you make informed decisions as you design your environment.

Relation to AWS Well-Architected

AWS Well-Architected helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for their applications and workloads. Based on six pillars—operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability—AWS Well-Architected provides a consistent approach for customers and partners to evaluate architectures and implement designs that can scale over time.

The best practices for organizing your AWS environment addressed in this guide augment and support the best practices represented in the Well-Architected pillars.

Refer to Appendix A: Relation to AWS Well-Architected for a detailed list of areas of the Well-Architected framework that are related to how you organize your AWS environment.

Intended audience

These best practices are oriented toward cloud architects and technical leads who are responsible for the overall security and architecture of an AWS environment. Whether you are new to AWS or you have already been using AWS for years, your team will benefit from reviewing these best practices and comparing them to your requirements and current AWS environment.

These best practices are intended to apply to organizations largely independent of their industry, size, expected scale of adopting AWS, and workload portfolio. Depending on your needs, not all of the best practices might apply to your situation.

If you’re just starting to experiment and learn about AWS by using a single AWS account, you don't need to consider these best practices until you begin planning for your first few production workloads.