Publication date: July 26, 2022 (Document history) AbstractBusinesses that are starting to adopt 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. Skip to Main Content
AWS enables you to experiment, innovate, and scale more quickly, all while providing the most flexible and secure cloud environment. An important means through which AWS ensures security of your applications is the AWS account. An AWS account provides natural security, access and billing boundaries for your AWS resources, and enables you to achieve resource independence and isolation. For example, users outside of your account do not have access to your resources by default. Similarly, the cost of AWS resources that you consume is allocated to your account. While you may begin your AWS journey with a single account, AWS recommends that you set up multiple accounts as your workloads grow in size and complexity. Using a multi-account environment is an AWS best practice that offers several benefits:
Ultimately, a multi-account AWS environment enables you to use the cloud to move faster and build differentiated products and services, all while ensuring you do so in secure, scalable and resilient manner. But, how should you build your multi-account AWS environment? You may have questions such as what account structure to use, what policies and guardrails should be implemented, or how to set up your environment for auditing. The rest of this guide will walk you through the elements of building a secure and productive multi-account AWS environment, often referred to as a “landing zone,” as recommended by AWS. This represents the best practices that can be used to build an initial framework while still allowing for flexibility as your AWS workloads increase over time.
The basis of a well-architected multi-account AWS environment is AWS Organizations, an AWS service that enables you to centrally manage and govern multiple accounts. Before getting started, let’s get familiar with a few terms. An organizational unit (OU) is a logical grouping of accounts in your AWS Organization. OUs enable you to organize your accounts into a hierarchy, and make it easier for you to apply management controls. AWS Organizations policies are what you use to apply such controls. A Service Control Policy (SCP) is a policy that defines the AWS service actions, such as Amazon EC2 Run Instance, that accounts in your organization can perform. First, consider what account groupings or OUs you should create. Your OUs should be based on function or common set of controls rather than mirroring your company’s reporting structure. AWS recommends that you start with security and infrastructure in mind. Most businesses have centralized teams that serve the entire organization for those needs. As such, we recommend creating a set of foundational OUs for these specific functions:
Given that most companies have different policy requirements for production workloads, infrastructure and security can have nested OUs for non-production (SDLC) and production (Prod). Accounts in the SDLC OU host non-production workloads and therefore should not have production dependencies from other accounts. If there are variations in OU policies between life cycle stages, SDLC can be split into multiple OU's (e.g. dev and pre-prod). Accounts in the Prod OU host the production workloads. Apply policies at the OU-level to govern the Prod and SDLC environment per your requirements. In general, applying policies at the OU-level is a better practice than at the individual account-level as it simplifies policy management and any potential troubleshooting.
Once the central services are in place, we recommend creating OUs that directly relate to building or running your products or services. Many AWS customers build these OU’s after establishing the foundation.
Now that both the foundational and production-oriented OU’s are established, we recommend adding additional OU’s for maintenance and continued expansion depending on your specific needs. These are some common themes based on practices from existing AWS customers:
|