AWS whitepapers documentation change
Summary
Minor text formatting changes, typo fixes, and rephrasing for clarity. Includes splitting paragraphs, updating image alt text, and consolidating link formatting.
Security assessment
Changes focus on grammatical improvements, formatting consistency, and documentation clarity rather than addressing security vulnerabilities or introducing new security features. While the content discusses security boundaries and isolation as benefits of multi-account strategies, these are existing security concepts being maintained rather than new security documentation.
Diff
diff --git a/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.md b/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.md index 511e5333a..982549a55 100644 --- a//whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.md +++ b//whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.md @@ -38 +38 @@ You can group workloads with a common business purpose in distinct accounts. As -Different business units or product teams might have different processes or security boundary requirements. Depending on your overall business model, you might choose to isolate distinct business units or subsidiaries in different accounts or organizational units (OUs). Isolation of business units can help them operate with greater decentralized control, but still provides the ability for you to provide overarching controls. This approach might also ease divestment of those units over time. +Different business units or product teams might have different processes or security boundary requirements. Depending on your overall business model, you might choose to isolate distinct business units or subsidiaries in different accounts or Organizational Units. Isolation of business units can help them operate with greater decentralized control, but still provides the ability for you to provide overarching controls. This approach might also ease divestment of those units over time. @@ -46 +46 @@ If you acquire a business that is already operating in AWS, you can move the ass -Workloads often have distinct security postures that require separate controls and mechanisms to support them. For example, it’s common to apply different security and operational controls 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. +Workloads often have distinct security postures that require separate controls and mechanisms to support them. For example, it's common to apply different security and operational controls 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. @@ -54 +54 @@ Establishing these data perimeters is particularly valuable for highly confident -For example, designating a set of accounts to house publicly accessible (Amazon S3) buckets enables you to implement policies for all of your other accounts to expressly forbid making Amazon S3 buckets publicly available. +For example, designating a set of accounts to house publicly accessible (Amazon S3) buckets enables you to implement policies for all of your other accounts to prohibit making Amazon S3 buckets publicly available. @@ -58 +58,3 @@ For example, designating a set of accounts to house publicly accessible (Amazon -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 controls to help prohibit access to and use of sensitive and internal data. +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 controls to help prohibit access to and use of sensitive and internal data. @@ -73 +75 @@ In support of later stages of the workload lifecycle, you can use distinct test -The inherent isolation provided by an AWS account can be leveraged to limit the scope of impact from issues within your cloud environment. By provisioning resources within dedicated accounts, you establish clear security, access, and billing boundaries that prevent problems from spreading between different parts of your infrastructure. This account-level isolation is a key benefit of a multi-account strategy, as it ensures that if an application-level problem, misconfiguration, or malicious activity occurs within one account, the impacts can be contained and prevented from impacting workloads in other accounts. Maintaining this resource independence across multiple accounts is a powerful way to manage risk and ensure failures remain localized, providing a safeguard against wider disruptions that could occur in a single monolithic account environment. +The inherent isolation provided by an AWS account can be leveraged to limit the scope of impact from issues within your cloud environment. By provisioning resources within dedicated accounts, you establish clear security, access, and billing boundaries that prevent problems from spreading between different parts of your infrastructure. This account-level isolation is a key benefit of a multi-account strategy, as it helps ensure that if an application-level problem, misconfiguration, or malicious activity occurs within one account, the impacts can be contained and prevented from impacting workloads in other accounts. Maintaining this resource independence across multiple accounts is a powerful way to manage risk and help ensure failures remain localized, providing a safeguard against wider disruptions that could occur in a single monolithic account environment. @@ -79 +81 @@ Organizations often have multiple IT operating models or ways in which they divi - + @@ -94,3 +96 @@ As a practice, IT Service Management (ITSM) is a common element across all of th -Given the implications of centralized operations versus more distributed operational responsibilities, you will likely benefit from establishing separate groups of accounts in support of different operating models. Use of separate accounts enables you to apply distinct governance and operational controls that are appropriate for each of your operating models. - -To learn more about operating models and their implications on your cloud adoption, refer to the the [AWS Well-Architected Operational Excellence Pillar Operating Model](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html). +Given the implications of centralized operations versus more distributed operational responsibilities, you will likely benefit from establishing separate groups of accounts in support of different operating models. Use of separate accounts enables you to apply distinct governance and operational controls that are appropriate for each of your operating models. To learn more about operating models and their implications on your cloud adoption, refer to the [AWS Well-Architected Operational Excellence Pillar Operating Model.](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html) @@ -102,3 +102 @@ An account is the default means by which AWS costs are allocated. Because of thi -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. - -For more information about cost optimization, see the AWS Well-Architected Cost Optimization Pillar’s [Expenditure and Usage Awareness](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/expenditure-and-usage-awareness.html) best practices. +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. For more information about cost optimization, see the AWS Well-Architected Cost Optimization Pillar's [Expenditure and Usage Awareness](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/expenditure-and-usage-awareness.html) best practices. @@ -112,3 +110 @@ You can use Service Quotas to help protect you from unexpected excessive provisi -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. +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.