Amazon SAP-C02: 成本优化与治理 — 学习指南

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

属于 AWS Solutions Architect Professional SAP-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

成本可见性、分配与报告

要实现真正的成本可见性，首先需要实施一致且强制的成本分配以及高保真度的报告。部署 AWS Organizations 并指定一个付款人账户，启用整合账单功能，以集中管理发票，同时保持各账户费用的独立核算。激活 AWS Cost and Usage Report (CUR)，设置小时级粒度、S3 交付和 Amazon Athena 集成，以便您可以运行即席查询，并将成本记录与资源元数据进行关联。实施严格的标签策略：定义一套强制性的成本分配标签（如 environment、project、owner、business-unit 和 cost-center），并使用 CloudFormation StackSets 在资源预置时强制应用这些标签，通过 Service Control Policies 限制创建未打标签的资源，并利用 AWS Config Rules 评估和自动修复缺失的标签。结合使用 Cost Explorer 与预留实体和容量优化报告，以了解支出趋势和闲置容量。常见的陷阱包括：标签覆盖不完整导致内部费用分摊不准确，仅依赖 Billing Console 而不进行 CUR 分析，以及未能捕获跨账户或跨区域的数据传输成本。决策权衡通常在于及时性与粒度之间：启用小时级 CUR 和 Athena 会产生更高的处理成本，但能提供业务决策所需的精确归因；而粗略的月度摘要虽然运营成本较低，但会掩盖瞬时的高峰和低效的资源。

承诺使用定价、容量优化与购买策略

优化承诺使用支出需要在 Savings Plans、Reserved Instances 和 Spot 等瞬时定价模型之间做出选择，同时通过容量优化来使资源容量与工作负载特征相匹配。首先利用 Cost Explorer 和 Compute Optimizer 的使用模式数据，识别稳态的 CPU/内存基线，并寻找更换实例族或实例大小的机会。当工作负载需要在不同实例类型和区域间保持灵活性时，优先选择 Compute Savings Plans；当特定的实例族和可用区（AZ）部署能够获得更深折扣时，则使用 EC2 Instance Reservations。对于容错的批处理和微服务工作负载，可以利用 Spot 实例；但对于没有稳健检查点机制的单可用区有状态服务，应避免使用 Spot。容量优化应将来自 Compute Optimizer 和 Trusted Advisor 的自动建议与手动审查相结合，以避免因过度缩减容量而影响性能。注意一些陷阱，包括：在业务预测不确定时过度承诺购买 3 年期 RI，因使用情况未打标签或账户隔离而导致 Savings Plans 利用率不足，以及在未经测试的情况下假定实例族之间可以互换。权衡通常在于成本与运营灵活性之间：更深的长期折扣能降低单位成本，但如果需求下降或架构变更，会增加业务风险；相反，Spot 和按需实例以较高的单位成本提供了敏捷性。

治理、策略执行与自动修复

集中式治理建立起防护机制，以防止不受控制的支出，同时赋能自治的团队。使用 AWS Control Tower 或一个架构良好的 Organizations 基线来预置账户，这些账户将带有预配置的防护机制和集中式日志记录。应用 Service Control Policies 来限制使用高成本服务或未经批准的区域，并部署 AWS Config Rules 来检测不合规的配置，例如公开的 S3 存储桶、过大的实例类型或缺少加密和标签。将 AWS Budgets 与自动化操作集成：设置预算阈值，以触发 SNS 通知，并通过 Lambda 或 Systems Manager 执行自动修复（例如，停止/终止闲置实例或降低 RDS 实例规格）。Trusted Advisor 通过提供成本优化检查来补充治理，但不要将其视为唯一的信号；Trusted Advisor 的免费检查项目有限，需要商业或企业级支持计划才能获得详细的洞察。常见的陷阱包括：过于严格地使用 SCP 从而阻碍了合法的运维变更，仅依赖通知而没有自动化的强制执行，以及授予过多的 IAM 权限导致策略可被绕过。通过权衡业务自主性与风险来评估治理决策：更严格的控制可以防止成本失控，但可能会减慢开发速度，并需要一个明确定义的例外处理流程。

成本感知架构模式与数据传输考量

架构选择深刻影响着持续产生的成本。将高流量内容和全球分发任务卸载到 Amazon CloudFront，以减少 S3 源站请求和出口费用；仅当延迟优势能够抵消更高传输成本时，才使用 S3 Transfer Acceleration。对于跨可用区（AZ）和跨区域的架构，请记住可用区之间的数据传输可能会收费；在可能的情况下，设计时应考虑可用区内的流量局部性，或通过区域性服务聚合流量。对于大文件分发，可考虑使用 Amazon S3 的分段上传和生命周期策略、用于不可预测访问模式的 S3 Intelligent-Tiering，以及用于单可用区工作负载的 EFS One Zone（在这种场景下，通过权衡弹性来降低成本）。在迁移容器工作负载时，需评估 Fargate 与基于 EC2 的 ECS/EKS：Fargate 提高了运维简便性并减少了集群管理开销，但通常每 vCPU/内存的成本要高于充分利用的、由 EC2 Spot 实例支持的节点组。常见的陷阱包括低估跨区域复制的成本、将高流转率的日志错误地放置在不频繁访问存储类中，以及假设 VPC 端点是免费的——它们虽然节省了 NAT 出口费用，但会产生每小时和每 GB 的费用。决策标准应权衡数据引力、延迟 SLA 和持久性需求：仅在弹性和性能要求允许的情况下，才选择更便宜的存储或计算资源。

实践问题：用例场景

场景：Acme Global Enterprises 运营着一个成熟的 AWS 环境，该环境在 AWS Organizations 下有 18 个成员账户，一个集中的付款人账户，并且工作负载遍布三个区域。他们部分采用了标签策略，运行着几个长期存在的 EC2 机群，并广泛使用 S3 存储分析数据。

挑战：他们需要在六个月内将每月 AWS 支出减少 20%，同时保持性能 SLA 并使自治团队能够部署新功能。

推荐方法：

启用成本和使用情况报告（Cost and Usage Report）到 S3，设置小时级粒度，并与 Amazon Athena 集成；为过去 6-12 个月创建 Cost Explorer 的预留实例和规模优化报告。
部署 Compute Optimizer 并分析稳态实例的使用情况；购买混合的 Compute Savings Plans 以获得广泛覆盖，并为可预测的、特定实例系列的工作负载购买一年期可转换 RI。
通过 CloudFormation StackSets 和带有自动修复功能的 AWS Config 规则来强制执行标签策略，以处理缺失标签的情况；将按标签分类的成本报告分发给业务部门负责人，并创建带有自动化 SNS 和 Lambda 修复功能的 AWS Budgets，以应对阈值超支。
将静态和全球分发的内容转移到 Amazon CloudFront，将不常访问的数据转换为带有生命周期转换的 S3 Intelligent-Tiering，并识别适合使用 Spot 实例（带有检查点机制）的批处理作业，以从按需容量迁移出去。

基本原理：集中化的可见性（CUR + Athena）揭示了具体的规模优化和预留购买机会，而自动化的护栏（Config、StackSets、Budgets）则强制执行成本分摊并防止成本回升；将 Savings Plans 与选择性的 RI 相结合，可以在折扣深度和灵活性之间取得平衡，从而在不牺牲性能的情况下实现可靠的成本降低。

← 韧性、灾难恢复与高可用性 · 所有领域 · 部署、自动化与 DevOps →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →