# 使用多账户的好处

## 按照业务目标和负责人对资源进行分组

您可以将具有共同业务目的的工作负载归入不同的账户。 这样，你就可以将所有权和决策权与这些账户统一起来，避免与其他账户中工作负载的安全和管理方式产生依赖和冲突。

隔离业务单元有助于它们在更大程度上分散控制，但仍能为您提供总体监管。 随着时间的推移，这种方法还可以方便剥离这些业务单元。

## 按环境实施不同的安全控制

为特定工作负载的非生产环境和生产环境应用不同的安全和操作策略是很常见的。 默认情况下，通过为非生产环境和生产环境使用单独的账户，构成工作负载环境的资源和数据就会与其他环境和工作负载分开。

## 限制对敏感数据的访问

如果将敏感数据存储限制在专为管理该数据存储而建立的账户中，就可以更轻松地限制可访问和管理数据存储的人员和流程数量。 这种方法简化了实现最小权限访问的过程。 在账户的粗粒度级别限制访问权限，有助于控制高度敏感数据的暴露。

例如，指定一组账户存放可公开访问的（Amazon S3）存储桶，就可以对所有其他账户实施策略，明确禁止公开 Amazon S3 存储桶。

## 促进创新和灵活性

在 AWS，我们将技术人员称为构建者，因为他们都负责使用 AWS 产品和服务构建价值。 您的构建人员可能代表不同的角色，如应用程序开发人员、数据工程师、数据科学家、数据分析师、安全工程师和基础架构工程师。

在工作负载生命周期的早期阶段，您可以通过为构建人员提供独立账户来支持实验、开发和早期测试，从而帮助促进创新。 与严格控制的生产型测试和生产环境相比，这些环境通常能提供更大的自由度，因为它们允许更广泛地访问 AWS 服务，同时使用防护栏来帮助禁止访问和使用敏感数据和内部数据。

在这两种情况下，我们都建议采用安全护栏和成本预算，以便限制风险并积极管理成本。

## 限制不良事件的影响范围

AWS 账户为您的 AWS 资源提供安全、访问和计费边界，可帮助您实现资源独立和隔离。 根据设计，一个账户中配置的所有资源在逻辑上都与其他账户中配置的资源隔离，甚至在您自己的 AWS 环境中也是如此。

这种隔离边界为您提供了一种限制应用程序相关问题、错误配置或恶意行为风险的方法。 如果问题发生在一个账户中，对其他账户中工作负载的影响就会减少或消除。

## 支持多种 IT 运营模式

企业通常有多种 IT 运营模式，或在企业各部门之间划分责任的方式，以交付应用工作负载和平台功能。 下图显示了三种运营模式示例：

<figure><img src="https://3752289132-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LTfg4e0NhLEbwi6WFJp%2Fuploads%2FCfmwH8lQT08uF14vPdjc%2Fimage.png?alt=media&#x26;token=fb76ad7b-19b8-4c0e-b75f-e08fc80a8fa8" alt=""><figcaption></figcaption></figure>

* 在传统运营模式中，拥有定制和现成商用（COTS）应用程序的团队负责应用程序的工程设计，但不负责生产运营。 云平台工程团队负责底层平台功能的工程设计。 单独的云运营团队负责应用程序和平台的运营。
* 在 CloudOps 模式中，COTS负责工程设计，也负责其应用的生产运营。 在这种模式中，一个共同的云平台工程团队负责底层平台功能的工程和运营。
* 在 DevOps 模式中，DevOps团队承担了工程设计和运营平台功能的额外责任，这些功能是针对其应用的。 云平台工程团队负责多个应用程序使用的共享平台功能的工程和运营。

作为一种实践，IT 服务管理（ITSM）是所有模式的共同要素。 在这些模式中，ITSM 的总体目标和要求可能不会改变，但实现这些目标和要求的责任人和解决方案却会因模式而异。

考虑到集中运营与更分散的运营责任之间的影响，建立支持不同运营模式的独立账户组可能会让你受益匪浅。 使用单独的账户可以让你应用适合每种运营模式的不同管理和运营控制。

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).

## 管理成本

账户是分配 AWS 成本的默认方式。 因此，为不同的业务部门和工作负载组使用不同的账户可以帮助您更轻松地报告、控制、预测和预算云支出。

除了账户级别的成本报告外，AWS 还内置了对整个账户集成本合并和报告的支持。 当您需要精细的成本分配时，可以将成本分配标签应用到每个账户中的单个资源。

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.

## 分散AWS Service Quotas 和 API request rate limits <a href="#distribute-aws-service-quotas-and-api-request-rate-limits" id="distribute-aws-service-quotas-and-api-request-rate-limits"></a>

[AWS Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)，也称为限制，是适用于某个帐户的服务资源或操作的最大数量。 例如，每个账户可创建的 Amazon S3 存储桶数量。

您可以使用 "服务配额 "来帮助保护您的 AWS 资源免遭意外的过度调配，以及可能对您的 AWS 成本造成巨大影响的恶意行为。

由于服务配额和请求率限制是为每个账户分配的，因此为工作负载使用单独的账户有助于分散配额和限制的潜在影响。

To learn more about managing service quotas, refer to the AWS Well-Architected Reliability Pillar: [Manage Service Quotas and Constraints](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html).

参考资料

aws docs:<https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html>
