# 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 根据组织的要求制定各种策略 制定策略，确定组织应该如何管理资源，并定期执行检查。策略应该涵盖资源和工作负载的成本，包括在资源生命周期内的创建、修改和停用。 **在未建立这种最佳实践的情况下暴露的风险等级：**高 ## 实施指导 了解组织的成本和驱动因素，对于有效管理成本和使用情况以及找到降低成本的机会至关重要。在组织中，通常会有多个团队运行多个工作负载。这些团队可能在不同的组织单位，每个单位都有自己的收入来源。将资源成本分摊到工作负载、各个组织或产品负责人，这样既推动更高效的资源使用模式，又能减少浪费。准确的成本和使用情况监控有助于您了解如何优化工作负载，以及各部门和产品的盈利能力。利用这些知识，可以就在组织内的何处分配资源作出更明智的决策。组织中各层级的人员都了解使用情况是推动变化的关键，因为使用情况变化会导致成本变化。考虑采用多元方法来了解使用情况和支出情况。 执行治理的第一步是按照组织要求来针对云的使用制定策略。这些策略定义组织如何使用云以及如何管理资源。策略应涵盖与成本或使用情况有关的资源和工作负载的所有方面，包括资源生命周期内的创建、修改和停用。确认云环境中的任何更改都是遵循相应策略和程序实施的。在 IT 变更管理会议期间，提出问题以了解计划变更的成本影响（无论是增加还是减少）、业务理由以及预期结果。 策略应该简单易懂，能够在整个组织中有效实施。策略还需要易于遵守和解释（以便落实），并且要具体（不会在各团队之间造成误解）。此外，需要定期审查这些策略（例如我们的机制），并在客户业务状况或业务优先级发生变化时及时更新策略，以免导致策略过时。 从广泛的、高层级的策略开始，例如使用哪个地理区域，或者一天中应该运行资源的时间。逐步为各组织单位和工作负载细化策略。常见策略包括可以使用哪些服务和功能（例如，测试和开发环境中性能较低的存储），哪些类型的资源可供不同团队使用（例如，开发账户中最大规模的资源为中等大小），以及这些资源将使用多长时间（可能是临时使用、短期使用或在特定时间段内使用）。 **策略示例** 以下是侧重于成本优化的策略示例，可以参考该策略来创建自己的云治理策略。请确保根据组织和利益相关方的要求调整策略。 + **策略名称：**定义清晰的策略名称，例如“资源优化和成本削减策略”。 + **目的：**解释为什么应使用此策略以及预期结果如何。此策略的目标是确认，在为了满足业务要求而部署和运行所需工作负载方面，有最低的成本要求。 + **范围：**明确定义谁应使用此策略以及何时应使用此策略，例如 DevOps X 团队，为美国东部的客户在 X 环境（生产或非生产）中使用此策略。 **策略声明** 1. 根据工作负载的环境和业务要求（开发、用户验收测试、预生产或生产），选择 us-east-1 或多个美国东部区域。 1. 安排 Amazon EC2 和 Amazon RDS 实例在早上 6 点到晚上 8 点 [美国东部标准时间（EST）] 之间运行。 1. 在处于不活动状态 8 小时之后，停止所有未使用的 Amazon EC2 实例，在处于不活动状态 24 小时之后，停止未使用的 Amazon RDS 实例。 1. 在非生产环境中处于不活动状态 24 小时之后，终止所有未使用的 Amazon EC2 实例。提醒 Amazon EC2 实例拥有者（根据标签）查看其生产环境中已停止的 Amazon EC2 实例，并告知他们，如果其 Amazon EC2 实例在 72 小时内未使用，将会被终止。 1. 使用通用实例系列和大小（如 m5.large），然后使用 AWS Compute Optimizer，根据 CPU 和内存利用率调整实例大小。 1. 优先使用自动扩缩，根据流量动态调整运行的实例数量。 1. 为非关键工作负载使用竞价型实例。 1. 查看容量需求，为可预测的工作负载使用节省计划或预留实例，并通知云财务管理团队。 1. 使用 Amazon S3 生命周期策略，将不经常访问的数据移动到更便宜的存储层。如果未定义保留策略，请使用 Amazon S3 Intelligent Tiering，自动将对象移动到存档层。 1. 使用 Amazon CloudWatch 监控资源利用率并设置警报来触发扩展事件。 1. 对于每个 AWS 账户，使用 AWS Budgets，根据成本中心和业务单位为您的账户设置成本和使用情况预算。 1. 使用 AWS Budgets 为账户设置成本和使用情况预算，有助于您控制支出和避免意外账单，从而更好地控制成本。 **程序：**提供实施此策略的详细过程，或参考介绍如何实施各个策略声明的其他文档。此部分应提供关于如何执行策略要求的分步说明。 要实施此策略，可以使用各种第三方工具或 AWS Config 规则来检查是否符合策略声明，并使用 AWS Lambda 函数触发自动修复操作。您也可以使用 AWS Organizations 来强制执行策略。此外，您应定期查看资源使用情况，并在必要时调整策略，以确认策略继续满足业务需求。 ## 实施步骤 + **与利益相关方交流：**要制定策略，让组织内的利益相关方（云业务办公室、工程师或实施策略的职能部门决策者）详细说明他们的要求并记录下来。采用迭代方法，首先大致进行，然后在每一步中不断细化到最小单元。团队成员包括与工作负载切身相关的人员（例如组织单位或应用程序负责人）以及支持小组（例如安全和财务团队）。 + **获得确认：**确保团队就哪些人可以访问和部署到 AWS 云 的策略达成一致。确保这些人遵守组织的策略，并确认其资源创建符合商定的策略和程序。 + **创建入职培训课程：**要求新组织成员完成入职培训课程，以建立成本意识并了解组织要求。他们可能会采取不同于以往经验的策略，或者根本不考虑这些策略。 + **定义运行工作负载的位置：**定义工作负载的运行位置，包括国家/地区以及国家/地区中的区域。此信息用于映射到 AWS 区域 和可用区。 + **定义服务和资源并对其进行分组：**定义工作负载所需的服务。对于每项服务，指定类型、大小和所需资源数量。按职能定义资源组，如应用程序服务器或数据库存储。资源可属于多个组。 + **定义用户并按职能对其进行分组：**定义与工作负载交互的用户，侧重于用户的工作范畴及其使用工作负载的方式，而不是侧重于他们的身份或其在组织中的职位。将类似用户或职能分组在一起。可以使用 AWS 托管式策略作为指南。 + **定义操作：**使用前面确定的位置、资源和用户，定义每项在其生命周期（开发、运行和停用）内实现工作负载成果所需的操作。根据每个位置的组（而不是组中的个别元素）确定操作。首先广泛读写，然后细化到每项服务的具体操作。 + **定义审核期：**工作负载和组织要求可能会随着时间的推移而发生变化。定义工作负载审核计划，确保其与组织优先事项保持一致。 + **记录策略：**确认已定义的策略是否可按组织的要求访问。这些策略用于实施、维护和审核对环境的访问。 ## 资源 **相关文档：** + [云中的变更管理](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-cloud.html) + [针对工作职能的 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) + [AWS 管理和治理](https://aws.amazon.com/products/management-and-governance/) + [使用 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/) **相关视频：** + [大规模的 AWS 管理和治理](https://www.youtube.com/watch?v=xdJSUnPcPPI) # COST02-BP02 实施方向性目标和执行性目标 实施工作负载的成本和使用情况方向性目标和执行性目标。方向性目标为组织在预期结果方面指明了方向，而执行性目标则提供了要为工作负载实现的具体可衡量结果。 **在未建立这种最佳实践的情况下暴露的风险等级：**高 ## 实施指导 为组织制定成本和使用情况方向性目标和执行性目标。作为一个在 AWS 上不断发展壮大的组织，针对成本优化设定方向性目标并进行跟踪，这一点非常重要。这些目标或[关键绩效指标（KPI）](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metric-the-touchstone-of-your-it-planning-and-evaluation/)可以是按需支出百分比等内容，也可以是采用某些优化服务（比如 AWS Graviton 实例或 gp3 EBS 卷类型）。设定可衡量且可实现的方向性目标，有助于您衡量效率的提高情况，这对于业务运营不可或缺。方向性目标为组织提供有关预期结果的指引和方向。 执行性目标则明确要实现的具体可衡量的结果。简言之，方向性目标是指您前进的方向，而执行性目标就是在这个方向上的进展情况，以及应何时实现这个目标（使用具体、可衡量、可分配、切合实际、适时的指导原则，即 SMART 指导原则）。方向性目标的一个示例是：在略微（非线性）增加成本的情况下，显著提升平台使用量。执行性目标的一个示例是：在成本增长不到 5% 的情况下，将平台使用量提升 20%。另一个常见的方向性目标是每 6 个月提高一次工作负载的效率。相应的执行性目标则是，需要每 6 个月将各项业务指标的成本缩减 5%。使用正确的指标，合理计算来为组织设定 KPI。可以从基本 KPI 开始，以后再根据业务需求进行改进。 就成本优化而言，其方向性目标是提高工作负载效率，这对应于逐步降低每项业务成果的工作负载成本。为所有工作负载实施此方向性目标，并设定执行性目标，例如每 6 至 12 个月将效率提高 5%。在云端，可以通过培养成本优化能力以及发布新服务和功能来做到这一点。 执行性目标是您为实现方向性目标而要达到的可量化基准，这些基准将您的实际结果与执行性目标进行比较。使用 KPI 为计算服务（例如竞价型实例采用、Graviton 采用、最新实例类型和按需覆盖范围）、存储服务（例如 EBS GP3 采用、过时的 EBS 快照和 Amazon S3 Standard 存储）或数据库服务使用情况（例如 RDS 开源引擎、Graviton 采用和按需覆盖范围）的单位成本建立基准。这些基准和 KPI 有助于验证您是否通过最经济高效的方式使用 AWS 服务。 下表提供了标准 AWS 指标列表以供参考。每个组织都可以为这些 KPI 设定不同的执行性目标值。 | 类别 | KPI | 描述 | | --- | --- | --- | | 计算 | EC2 使用情况覆盖率 | 使用 SP\$1RI\$1Spot 的 EC2 实例（以成本或小时计）与 EC2 实例的总计（以成本或小时计）的比较 | | 计算 | 计算 SP/RI 使用率 | 使用的 SP 或 RI 小时数与可用 SP 或 RI 总小时数的比较 | | 计算 | EC2/小时成本 | EC2 成本除以该小时内运行的 RDS 实例数量 | | 计算 | vCPU 成本 | 所有实例每个 vCPU 的成本 | | 计算 | 最新一代实例 | Graviton（或其他现代实例类型）上的实例百分比 | | 数据库 | RDS 覆盖率 | 使用 RI 的 RDS 实例（以成本或小时计）与 RDS 实例的总计（以成本或小时计）的比较 | | 数据库 | RDS 使用率 | 使用的 RI 小时数与可用 RI 总小时数的比较 | | 数据库 | RDS 正常运行时间 | RDS 成本除以该小时内运行的 RDS 实例数量 | | 数据库 | 最新一代实例 | Graviton（或其他现代实例类型）上的实例百分比 | | 存储 | 存储使用率 | 优化的存储成本（例如 Glacier、Deep Archive 或不频繁访问）除以总存储成本 | | 标记 | 未标记的资源 | Cost Explorer： 1. 筛选出服务抵扣金、折扣、税款、退款、商城，并复制最新的月度成本 2. 在 Cost Explorer 中选择**仅显示未标记的资源** 3. 将**未标记资源**中的数字除以每月成本。 | 此表包含执行性目标值或基准值，这些值应根据您的组织目标计算得出。您需要衡量业务的某些指标，并了解该工作负载的业务成果，以便确立准确、切合实际的 KPI。在评估组织内部的绩效指标时，要区分用于不同目的的各类指标。这些指标主要衡量技术基础设施的性能和效率，而不是直接衡量总体业务影响。例如，它们可能会跟踪服务器响应时间、网络延迟或系统正常运行时间。要评测基础设施能否有效支持组织的技术运营，这些指标必不可少。但是，您无法通过它们直接了解更广泛的业务目标，例如客户满意度、收入增长或市场份额。要全面了解业务绩效，请使用与业务成果直接相关的战略业务指标，补充这些效率指标。 您需要能够近乎实时地监控 KPI 及相关的成本节省机会，并不断跟踪进度。要着手定义和跟踪 KPI 目标，我们建议使用 [Cloud Intelligence Dashboard](https://wellarchitectedlabs.com/cloud-intelligence-dashboards/)（CID）中的 KPI 控制面板。根据来自成本和使用情况报告（CUR）的数据，KPI 控制面板提供了一系列建议的成本优化 KPI，能够设定自定义的方向性目标并不断跟踪进度。 如果通过其他解决方案来设定和跟踪 KPI 方向性目标，请务必让组织中的所有云财务管理利益相关方都采用这些方法。 ### 实施步骤 + **定义预期使用量：**首先，重点关注使用水平。与应用程序负责人、营销团队和更大的业务团队交流，了解工作负载的预期使用水平。客户需求可能如何随时间而变化？会因季节性增长或营销活动发生哪些变化？ + **定义工作负载资源和成本:**定义使用水平后，量化满足这些使用量所需的工作负载资源变化。您可能需要增加工作负载组件的资源大小或数量，增加数据传输，或者在特定级别将工作负载组件更改为不同的服务。明确每个关键点的成本，并预测使用情况发生变化时的成本变化。 + **定义业务目标：**从预期的使用情况和成本变化中获取输出，将其与预期的技术变化或正在开展的任何计划相结合，制定工作负载目标。方向性目标必须阐明使用情况和成本，以及两者之间的关系。方向性目标必须简明扼要，并能让人们了解企业对结果的期望（例如，确保未使用的资源保持在一定的成本水平以下）。您不需要为每种未使用的资源类型定义方向性目标，也不需要定义会导致方向性目标和执行性目标损失的成本。确认制定有组织计划（例如培训和教育等能力培养计划），以防成本呈预期变化，而使用情况无变化。 + **定义执行性目标：**对于定义的每个方向性目标，指定一个可衡量的执行性目标。如果方向性目标是提高工作负载的效率，则执行性目标将量化改进量（通常为每一美元支出的业务产出）及获益时间。例如，可以设定一个方向性目标，最大限度地减少因过度预置而造成的浪费。有了此方向性目标，执行性目标可以是，因第一层生产工作负载中的计算过度预置而造成的浪费不应超过层级计算成本的 10%。此外，第二个执行性目标可以是，因第二层生产工作负载中的计算过度预置而造成的浪费不应超过层级计算成本的 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/) + [S.M.A.R.T. 目标](https://en.wikipedia.org/wiki/SMART_criteria) + [How to track your cost optimization KPIs with the CID KPI Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/) **相关视频：** + [Well-Architected Lab：方向性目标和执行性目标（第 100 级）](https://catalog.workshops.aws/well-architected-cost-optimization/en-US/2-expenditure-and-usage-awareness/150-goals-and-targets) **相关示例：** + [什么是单位指标？](https://aws.amazon.com/blogs/aws-cloud-financial-management/what-is-a-unit-metric/) + [选择单位指标来支持您的业务](https://aws.amazon.com/blogs/aws-cost-management/selecting-a-unit-metric-to-support-your-business/) + [实践中的单位指标 – 经验教训](https://aws.amazon.com/blogs/aws-cost-management/unit-metrics-in-practice-lessons-learned/) + [单位指标如何有助于在业务职能之间建立一致性](https://aws.amazon.com/blogs/aws-cost-management/unit-metrics-help-create-alignment-between-business-functions/) # COST02-BP03 实施账户结构 实施与组织对应的账户结构。这有助于在整个组织内分摊和管理成本。 **在未建立这种最佳实践的情况下暴露的风险等级：**高 ## 实施指导 AWS Organizations 允许创建多个 AWS 账户，这有助于在扩展 AWS 上的工作负载时集中管理环境。可以通过在组织单位（OU）结构中分组 AWS 账户，并在每个 OU 下创建多个 AWS 账户，对组织层次结构进行建模。要创建账户结构，首先需要确定哪个 AWS 账户 将成为管理账户。之后，可以按照[管理账户最佳实践](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html)和[成员账户最佳实践](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)，根据设计的账户结构创建新 AWS 账户 或选择现有账户作为成员账户。 建议无论组织规模或使用情况如何，始终至少有一个管理账户和一个与之链接的成员账户。所有工作负载资源应仅驻留在成员账户中，不应在管理账户中创建任何资源。对于您应该拥有多少个 AWS 账户 这一问题，没有标准答案。评测当前和未来的运营和成本模型，确保 AWS 账户 结构反映了组织的目标。有些公司出于业务原因会创建多个 AWS 账户，例如： + 需要在组织部门、成本中心或特定工作负载之间实施管理或财务和计费隔离。 + AWS 服务限制设置为针对特定工作负载。 + 必须对工作负载和资源进行隔离和分离。 在 [AWS Organizations](https://aws.amazon.com/organizations/) 内，[整合账单](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)会在一个或多个成员账户与管理账户之间创建结构。通过成员账户，可以按组隔离和区分成本和使用情况。常见做法是每个组织部门（如财务、营销和销售）、每个环境生命周期（如开发、测试和生产）或每个工作负载（工作负载 a、b 和 c）具有单独的成员账户，然后使用整合账单将这些关联账户汇总在一起。 通过整合账单，可以将多个成员 AWS 账户 的付款整合至一个管理账户下，同时仍可查看每个关联账户的活动。由于成本和使用情况在管理账户中汇总，因此，可以最大限度地提高服务量折扣，并最大限度地利用承诺折扣（节省计划和预留实例）来获得最高折扣。 下图显示了如何对组织单位（OU）使用 AWS Organizations，以对多个账户进行分组，并在每个 OU 下放置多个 AWS 账户。建议将 OU 用于各种应用场景和工作负载，这提供了组织账户的模式。 ![\[树状图中显示了如何在组织单位下对多个账户进行分组。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/aws-organizations-ou-grouping.png) [AWS Control Tower](https://aws.amazon.com/controltower/) 可以快速设置和配置多个 AWS 账户，确保治理符合组织要求。 **实施步骤** + **定义分离要求：**分离要求涉及多项因素，包括安全性、可靠性和财务结构。按顺序阐明每项因素，并详细说明工作负载或工作负载环境是否应与其他工作负载分开。安全性有助于满足访问和数据要求。可靠性管理限制，以便环境和工作负载不会影响其他项。定期查看 Well-Architected Framework 的安全性和可靠性支柱，并遵循提供的最佳实践。财务结构创建严格的财务分离（不同的成本中心、工作负载所有权和问责制）。常见的分离示例包括在单独的账户中运行生产和测试工作负载，或使用单独的账户，以便可以将发票和账单数据提供给组织中的单个业务单位或部门，或拥有该账户的利益相关方。 + **定义分组要求：**分组要求并不覆盖分离要求，而是用于协助管理。将无需分离的类似环境或工作负载分组在一起。例如，将一个或多个工作负载的多个测试或开发环境分组在一起。 + **定义账户结构：**使用这些分离和分组，为每个组指定一个账户，并确保持续满足分离要求。这些账户有成员账户或关联账户。通过将这些成员账户分组到一个管理账户或付款人账户下，可以合并使用量，从而可以跨所有账户享有更大的批量折扣，这为所有账户提供一个账单。可以分离账单数据，并为每个成员账户提供其账单数据的单独视图。如果成员账户不能让任何其他账户看到自己的使用情况或账单数据，或者，如果需要 AWS 提供单独的账单，请定义多个管理账户或付款人账户。在这种情况下，每个成员账户都有自己的管理账户或付款人账户。资源应始终放置在成员账户或关联账户中。管理账户或付款人账户应只用于管理。 ## 资源 **相关文档：** + [使用成本分配标签](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) + [针对工作职能的 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/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html)和[成员账户](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)的最佳实践 + [使用多个账户整理您的 AWS 环境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) + [开启共享的预留实例和节省计划折扣](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html) + [整合账单](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) + [整合账单](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) **相关视频：** + [AWS Organizations 简介](https://www.youtube.com/watch?v=T4NK8fv8YdI) + [为 AWS Organizations 设置使用最佳实践的多账户 AWS 环境](https://www.youtube.com/watch?v=uOrq8ZUuaAQ) **相关示例：** + [为电信公司定义 AWS 多账户策略](https://aws.amazon.com/blogs/industries/defining-an-aws-multi-account-strategy-for-telecommunications-companies/) + [Best Practices for Optimizing AWS 账户](https://aws.amazon.com/blogs/architecture/new-whitepaper-provides-best-practices-for-optimizing-aws-accounts/) + [Best Practices for Organizational Units with AWS Organizations](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog) # COST02-BP04 实施组和角色 实施与策略一致的组和角色，控制每个组中谁可以创建、修改或停用实例和资源。例如，实施开发组、测试组和生产组。这适用于 AWS 服务和第三方解决方案。 **在未建立这种最佳实践的情况下暴露的风险等级：**低 ## 实施指导 用户角色和组是设计和实施安全、高效的系统的基本构件。角色和组有助于组织在控制力需求与灵活性和生产率要求之间取得平衡，最终满足组织目标和用户需求。正如 AWS Well-Architected Framework 安全性支柱的[身份与访问管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html)部分所建议的那样，您需要强大的身份管理和权限，以便在适当的条件下为合适的人员提供对正确资源的访问权限。用户仅获得完成任务所需的访问权限。这可最大限度地降低与未经授权访问或滥用相关的风险。 制定策略后，可以在组织内创建逻辑组和用户角色。这让您可以分配权限、控制使用情况，并有助于实施强健的访问控制机制，防止未经授权访问敏感信息。从大致的人员分组开始，这通常与组织单位和岗位角色（例如，IT 部门的系统管理员、财务主管或业务分析师）对应。这些组将执行相似任务并需要相似访问权限的人员划分在一起。角色定义组必须做什么。管理组和角色的权限比管理单个用户的权限更容易。角色和组可一致且系统性地为所有用户分配权限，防止出现错误和不一致。 当用户的角色发生变化时，管理员可以在角色或组级别上调整访问权限，而不是重新配置单个用户账户。例如，IT 部门的系统管理员需要创建所有资源的权限，而分析团队成员仅需要创建分析资源。 ### 实施步骤 + **实施组：**如有必要，请使用组织策略中定义的用户组实施相应的组。有关用户、组和身份验证的最佳实践，请参阅 AWS Well-Architected Framework 的[安全性支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)。 + **实施角色和策略：**使用组织策略中定义的操作，创建所需的角色和访问策略。有关角色和策略的最佳实践，请参阅 AWS Well-Architected Framework 的[安全性支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)。 ## 资源 **相关文档：** + [针对工作职能的 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 Well-Architected Framework 安全性支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) + [AWS Identity and Access Management（IAM）](https://aws.amazon.com/iam/) + [AWS Identity and Access Management 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) **相关视频：** + [为何使用身份与访问管理](https://www.youtube.com/watch?v=SXSqhTn2DuE) **相关示例：** + [使用 IAM 策略控制对 AWS 区域 的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) + [开启您的云财务管理之旅：云成本运营](https://aws.amazon.com/blogs/aws-cloud-financial-management/op-starting-your-cloud-financial-management-journey/) # COST02-BP05 实施成本控制 根据组织策略以及定义的组和角色来实施控制。这样可以确保成本只根据组织要求的规定产生，例如，控制用户对区域或资源类型的访问。 **在未建立这种最佳实践的情况下暴露的风险等级：**中 ## 实施指导 实施成本控制的第一步通常是进行相关通知设置，以便在发生成本或使用情况超出策略的事件时触发通知。可以迅速采取行动，并验证是否需要采取纠正措施，而不会限制工作负载或新活动，抑或是对它们产生负面影响。了解工作负载和环境限制后，就可以强制实施治理。[AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 允许您为 AWS 成本、使用情况和承诺折扣（节省计划和预留实例）设置通知和定义每月预算。可以在总成本级别（如所有成本）创建预算，也可以在更细粒度的级别创建预算，其中只包含特定的维度，如关联的账户、服务、标签或可用区。 使用 AWS Budgets 设置预算限制后，请使用 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 来降低意外成本。AWS Cost Anomaly Detection 是一种成本管理服务，它使用机器学习来持续监控成本和使用情况，以检测异常支出。它可以帮助您识别异常支出和根本原因，以便您可以快速采取行动。首先，在 AWS Cost Anomaly Detection 中创建成本监控，然后通过设置美元阈值来选择提醒首选项（例如，对影响大于 1000 美元的异常情况发出提醒）。收到提醒后，可以分析造成异常情况的根本原因，以及对成本的影响。您还可以在 AWS Cost Explorer 中监控并执行自己的异常分析。 在 AWS 中通过 [AWS Identity and Access Management](https://aws.amazon.com/iam/) 和 [AWS Organizations 服务控制策略（SCP）强制执行治理策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.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)》。 也可以通过 [AWS 服务配额](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)管理实施治理。通过确保为服务配额设置最低开销并进行准确维护，可以最大限度地减少组织要求以外的资源创建。要实现这一点，必须了解要求的改变速度、正在进行的项目（资源的创建和停用），并考虑配额更改的实施速度。必要时，[服务配额](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)可用于增加配额。 **实施步骤** + **实施支出通知：**使用定义的组织策略，创建 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 以在支出超出策略时收到通知。配置多个成本预算，每个账户一个，以通知您账户的总支出情况。在每个账户中为该账户内的较小单元配置额外的成本预算。这些单元因账户结构而异。一些常见示例包括 AWS 区域、工作负载（使用标签）或 AWS 服务。将电子邮件通讯组列表配置为通知的收件人，而不是个人的电子邮件账户。可以为超出金额的情况配置实际预算，或者使用预测预算通知预测使用情况。还可以预配置 AWS Budgets 操作，以强制实施特定 IAM 或 SCP 策略，或停止目标 Amazon EC2 或 Amazon RDS 实例。可以自动执行预算操作，也可以要求工作流程审批。 + **对异常支出实施通知：**使用 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 降低组织中的意外成本，并分析潜在异常支出的根本原因。创建成本监控来以指定粒度识别异常支出，并在 AWS Cost Anomaly Detection 中配置通知后，它会在检测到异常支出时向您发送提醒。这将让您能够分析导致异常的根本原因，并了解对成本的影响。配置 AWS Cost Anomaly Detection 时使用 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/) + [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) + [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) + [控制您的 AWS 成本](https://aws.amazon.com/getting-started/hands-on/control-your-costs-free-tier-budgets/) **相关视频：** + [如何使用 AWS Budgets 来跟踪我的支出和使用情况](https://www.youtube.com/watch?v=Ris23gKc7s0) **相关示例：** + [IAM 访问管理策略示例](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html) + [服务控制策略示例](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) + [AWS Budgets 操作](https://aws.amazon.com/blogs/aws-cloud-financial-management/get-started-with-aws-budgets-actions/) + [创建 IAM 策略以使用标签控制对 Amazon EC2 资源的访问权限](https://aws.amazon.com/premiumsupport/knowledge-center/iam-ec2-resource-tags/) + [限制 IAM Identity 对特定 Amazon EC2 资源的访问权限](https://aws.amazon.com/premiumsupport/knowledge-center/restrict-ec2-iam/) + [Slack integrations for Cost Anomaly Detection using Amazon Q Developer in chat applications](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/) # COST02-BP06 跟踪项目生命周期 跟踪、衡量并审核项目、团队和环境的生命周期，以避免使用不必要的资源并为此付费。 **在未建立这种最佳实践的情况下暴露的风险等级：**低 ## 实施指导 通过有效地跟踪项目生命周期，组织可以加强规划、管理和资源优化，进而更好地控制成本。通过跟踪获得的见解对于作出明智的决策非常宝贵，有助于提高项目的成本效益和整体成功率。 跟踪工作负载的整个生命周期，有助于您了解何时不再需要工作负载或工作负载组件。现有的工作负载和组件可能看起来仍在使用中，但是当 AWS 发布新的服务或功能时，它们可能会被停用或采用。检查工作负载的先前阶段。在工作负载进入生产之后，可以停用以前的环境或大幅降低其容量，直到再次需要它们为止。 可以用时间范围或提醒标记资源，以便确定工作负载的审核时间。例如，如果上一次审核开发环境是在几个月前，现在可能非常适合再次审核该环境，以探究是否能采用新服务或该环境是否在使用中。可以在 AWS 上使用 [myApplications](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/aws-myApplications.html) 对应用程序进行分组和标记，以管理和跟踪元数据，例如重要性、环境、上次审查时间和成本中心。您既可以跟踪工作负载的生命周期，也可以监控和管理应用程序的成本、运行状况、安全态势和性能。 AWS 提供了各种可用于实体生命周期跟踪的管理和治理服务。可以使用 [https://aws.amazon.com/config/](https://aws.amazon.com/config/) 或 [https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/) 提供一份详尽的 AWS 资源和配置清单。建议集成现有项目或资产管理系统，以跟踪组织内的活动项目和产品。将当前系统与 AWS 提供的丰富事件和指标集结合起来，您就可以构建重要生命周期事件的视图并主动管理资源，以减少不必要的成本。 与[应用程序生命周期管理（ALM）](https://aws.amazon.com/what-is/application-lifecycle-management/)类似，跟踪项目生命周期应涉及多个流程、工具、团队协同工作，例如设计和开发、测试、生产、支持及工作负载冗余。 通过仔细监控项目生命周期的每个阶段，组织可以获得重要的见解并增强掌控力，从而促进成功的项目规划、实施和完成。这种仔细的监督可以确保项目不仅符合质量标准，而且在预算范围内按时交付，从而提高总体成本效率。 有关实施实体生命周期跟踪的更多详细信息，请参阅《[https://aws.amazon.com/architecture/well-architected/](https://aws.amazon.com/architecture/well-architected/)》。 ### 实施步骤 + **建立项目生命周期监控流程：**[云卓越中心团队](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_cloud_financial_management_function.html)必须建立项目生命周期监控流程。建立结构化的系统化方法来监控工作负载，以改善项目的控制、可见性和性能。使监控过程透明化、协作化并注重持续改进，以最大限度地提高其有效性和价值。 + **执行工作负载审查：**根据组织策略的定义，定期安排时间审核现有项目并执行工作负载审查。在审核方面投入的工作量应与组织的大致风险、价值或成本成比例。主要审核领域包括组织面临的意外事件或中断风险，或对组织所做的贡献（以收入或品牌声誉进行衡量）、工作负载的成本（以资源的总成本和运营成本进行衡量）和工作负载的使用情况（以单位时间的组织产出量进行衡量）。如果这些领域在生命周期内发生变化，则需要对工作负载进行调整，例如全部停用或部分停用。 ## 资源 **相关文档：** + [Guidance for Tagging on AWS](https://aws.amazon.com/solutions/guidance/tagging-on-aws/) + [什么是 ALM（应用程序生命周期管理）？](https://aws.amazon.com/what-is/application-lifecycle-management/) + [针对工作职能的 AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) **相关示例：** + [使用 IAM 策略控制对 AWS 区域 的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) **相关工具** + [AWS Config](https://aws.amazon.com/config/) + [AWS Systems Manager](https://aws.amazon.com/systems-manager/) + [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) + [AWS Organizations](https://aws.amazon.com/organizations/) + [AWS CloudFormation](https://aws.amazon.com/cloudformation/?c=mg&sec=srv)