Transcription
Organizing Your AWSEnvironment UsingMultiple AccountsAWS Whitepaper
Organizing Your AWS Environment UsingMultiple Accounts AWS WhitepaperOrganizing Your AWS Environment Using Multiple Accounts: AWSWhitepaperCopyright Amazon Web Services, Inc. and/or its affiliates. All rights reserved.Amazon's trademarks and trade dress may not be used in connection with any product or service that is notAmazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages ordiscredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who mayor may not be affiliated with, connected to, or sponsored by Amazon.
Organizing Your AWS Environment UsingMultiple Accounts AWS WhitepaperTable of ContentsOrganizing Your AWS Environment . iAbstract . 1Are you Well-Architected? . 1Introduction . 2AWS accounts . 2Stages of adoption . 2Best practices . 4Relation to AWS Well-Architected . 4Intended audience . 4Benefits of using multiple AWS accounts . 5Group workloads based on business purpose and ownership . 5Apply distinct security controls by environment . 5Constrain access to sensitive data . 6Promote innovation and agility . 6Limit scope of impact from adverse events . 6Support multiple IT operating models . 7Manage costs . 8Distribute AWS Service Quotas and API request rate limits . 8Core concepts . 9AWS Organizations . 9About organizations . 9Benefits of using OUs . 10Group similar accounts based on function . 11Apply common policies . 11Share common resources . 12Provision and manage common resources . 12Multiple organizations . 12Test changes to your overall AWS environment . 12Support acquisitions and divestments . 12Support large AWS environments . 13Align with your billing requirements . 13Design principles for organizing your AWS accounts . 14Organize based on security and operational needs . 14Apply security guardrails to OUs rather than accounts . 14Avoid deep OU hierarchies . 14Start small and expand as needed . 15Avoid deploying workloads to the organization’s management account . 15Separate production from non-production workloads . 15Assign a single or small set of related workloads to each production account . 15Use federated access to help simplify managing human access to accounts . 15Use automation to support agility and scale . 16Recommended OUs . 17Security OU . 18Log archive account . 18Security tooling accounts . 19Security read-only access account . 20Security break-glass account . 21Example structure . 21Infrastructure OU . 22Example structure . 22Sandbox OU . 23Sandbox per builder or team with spend limits . 23Temporary resources and environments . 23Wide-ranging access . 24iii
Organizing Your AWS Environment UsingMultiple Accounts AWS WhitepaperNo access to corporate resources and non-public data .Sandbox and development environments .Example structures .Workloads OU .Example structure .Policy Staging OU .Workload-specific policies .Recommended testing and promotion workflow .Example structure .Suspended OU .Constraining activity in suspended accounts .Tagging suspended accounts .Closing suspended accounts .Individual Business Users OU .Guardrails .Services that do not require direct user access to accounts .Exceptions OU .Service control policies and scrutiny .Consider Workloads OU as an alternative .Deployments OU .Using CI/CD capabilities residing outside of your AWS environment .Separating CI/CD management capabilities from workloads .Running CI jobs and CD build stages in deployment accounts .Aligning CI/CD accounts with groups of workloads .Considering use of multi-tenant shared CI/CD services .Enabling team access to production CI/CD services .Providing CD pipeline access to workload accounts .Testing changes to your CI/CD capabilities .Developing and testing CI jobs and CD pipelines .Example structure .Transitional OU .Common reasons for moving accounts into your organization .Benefits of moving accounts into your AWS organization .Considerations for moving accounts into your organization .After moving accounts .Organizing workload-oriented OUs .Workloads and environments .Workloads .Workload environments .Workload accounts .Production and non-production workload environments .Workload dependencies across environments .Production environments accessing non-production .Non-production environments accessing dependencies .OU structure for non-production environments .Option A: Common guardrails across non-production environments .Option B: Different guardrails across non-production environments .Worksheets to help decide on workload-oriented OUs .Extended workload-oriented OU structure .Grouping related workloads .Separating business units with significantly different policies .Patterns for organizing your AWS accounts .Single AWS account .Production starter organization .Production starter organization with AWS Control Tower .Basic organization .Basic organization with infrastructure services 24243454545474850
Organizing Your AWS Environment UsingMultiple Accounts AWS WhitepaperBasic organization with CI/CD as a separate function . 52Advanced organization . 54Conclusion . 56Implementation . 57Getting Started with your multi-account environment . 57New Customers . 57Existing Customers . 57Services to help you implement your multi-account environment . 60AWS Organizations . 9AWS Control Tower . 61AWS Managed Services . 61Contributors . 62Additional resources . 63Appendix A: Relation to AWS Well-Architected . 64Operational Excellence Pillar . 64Security Pillar . 64Reliability Pillar . 64Cost Optimization Pillar . 65Appendix B: Worksheet for mapping workload environment purposes to hosting environment types . 66Use the results for internal documentation . 66How to use this worksheet . 66Descriptions of example purposes of workload environments . 67Self-paced learning and experimentation workload environments . 67Development workload environments . 67Static analysis, build, and unit testing workload environments . 67CI jobs and CD pipelines workload environments . 67Smoke testing workload environments . 68Development integration testing workload environments . 68Production-like system testing workload environments . 68Stable shared test workload environments . 68Resiliency testing workload environments . 68Demo workload environments . 69External pre-release workload environments . 69Production workload environments . 69Descriptions of example workload hosting environment types . 69Corporate desktop environments . 69Sandbox environments . 69Development environments . 70Data-oriented development environments . 70Test environments . 70Production environments . 70Example worksheet . 70Empty worksheet . 71Appendix C: Worksheet for identifying attributes of workload hosting environments . 73How to use this worksheet . 73Descriptions of example attributes . 73Owners/Tenants . 74Tolerance for extended outages . 74Internet access . 75Internal network access . 75Data . 75Third-party software and cloud services . 76Degree of access . 76Lifespan of resources . 76Direct human write access to workload resources . 76Automated workload provisioning . 77Formal change management for workloads . 77v
Organizing Your AWS Environment UsingMultiple Accounts AWS WhitepaperDegree of centrally managed foundation .Common enterprise guardrails .Example worksheet .Empty worksheet .Appendix D: Multiple AWS Regions .Geographic scopes of data protection .Performance considerations .Log management .Appendix E: How does AWS Control Tower establish your multi-account environment? .Establish your multi-account environment with AWS Control Tower .Next Steps for setting up your multi-account environment .Document history .Notices .vi77787881838383838585868788
Organizing Your AWS Environment UsingMultiple Accounts AWS WhitepaperAbstractOrganizing Your AWS EnvironmentUsing Multiple AccountsPublication date: March 31, 2022 (Document history (p. 87))AbstractBusinesses that are starting to adopt AWS, expanding their footprint on AWS, or planning to enhance anestablished AWS environment, can benefit from considering the latest guidance for organizing their AWSenvironments.Using multiple AWS accounts to help isolate and manage your business applications and data canhelp you optimize across most of the AWS Well-Architected Framework pillars including operationalexcellence, security, reliability, and cost optimization. This paper provides best practices for organizingyour overall AWS environment. The extent to which you use these best practices depends on your stageof the cloud adoption journey and your specific business needs.Are you Well-Architected?The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you makewhen building systems in the cloud. The six pillars of the Framework allow you to learn architectural bestpractices 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 canreview 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 architecturedeployments, diagrams, and whitepapers—refer to the AWS Architecture Center.1
Organizing Your AWS Environment UsingMultiple Accounts AWS WhitepaperAWS accountsIntroductionBusinesses that are starting to adopt AWS, expanding their footprint on AWS, or planning to enhance anestablished AWS environment, can benefit from considering the latest guidance for organizing their AWSenvironments.As AWS customers look to establish their AWS Cloud presence, they look for a way to build out theircloud foundations to enable them to deploy production workloads. Many customers want the ability tobuild and move fast while staying secure.Customers might have multiple teams with different security and compliance controls that need to beisolated from one other. Some might have different business processes entirely or be part of differentbusiness lines that need clarity of costs incurred.Customers need explicit security boundaries, a mechanism to have direct control and visibility of theirlimits and any throttling, and a complete 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 canhelp you optimize across most of the AWS Well-Architected Framework pillars including operationalexcellence, security, reliability, and cost optimization.Topics AWS accounts (p. 2) Stages of adoption (p. 2) Best practices (p. 4) Relation to AWS Well-Architected (p. 4) Intended audience (p. 4)AWS accountsYour cloud resources and data are contained in an AWS account. An account acts as an identity andaccess management isolation boundary. When you need to share resources and data between twoaccounts, you must explicitly allow this access.By default, no access is allowed between accounts. For example, if you designate different accountsto contain your production and non-production resources and data, by default, no access is allowedbetween those environments.The number of accounts that best meets your needs can range from a few, to hundreds, or eventhousands. Management of many accounts requires use of automation to help minimize your operationalcomplexity 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 ofaccount quantity.Stages of adoptionThrough experience working with thousands of customers, AWS has outlined a common set of stages ofcloud adoption. These best practices are designed to help you meet your needs throughout your cloudadoption journey. You can start out with a small AWS environment and progressively grow and evolve itas you gain experience and expand your adoption.2
Organizing Your AWS Environment UsingMultiple Accounts AWS WhitepaperStages of adoptionWhen your organization is new to AWS, you might start by creating one or more personal or teammanaged accounts for initial experimentation. This work is usually done informally and before moreconcerted efforts are made to evaluate the value of AWS. In this experimental and often informalstage, there’s usually little investment made in organizing and rationalizing the number and purpose ofaccounts.Stages of cloud adoptionIn the project stage of adoption, you begin to formally plan for your first few production deploymentson AWS. It’s common to establish an initial cloud foundation that meets your security, governance, andoperational requirements.A workload identifies a set of components that together deliver business value. A workload is usually thelevel of detail that business and technology leaders communicate about. Some examples of workloadsare: Marketing websites Ecommerce websites Mobile app backends Analytic platformsWorkloads vary in levels of architectural complexity, from static websites to complex microservices eachwith potentially different requirements on cost or billing identification.Rather than using a single account, we recommend that you use at least several accounts to separateyour workloads. This approach is designed to make it easier for you to meet your requirements, even inthe early project stage of adoption. Based on the success of those first few workloads, you’ll likely wantto gain further business benefits by expanding your adoption of AWS. This motivation often leads to thefoundation stage of adoption. In this stage, you invest in evolving your cloud foundational capabilitiesbefore greatly expanding adoption.Evolving your foundation in AWS often includes formalizing and expanding the structure of youraccounts to meet the needs of onboarding more teams and workloads
Organizing Your AWS Environment Using Multiple Accounts AWS Whitepaper AWS accounts Introduction Businesses that are starting to adopt AWS, expanding their footprint on AWS, or planning to enhance an
![[AWS Black Belt Online Seminar] AWS X-Ray](/img/17/20200526-blackbelt-x-ray.jpg)
