Below are the main topics involved in this
Group workloads based on business purpose and ownership
Apply distinct security controls by environment
Constrain access to sensitive data
Promote innovation and agility
Limit scope of impact from adverse events
Support multiple IT operating models
Manage costs
Distribute AWS Service Quotas and API request rate limits
Group workloads based on business purpose and ownership
You can group workloads with a common business purpose in distinct accounts. As a result, you can align the ownership and decision making with those accounts and avoid dependencies and conflicts with how workloads in other accounts are secured and managed.
Different business units or product teams might have different processes. Depending on your overall business model, you might choose to isolate distinct business units or subsidiaries in different accounts. Isolation of business units can help them operate with greater decentralized control, but still provides the ability for you to provide overarching guardrails. This approach might also ease divestment of those units over time.
Guardrails are governance rules for security, operations, and compliance that you can define and apply to align with your overall requirements.
Apply distinct security controls by environment
Workloads often have distinct security profiles that require separate control policies and mechanisms to support them. For example, it’s common to apply different security and operational policies for the non-production and production environments of a given workload. By using separate accounts for the non-production and production environments, by default, the resources and data that make up a workload environment are separated from other environments and workloads.
Constrain access to sensitive data
When you limit sensitive data stores to an account that is built to manage it, you can more easily constrain the number of people and processes that can access and manage the data store. This approach simplifies the process of achieving least privilege access. Limiting access at the coarse-grained level of an account helps contain exposure to highly sensitive data.
For example, designating a set of accounts to house publicly accessible Amazon S3 buckets enables you to implement policies for all your other accounts to expressly forbid making S3 buckets publicly available.
Promote innovation and agility
At AWS, we refer to your technologists as builders because they are all responsible for building value using AWS products and services. Your builders likely represent diverse roles, such as application developers, data engineers, data scientists, data analysts, security engineers, and infrastructure engineers.
In the early stages of a workload’s lifecycle, you can help promote innovation by providing your builders with separate accounts in support of experimentation, development, and early testing. These environments often provide greater freedom than more tightly controlled production-like test and production environments by enabling broader access to AWS services while using guardrails to help prohibit access to and use of sensitive and internal data.
Sandbox accounts are typically disconnected from your enterprise services and do not provide access to your internal data, but offer the greatest freedom for experimentation.
Development accounts typically provide limited access to your enterprise services and development data, but can more readily support day-to-day experimentation with your enterprise approved AWS services, formal development, and early testing work.
In both cases, we recommend security guardrails and cost budgets so that you limit risks and proactively manage costs.
Limit scope of impact from adverse events
An AWS account provides security, access, and billing boundaries for your AWS resources that can help you achieve resource independence and isolation. By design, all resources provisioned within an account are logically isolated from resources provisioned in other accounts, even within your own AWS environment.
This isolation boundary provides you with a way to limit the risks of an application-related issue, misconfiguration, or malicious actions. If an issue occurs within one account, impacts to workloads contained in other accounts can be either reduced or eliminated.
Manage Costs
An account is the default means by which AWS costs are allocated. Because of this fact, using different accounts for different business units and groups of workloads can help you more easily report, control, forecast, and budget your cloud expenditures.
In addition to cost reporting at the account level, AWS has built-in support to consolidate and report costs across your entire set of accounts. When you require fine-grained cost allocation, you can apply cost allocation tags to individual resources in each of your accounts.
Distribute AWS Service Quotas and API request rate limits
AWS Service Quotas, also known as limits, are the maximum number of service resources or operations that apply to an account. For example, the number of Amazon Simple Storage Service (Amazon S3) buckets that you can create for each account.
You can use Service Quotas to help protect you from unexpected excessive provisioning of AWS resources and malicious actions that could dramatically impact your AWS costs.
AWS services can also throttle or limit the rate of requests made to their API operations.
Because Service Quotas and request rate limits are allocated for each account, use of separate accounts for workloads can help distribute the potential impact of the quotas and limits.
references:
https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html
No comments:
Post a Comment