# COST 2  您如何管理使用情况？ 制定各种策略和机制，确保花费适当的成本来达到目标。采用制约与平衡方法，您可以在不超支的情况下进行创新。 **Topics** + [COST02-BP01 根据组织的要求制定各种策略](cost_govern_usage_policies.md) + [COST02-BP02 制定方向性目标和执行性目标](cost_govern_usage_goal_target.md) + [COST02-BP03 实施账户结构](cost_govern_usage_account_structure.md) + [COST02-BP04 实施组和角色](cost_govern_usage_groups_roles.md) + [COST02-BP05 实施成本控制](cost_govern_usage_controls.md) + [COST02-BP06 跟踪项目生命周期](cost_govern_usage_track_lifecycle.md) # COST02-BP01 根据组织的要求制定各种策略 制定策略，规定您的组织应该如何管理资源。策略应该涵盖资源和工作负载的成本，包括在资源生命周期内创建、修改和停用。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 了解组织的成本和驱动因素对于有效管理成本和使用量以及识别降低成本的机会至关重要。在组织中，通常会有多个团队运行多个工作负载。这些团队可能在不同的部门，每个部门都有其自己的收入来源。将资源成本分摊到工作负载、各个组织或产品拥有者可以推动更高效的资源使用行为，减少浪费。准确的成本和使用量监控能够帮助您了解各部门和产品如何盈利，并让您能够针对组织内的资源分配做出更明智的决策。组织中各层级的人员都了解使用量是推动变化的关键，因为使用量变化会导致成本变化。考虑采用多元方法来了解您的使用量和支出情况。 执行治理的第一步是按照组织要求来针对云的使用制定策略。这些策略定义组织如何使用云以及如何管理资源。策略应涵盖与成本或使用量有关的资源和工作负载的所有方面，包括资源生命周期内的创建、修改和停用。 策略应该简单易懂，能够在整个组织中有效实施。从广泛的、高层级的策略开始，例如允许在哪个地理区域使用，或者一天中应该运行资源的时间。逐步为各组织部门和工作负载细化策略。常见策略包括可以使用哪些服务和功能（例如，测试或开发环境中性能较低的存储区），以及哪些类型的资源可供不同团队使用（例如，开发账户中最大的资源规模是中等）。 **实施步骤** + **与团队成员会面： **要制定策略，请召集组织中的所有团队成员，详细说明他们的要求并相应地编制成档。采用迭代方法，首先大致进行，然后在每一步中不断细化到最小单元。团队成员包括与工作负载切身相关的人员（例如组织单位或应用程序负责人）以及支持小组（例如安全和财务团队）。 + ** 定义工作负载的位置： **定义工作负载的运行位置，包括国家/地区以及国家/地区中的区域。此信息用于映射到 AWS 区域和可用区。 + ** 定义和分组服务和资源： **定义工作负载所需的服务。对于每项服务，指定类型、大小和所需资源数量。按职能定义资源组，如应用程序服务器或数据库存储。资源可属于多个组。 + **按职能定义和分组用户： **定义与工作负载交互的用户，侧重于用户的工作范畴及其使用工作负载的方式，而不是侧重于他们的身份或其在组织中的职位。将类似用户或职能分组在一起。您可以使用 AWS 托管策略作为指南。 + ** 定义操作：** 使用前面确定的位置、资源和用户，定义每项在其生命周期（开发、运行和停用）内实现工作负载成果所需的操作。根据每个位置的组（而不是组中的个别元素）确定操作。首先广泛读写，然后细化到每项服务的具体操作。 + ** 定义审核期：** 工作负载和组织要求可能会随时间而变化。定义工作负载审核计划，以确保其与组织重点保持一致。 + **将策略编制成文档： **确保已定义的策略可按组织的要求访问。这些策略用于实施、维护和审计对环境的访问。 ## 资源 **相关文档：** + [AWS 针对工作职能的托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) + [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) + [AWS 服务的操作、资源和条件键](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html) + [云产品](https://aws.amazon.com/products/) + [使用 IAM 策略控制对 AWS 区域的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) + [全球基础设施区域和可用区](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) # COST02-BP02 制定方向性目标和执行性目标 制定工作负载的成本和使用量目标。方向性目标为组织在成本和使用情况方面指明了方向，执行性目标则为工作负载提供了可衡量的结果。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 为组织制定成本和使用量的方向性目标及执行性目标。方向性目标为组织提供有关预期结果的指引和方向。执行性目标则提供要实现的具体可衡量的结果。方向性目标的一个示例是：在略微（非线性）增加成本的情况下，显著提升平台使用量。执行性目标的一个示例是：在成本增长不到 5％ 的情况下，将平台使用量提升 20％。另一个常见的方向性目标是每 6 个月提高一次工作负载的效率。与之相关的执行性目标是，工作负载的每项输出成本每 6 个月降低 5％。 云工作负载的一个常见方向性目标是提高工作负载效率，即随着时间的推移降低工作负载每项业务成果的成本。建议为所有工作负载实施此目标，并设定执行性目标，例如每 6 至 12 个月将效率提高 5%。通过在成本优化中增强能力以及发布新服务和服务功能，可以在云中实现这一目标。 **实施步骤** + **定义预期使用量水平： **首先专注于使用量水平。与应用程序负责人、市场营销团队和更大的业务团队交流，了解工作负载的预期使用量水平。客户需求如何随时间而变化？是否会因季节性增长或营销活动而发生变化？ + ** 定义工作负载资源和成本： **定义使用量水平后，量化满足这些使用量水平所需的工作负载资源变化。您可能需要增加工作负载组件的资源大小或数量，增加数据传输，或者在特定级别将工作负载组件更改为不同的服务。详细说明每项要点的成本，以及当使用量发生变化时成本的变化。 + **定义业务目标： **从预期的使用量和成本变化中获取输出，将其与预期的技术变化或正在运行的任何计划相结合，制定工作负载目标。目标必须阐明使用量、成本和两者之间的关系。确认制定有组织的计划，例如培训和教育等能力培养项目，以防成本呈预期变化，而使用量无变化。 + **定义执行性目标： **对于定义的每个方向性目标，指定一个可衡量的执行性目标。如果方向性目标是提高工作负载的效率，则执行性目标将量化改进量，通常为每一美元支出的业务产出及获益时间。 ## 资源 **相关文档：** + [AWS 针对工作职能的托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) + [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) + [使用 IAM 策略控制对 AWS 区域 的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) # COST02-BP03 实施账户结构 实施与您的组织对应的账户结构。这有助于在整个组织内分摊和管理成本。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 AWS 拥有一个父级对多个子级的账户结构，通常称为管理账户（父级，之前称为付款人）账户-成员（子级，之前称为关联）账户。最佳实践是，无论组织规模或使用情况如何，始终至少有一个管理账户和一个成员账户。所有工作负载资源应仅驻留在成员账户内。 对于您应该拥有多少 AWS 账户这一问题，没有标准答案。评估当前和未来的运营和成本模型，以确保您的 AWS 账户结构反映了组织的目标。有些公司出于业务原因会创建多个 AWS 账户，例如： + 需要在组织部门、成本中心或特定工作负载之间实施管理和/或财务和计费隔离。 + AWS Service Limits 设置为特定于特殊工作负载。 + 工作负载和资源之间必须进行隔离和分离。 在 [AWS Organizations](https://aws.amazon.com/organizations/)中，[整合账单](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 会在一个或多个成员账户与管理账户之间创建结构。通过成员账户，您可以按团队隔离和区分成本和使用量。常见做法是每个组织部门（如财务、营销和销售）、每个环境生命周期（如开发、测试和生产）或每个工作负载（工作负载 a、b 和 c）具有单独的成员账户，然后使用整合账单将这些关联账户汇总在一起。 通过整合账单，您可以将多个成员 AWS 账户的付款整合至一个管理账户下，同时仍可查看每个关联账户的活动。由于成本和使用量在管理账户中汇总，因此，您可以最大限度地提高服务量折扣，并最大限度地利用承诺折扣（Savings Plans 和预留实例）来获得最高折扣。 [AWS Control Tower](https://aws.amazon.com/controltower/) 可以快速设置和配置多个 AWS 账户，确保治理符合您组织的要求。 **实施步骤** + **定义分离要求： **分离要求涉及多项因素，包括安全性、可靠性和财务结构。按顺序阐明每项因素，并详细说明工作负载或工作负载环境是否应与其他工作负载分开。安全性可确保遵守访问和数据要求。可靠性可确保对限制进行管理，以便环境和工作负载不会影响其他项。财务结构可确保严格实施财务分离和问责制。常见分离示例有生产和测试工作负载在不同的账户中运行，或者使用单独的账户以便可以将发票和账单数据提供给第三方组织。 + **定义分组要求：** 分组要求并不覆盖分离要求，而是用于协助管理。将无需分离的类似环境或工作负载分组在一起。例如，将一个或多个工作负载的多个测试或开发环境分组在一起。 + **定义账户结构： **使用这些分离和分组，为每个组指定一个账户，并确保持续满足分离要求。这些账户有成员账户或关联账户。通过将这些成员账户分组到一个管理账户或付款人账户下，可以合并使用量，从而可以跨所有账户享有更大的批量折扣，并为所有账户提供一个账单。可以分离账单数据，并为每个成员账户提供其账单数据的单独视图。如果成员账户不能让任何其他账户看到自己的使用情况或账单数据，或者，如果需要 AWS 提供单独的账单，请定义多个管理账户或付款人账户。在这种情况下，每个成员账户都有自己的管理账户或付款人账户。资源应始终放置在成员账户或关联账户中。管理账户或付款人账户应只用于管理。 ## 资源 **相关文档：** + [AWS 针对工作职能的托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) + [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) + [使用 IAM 策略控制对 AWS 区域的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) + [AWS Control Tower](https://aws.amazon.com/controltower/) + [AWS Organizations](https://aws.amazon.com/organizations/) + [整合账单](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) **相关示例：** + [拆分 CUR 和共享访问](https://wellarchitectedlabs.com/Cost/Cost_and_Usage_Analysis/300_Splitting_Sharing_CUR_Access/README.html) # COST02-BP04 实施组和角色 实施与策略一致的组和角色，控制每个组中谁可以创建、修改或停用实例和资源。例如，实施开发组、测试组和生产组。这适用于 AWS 服务和第三方解决方案。 **未建立这种最佳实践的情况下暴露的风险等级：** 低 ## 实施指导 制定策略后，可以在组织内创建用户的逻辑组和角色。这样，您就可以分配权限并控制使用量。从高层级的人员分组开始，这通常与组织部门和岗位角色（例如，IT 部门的系统管理员或财务主管）相一致。这些组将执行相似任务并需要相似访问权限的人员集结在一起。角色定义组必须做什么。例如，IT 部门的系统管理员需要创建所有资源的权限，而分析团队成员仅需要创建分析资源。 **实施步骤** + ** 实施组： **如有必要，请使用组织策略中定义的用户组实施相应的组。有关用户、组和身份验证的最佳实践，请参阅安全性支柱。 + ** 实施角色和策略： **使用组织策略中定义的操作，创建所需的角色和访问策略。有关角色和策略的最佳实践，请参阅安全性支柱。 ## 资源 **相关文档：** + [AWS 针对工作职能的托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) + [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) + [使用 IAM 策略控制对 AWS 区域 的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) + [Well-Architected 安全性支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) **相关示例：** + [Well-Architected 实验室：基本身份和访问权限](https://wellarchitectedlabs.com/Security/100_Basic_Identity_and_Access_Management_User_Group_Role/README.html) # COST02-BP05 实施成本控制 根据组织策略以及定义的组和角色来实施控制。这样可以确保成本只根据组织要求的规定产生，例如，使用 AWS Identity and Access Management（IAM）策略控制用户对区域或资源类型的访问。 **未建立此最佳实践暴露的风险等级：** 低 ## 实施指导 实施成本控制的第一步通常是进行相关设置，以便在发生成本或使用量超出组织策略的事件时触发通知。这样，您就可以迅速采取行动，并验证是否需要采取纠正措施，而不会限制工作负载或新活动或对它们产生负面影响。了解工作负载和环境限制后，可以强制实施治理。在 AWS 中，通知是通过 AWS Budgets 执行的，因此您可以定义 AWS 成本、使用量和承诺折扣（Savings Plans 和预留实例）的月度预算。可以在总成本级别（如所有成本）创建预算，也可以在更细粒度的级别创建预算，其中只包含特定的维度，如关联的账户、服务、标记或可用区。 在第二步中，您可以通过 [AWS Identity and Access Management](https://aws.amazon.com/iam/) （IAM）和 [AWS Organizations 服务控制策略 (SCP)，在 AWS 中强制实施治理策略。](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)借助 IAM，您可以安全地管理对 AWS 服务和资源的访问。您可以使用 IAM 控制谁能创建和管理 AWS 资源、可创建的资源类型以及可在何处创建。这样可以最大限度地减少创建不必要的资源。使用先前创建的角色和组，并分配 [IAM 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 以强制实施正确的使用量。SCP 用于集中管控组织中所有账户的最大可用权限，以确保您的账户始终在访问控制准则允许的范围内。SCP 仅在启用了所有功能的组织中可用，并且您可以将 SCP 配置为默认情况下拒绝或允许对成员账户执行操作。请参阅 [《Well-Architected 安全性支柱》白皮书](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 以了解有关实施访问管理的更多详细信息。 还可以通过管理服务限额来实施治理。通过确保为服务配额设置最低开销并进行准确维护，您可以最大限度地减少组织要求以外的资源创建。要实现这一点，您必须了解要求的改变速度、了解正在进行的项目（资源的创建和停用），以及影响可以实施的限额更改速度的因素。[服务限额](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 可用于在必要时增加配额。 **实施步骤** + ** 实施支出通知：** 使用定义的组织策略，制定 AWS 预算，当支出超出策略时发出通知。配置多个成本预算，每个账户一个，这样可通知您账户总支出。然后，在每个账户中，为该账户内的较小单元配置额外的成本预算。这些单元因您的账户结构而异。一些常见示例有 AWS 区域、工作负载（使用标签）或 AWS 服务。确保将电子邮件通讯组列表配置为通知的收件人，而不是个人的电子邮件账户。可以为超出金额的情况配置实际预算，或者使用预测预算通知预测使用量。 + ** 实施使用量控制： **使用定义的组织策略，实施 IAM 策略和角色，指定用户可执行的操作和无法执行的操作。一个 AWS 策略中可能包含多个组织策略。采用定义策略时所用的方式，首先大致进行，然后在每一步施加更细粒度的控制。服务限制也是一种有效的使用量控制措施。对所有账户实施正确的服务限制。 ## 资源 **相关文档：** + [针对工作职能的 AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) + [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) + [使用 IAM 策略控制对 AWS 区域的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) **相关示例：** + [Well-Architected 实验室：成本和使用情况治理](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) + [Well-Architected 实验室：成本和使用情况治理](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_2_Cost_and_Usage_Governance/README.html) # COST02-BP06 跟踪项目生命周期 跟踪、衡量并审计项目、团队和环境的生命周期，以避免使用不必要的资源并为此付费。 **未建立此最佳实践暴露的风险等级：** 低 ## 实施指导 确保跟踪工作负载的整个生命周期。这样可以确保在不再需要工作负载或工作负载组件时，可以将其停用或对其进行修改。这在发布新服务或功能时尤其有用。现有的工作负载和组件看起来仍在使用中，但是应该停用以将客户重定向到新服务。注意工作负载的先前阶段 – 在工作负载进入生产之后，可以停用以前的环境或大幅降低其容量，直到再次需要它们为止。 AWS 提供了许多可用于实体生命周期跟踪的管理和治理服务。您可以使用 [AWS Config](https://aws.amazon.com/config/) 或 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 提供一份详尽的 AWS 资源和配置清单。建议集成现有项目或资产管理系统来跟踪组织内的活动项目和产品。将当前系统与 AWS 提供的丰富事件集和指标结合起来，您就可以构建大量生命周期事件的视图并主动管理资源，以减少不必要的成本。 有关 Web 应用程序后端方面的建议， [《Well-Architected 卓越运营支柱》白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) 以了解有关实施实体生命周期跟踪的更多详细信息。 **实施步骤** + ** 执行工作负载审核： **按照组织策略的规定，审计现有项目。在审计方面投入的工作量应与组织的大致风险、价值或成本成比例。主要审计领域包括组织面临的事件或中断风险，或对组织所做的贡献（以收入或品牌声誉进行衡量）、工作负载的成本（以资源的总成本和运营成本进行衡量）和工作负载的使用量（以单位时间的组织产出量进行衡量）。如果这些领域在生命周期内发生变化，则需要对工作负载进行调整，例如全部停用或部分停用。 ## 资源 **相关文档：** + [AWS Config](https://aws.amazon.com/config/) + [AWS Systems Manager](https://aws.amazon.com/systems-manager/) + [针对工作职能的 AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) + [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) + [使用 IAM 策略控制对 AWS 区域的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)