此内容已过时。此版本的架构完善的框架现在可在以下位置找到： https://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/cost-optimization.html

COST 2: 您如何管理使用情况？

制定各种策略和机制，确保花费适当的成本来达到目标。采用制约与平衡方法，您可以在不超支的情况下进行创新。

资源

Control access to AWS Regions using IAM policies
AWS multiple account billing strategy
AWS managed policies for job functions

最佳实践:

改进计划

根据组织的要求制定各种策略

  • 与团队成员会面 : 要制定策略，请召集组织中的所有团队成员，详细说明他们的要求并相应地编制成档。采用迭代方法，首先大致进行，然后在每一步中不断细化到最小单元。团队成员包括与工作负载切身相关的人员（例如组织单位或应用程序负责人）以及支持小组（例如安全和财务团队）。
  • 定义工作负载的位置 : 定义工作负载的运行位置，包括国家/地区以及国家/地区中的区域。此信息用于映射到 AWS 区域和可用区。
    Global Infrastructures Regions and AZs
  • 定义和分组服务和资源 : 定义工作负载所需的服务。对于每项服务，指定类型、大小和所需资源数量。按职能定义资源组，如应用程序服务器或数据库存储。资源可属于多个组。
    Cloud Products
  • 按职能定义和分组用户 : 定义与工作负载交互的用户，侧重于用户的工作范畴及其使用工作负载的方式，而不是侧重于他们的身份或其在组织中的职位。将类似用户或职能分组在一起。您可以使用 AWS 托管策略作为指南。
    AWS Managed Policies for Job Functions
  • 定义操作 : 使用前面确定的位置、资源和用户，定义每项在其生命周期（开发、运行和停用）内实现工作负载成果所需的操作。根据每个位置的组（而不是组中的个别元素）确定操作。首先广泛读写，然后细化到每项服务的具体操作。
    Actions, Resources, and Condition Keys for AWS Services
  • 定义审核期 : 工作负载和组织要求可能会随时间而变化。定义工作负载审核计划，以确保其与组织重点保持一致。高频率的审核周期通常由安全要求、成本或使用情况对组织的重要性以及工作负载的变化量来确定。
  • 将策略编制成档 : 确保已定义的策略可按组织的要求访问。这些策略用于实施、维护和审计对环境的访问。

    • 制定方向性目标和执行性目标

  • 定义预期使用量水平 : 首先专注于使用量水平。与应用程序负责人、市场营销团队和更大的业务团队交流，了解工作负载的预期使用量水平。客户需求如何随时间而变化？是否会因季节性增长或营销活动而发生变化？
  • 定义工作负载资源和成本 : 定义使用量水平后，量化满足这些使用量水平所需的工作负载资源变化。您可能需要增加工作负载组件的资源大小或数量，增加数据传输，或者在特定级别将工作负载组件更改为不同的服务。详细说明每项要点的成本，以及当使用量发生变化时成本的变化。
  • 定义业务目标 : 从预期的使用量和成本变化中获取输出，将其与预期的技术变化或正在运行的任何计划相结合，制定工作负载目标。目标必须阐明使用量、成本和两者之间的关系。确保制定有组织的计划，例如培训和教育等能力培养，以防成本呈预期变化，而使用量无变化。
  • 定义执行性目标 : 对于定义的每个方向性目标，指定一个可衡量的执行性目标。如果方向性目标是提高工作负载的效率，则执行性目标将量化改进量，通常为每一美元支出的业务产出及获益时间。

    • 实施账户结构

  • 定义分离要求 : 分离要求涉及多项因素，包括安全性、可靠性和财务结构。按顺序阐明每项因素，并详细说明工作负载或工作负载环境是否应与其他工作负载分开。安全性可确保遵守访问和数据要求。可靠性可确保对限制进行管理，以便环境和工作负载不会影响其他项。财务结构可确保严格实施财务分离和问责制。常见分离示例有生产和测试工作负载在不同的账户中运行，或者使用单独的账户以便可以将发票和账单数据提供给第三方组织。
  • 定义分组要求 : 分组要求并不覆盖分离要求，而是用于协助管理。将无需分离的类似环境或工作负载分组在一起。例如，将一个或多个工作负载的多个测试或开发环境分组在一起。
  • 定义账户结构 : 使用这些分离和分组，为每个组指定一个账户，并确保持续满足分离要求。这些账户有成员账户或关联账户。通过将这些成员账户分组到一个主账户/付款人账户下，可以合并使用量，从而可以跨所有账户享有更大的批量折扣，并为所有账户提供一个账单。可以分离账单数据，并为每个成员账户提供其账单数据的单独视图。如果成员账户不能让任何其他账户看到自己的使用情况或账单数据，或者如果需要 AWS 提供单独的账单，请定义多个主账户/付款人账户。在这种情况下，每个成员账户都有自己的主账户/付款人账户。资源应始终放置在成员账户/关联账户中。主账户/付款人账户应只用于管理。
    AWS multiple account billing strategy
    Splitting the CUR and Sharing Access

    • 实施组和角色

  • 实施组 : 如有必要，请使用组织策略中定义的用户组实施相应的组。有关用户、组和身份验证的最佳实践，请参阅安全性支柱。
    Well-Architected Security Pillar
    Well-Architected Lab Basic Identity and Access
  • 实施角色和策略 : 使用组织策略中定义的操作，创建所需的角色和访问策略。有关角色和策略的最佳实践，请参阅安全性支柱。
    Well-Architected Security Pillar
    Well-Architected Lab Basic Identity and Access

    • 实施成本控制

  • 发布支出通知 : 使用定义的组织策略，制定 AWS 预算，当支出超出策略时发出通知。配置多个成本预算，每个账户一个，这样可通知您账户总支出。然后，在每个账户中，为该账户内的较小单元配置额外的成本预算。这些单元因您的账户结构而异。一些常见示例有 AWS 区域、工作负载（使用标签）或 AWS 服务。确保将电子邮件通讯组列表配置为通知的收件人，而不是个人的电子邮件账户。可以为超出金额的情况配置实际预算，或者使用预测预算通知预测使用量。
    Well-Architected Labs: Cost and Usage Governance
  • 实施使用量控制 : 使用定义的组织策略，实施 IAM 策略和角色，指定用户可执行的操作和无法执行的操作。一个 AWS 策略中可能包含多个组织策略。采用定义策略时所用的方式，首先大致进行，然后在每一步施加更细粒度的控制。服务限制也是一种有效的使用量控制措施。对所有账户实施正确的服务限制。
    Well-Architected Labs: Cost and Usage Governance
    Control access to AWS Regions using IAM policies
    AWS managed policies for job functions

    • 跟踪项目生命周期

  • 执行工作负载审核 : 按照组织策略的规定，审计现有项目。在审计方面投入的工作量应与组织的大致风险、价值或成本成比例。主要审计领域包括组织面临的事件或中断风险，或对组织所做的贡献（以收入或品牌声誉进行衡量）、工作负载的成本（以资源的总成本和运营成本进行衡量）和工作负载的使用量（以单位时间的组织产出量进行衡量）。如果这些领域在生命周期内发生变化，则需要对工作负载进行调整，例如全部停用或部分停用。