COST02-BP01 根据组织的要求制定各种策略 - AWS Well-Architected Framework
实施指导实施步骤资源

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

制定策略，确定贵组织应该如何管理资源，并定期执行检查。策略应该涵盖资源和工作负载的成本，包括在资源生命周期内的创建、修改和停用。

未建立这种最佳实践的情况下暴露的风险等级： 高

实施指导

了解组织的成本和驱动因素，对于有效管理成本和使用量以及找到降低成本的机会至关重要。在组织中，通常会有多个团队运行多个工作负载。这些团队可能在不同的部门，每个部门都有其自己的收入来源。将资源成本分摊到工作负载、各个组织或产品负责人，这样既推动更高效的资源使用模式，又能减少浪费。准确的成本和使用量监控有助于您了解如何优化工作负载，以及各部门和产品的盈利能力。利用这些知识，您可以就在组织内的何处分配资源做出更明智的决策。组织中各层级的人员都了解使用量是推动变化的关键，因为使用量变化会导致成本变化。考虑采用多元方法来了解您的使用量和支出情况。

执行治理的第一步是按照组织要求来针对云的使用制定策略。这些策略定义组织如何使用云以及如何管理资源。策略应涵盖与成本或使用量有关的资源和工作负载的所有方面，包括资源生命周期内的创建、修改和停用。确认云环境中的任何更改都是遵循相应策略和程序实施的。在 IT 变更管理会议期间，提出问题以了解计划变更的成本影响（无论是增加还是减少）、业务理由以及预期结果。

策略应该简单易懂，能够在整个组织中有效实施。策略还需要易于遵守和解释（以便落实），并且要具体（不会在各团队之间造成误解）。此外，需要定期审查这些策略（例如我们的机制），并在客户业务状况或业务优先级发生变化时及时更新策略，以免导致策略过时。

从广泛的、高层级的策略开始，例如使用哪个地理区域，或者一天中应该运行资源的时间。逐步为各组织部门和工作负载细化策略。常见策略包括可以使用哪些服务和功能（例如，测试和开发环境中性能较低的存储），哪些类型的资源可供不同团队使用（例如，开发账户中最大规模的资源为中等大小），以及这些资源将使用多长时间（可能是临时使用、短期使用或在特定时间段内使用）。

策略示例

以下是侧重于成本优化的策略示例，您可以参考该策略来创建自己的云治理策略。请确保根据组织和利益相关者的要求调整策略。

  • 策略名称： 定义清晰的策略名称，例如“资源优化和成本削减策略”。

  • 目的： 解释为什么应使用此策略以及预期效果如何。此策略的目标是确认，在为了满足业务要求而部署和运行所需工作负载方面，有最低的成本要求。

  • 范围： 明确定义谁应使用此策略以及在什么情况下使用此策略，例如 DevOps X 团队，为美国东部的客户在 X 环境（生产或非生产）中使用此策略。

策略声明

  1. 根据工作负载的环境和业务需求（开发、用户验收测试、预生产或生产），选择美国东部区域 1 或多个美国东部区域。

  2. 安排 Amazon EC2 和 Amazon RDS 实例在早上 6 点到晚上 8 点之间运行 [美国东部标准时间 (EST)]。

  3. 在处于不活动状态 8 小时之后，停止所有未使用的 Amazon EC2 实例，在处于不活动状态 24 小时之后，停止未使用的 Amazon RDS 实例。

  4. 在非生产环境中处于不活动状态 24 小时之后，终止所有未使用的 Amazon EC2 实例。提醒 Amazon EC2 实例拥有者（根据标签）查看其生产环境中已停止的 Amazon EC2 实例，并告知他们，如果其 Amazon EC2 实例在 72 小时内未使用，将会被终止。

  5. 使用通用实例系列和大小（如 m5.large），然后使用 AWS Compute Optimizer，根据 CPU 和内存利用率调整实例大小。

  6. 优先使用自动扩缩，根据流量动态调整运行的实例数量。

  7. 为非关键工作负载使用竞价型实例。

  8. 查看容量需求，为可预测的工作负载使用实惠配套或预留实例，并通知云财务管理团队。

  9. 使用 Amazon S3 生命周期策略，将不经常访问的数据移动到更便宜的存储层。如果未定义保留策略，请使用 Amazon S3 Intelligent Tiering，自动将对象移动到存档层。

  10. 使用 Amazon CloudWatch 监控资源利用率并设置警报来触发扩展事件。

  11. 对于每个 AWS 账户，使用 AWS Budgets，根据成本中心和业务单位为您的账户设置成本和使用量预算。

  12. 使用 AWS Budgets 为账户设置成本和使用量预算，有助于您控制支出和避免意外账单，从而更好地控制成本。

过程： 提供实施本策略的详细过程，或参考介绍如何实施各个策略声明的其他文档。此部分应提供了关于如何执行策略要求的分步说明。

要实施此策略，您可以使用各种第三方工具或 AWS Config 规则来检查是否符合策略声明，并使用 AWS Lambda 函数触发自动修复操作。您也可以使用 AWS Organizations 来强制执行策略。此外，您应定期查看资源使用情况，并在必要时调整策略，以确保策略继续满足您的业务需求。

实施步骤

  • 与利益相关者会面： 要制定策略，让组织内的利益相关者（云业务办公室、工程师或实施策略的职能部门决策者）详细说明他们的要求并记录下来。采用迭代方法，首先大致进行，然后在每一步中不断细化到最小单元。团队成员包括与工作负载切身相关的人员（例如组织单位或应用程序负责人）以及支持小组（例如安全和财务团队）。

  • 完成确认： 确保团队就哪些人可以访问和部署到 AWS Cloud 的策略达成一致。确保这些人遵守组织的策略，并确认其资源创建符合商定的策略和程序。

  • 创建入职培训课程： 要求新组织成员完成入职培训课程，以建立成本意识并了解组织要求。他们可能会采取不同于以往经验的策略，或者根本不考虑这些策略。

  • 定义工作负载的位置： 定义工作负载的运行位置，包括国家/地区以及国家/地区中的区域。此信息用于映射到 AWS 区域 和可用区。

  • 定义和分组服务和资源： 定义工作负载所需的服务。对于每项服务，指定类型、大小和所需资源数量。按职能定义资源组，如应用程序服务器或数据库存储。资源可属于多个组。

  • 按职能定义和分组用户： 定义与工作负载交互的用户，侧重于用户的工作范畴及其使用工作负载的方式，而不是侧重于他们的身份或其在组织中的职位。将类似用户或职能分组在一起。您可以使用 AWS 托管策略作为指南。

  • 定义操作： 使用前面确定的位置、资源和用户，定义每项在其生命周期（开发、运行和停用）内实现工作负载成果所需的操作。根据每个位置的组（而不是组中的个别元素）确定操作。首先广泛读写，然后细化到每项服务的具体操作。

  • 定义审核期： 工作负载和组织要求可能会随时间而变化。定义工作负载审核计划，以确保其与组织重点保持一致。

  • 将策略编制成档： 验证已定义的策略是否可按组织的要求访问。这些策略用于实施、维护和审计对环境的访问。

资源

相关文档：

相关视频：

相关示例：