Amazon SOA-C02: 成本管理与资源标记 — 学习指南

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

成本管理和资源标签是保持云支出可见、可预测和受治理的核心运营活动。准确的账单和报告让运营人员能够将成本归因于团队、项目和环境；标签加上强制执行的策略可实现自动化的成本分摊和清理。积极使用 Cost Explorer、成本和使用情况报告、Budgets 以及优化工具有助于减少浪费，并为 Savings Plans 或 Reserved Instances 等承诺决策提供信息。了解特定于服务的成本驱动因素（网络、存储、负载均衡器、NAT）可以防止意外的出口流量费用和托管服务费用。

账单、成本报告和成本管理器的基础知识

通过 AWS Organizations 启用整合账单，并将成本和使用情况报告 (CUR) 以小时粒度和包含资源 ID 的形式交付到 S3 存储桶，以支持详细的成本归因。在账单控制台中，启用成本分配标签（包括 AWS 生成的和用户定义的），这样 Cost Explorer 和 CUR 中就会包含标签列。要以编程方式访问，请使用 Cost Explorer API 或 CLI：例如，

undefined

。

使用 Cost Explorer 进行交互式趋势分析和规模优化视图：启用“规模优化建议”报告，按标签或关联账户筛选，并导出建议的 CSV 文件。对于自动化工作流，可将 CUR 提取到 Athena（针对 CUR 文件创建外部表），以跨维度（linkedAccountId、productName、usageType、resourceId、tags）运行 SQL 查询。将 Athena 查询与 Glue 爬网程序结合，可以在 QuickSight 中构建仪表板，或为账单驱动的自动化提供数据。

选择报告粒度和保留期的决策标准：

• 如果需要基于短期实例进行按实例的成本分摊或自动化，请使用小时粒度的 CUR。
• 当不需要小时级别的细节时，可使用每日粒度的 CUR 进行月度趋势分析。
• 当您希望将账单数据与资源清单（标签编辑器、Resource Groups）关联以实现精确归因时，请激活资源 ID。

用于成本分配和治理的标签策略

采用规范的标签键分类法（例如：CostCenter、Owner、Project、Environment、Lifecycle），并在资源创建时强制执行。在账单控制台中将这些键激活为成本分配标签，使其出现在 Cost Explorer 和 CUR 中。通过以下方式实施强制策略：

• 使用 AWS Organizations 的标签策略来规定允许的键和值。
• 使用 AWS Config 托管规则 required-tags 来检测缺失的标签。
• 使用 IAM 权限或服务控制策略（SCP）拒绝在没有必需标签的情况下创建资源（使用条件键 aws:RequestTag 和 aws:TagKeys）。

使用 Resource Groups Tagging API 和标签编辑器来审计和修复跨区域的标签：例如，

undefined

。通过附加堆栈级别的标签，并使用基于 Lambda 的钩子将运行时元数据（instanceId、launchTime）添加到资源中，从而通过 CI/CD 或 CloudFormation 自动化标签传播。

选择标签强制执行策略时的权衡：

• 严格强制（拒绝无标签的创建操作）可以防止未标记资源的蔓延，但除非有例外，否则可能会阻碍开发人员的临时工作流。
• 检测并修复（Config + 自动化）的方式阻力较小，但在资源创建和标签修正之间存在延迟。

Savings Plans、Reserved Instances 和规模优化

根据计算使用量的可预测性和灵活性需求，在按需、Savings Plans 和 Reserved Instances 之间做出选择。主要区别：

• Savings Plans：Compute Savings Plans 适用于 EC2、Fargate 和 Lambda，并提供跨实例大小/区域的灵活性；EC2 Instance Savings Plans 针对特定区域内的实例系列，折扣更高，但跨服务覆盖范围较小。
• Reserved Instances (RIs)：Standard RIs 为固定的实例类型提供最大折扣，可以是区域性的或可用区级的；Convertible RIs 允许更改实例系列，但需要重新配置。
• 按需实例：无承诺，每小时成本最高，最适合突发性或未知的工作负载。

使用 Compute Optimizer 和 Cost Explorer 的规模优化报告来识别未充分利用的实例（CPU、网络、EBS 吞吐量）和过度预置的存储。将 CloudWatch (

undefined

) 指标与 Compute Optimizer 的建议相结合，为缩减规模或更改实例系列提供依据。当使用量稳定时（例如，生产环境的基准 vCPU 小时数），计算盈亏平衡点和覆盖率：为可预测的基准使用量购买 Savings Plans 或 RIs，并保留一部分按需实例作为缓冲以应对突发使用量。

预算、警报和预测

在 AWS Budgets 中为成本、使用量以及 RI/Savings Plan 覆盖率创建预算，阈值类型包括“实际”和“预测”。使用控制台或 CLI (aws budgets create-budget --account-id <id> --budget file://budget.json)，并附加 SNS 主题、电子邮件或 Lambda 操作通知。对于编程方式的修复，可将 SNS 连接到 Lambda 以标记或停止临时资源，或在预测值超过阈值时在 ITSM 系统中创建工单。

添加 Cost Anomaly Detection 来检测突发的支出峰值，并将异常情况关联到 SNS/SQS 以实现自动化调查工作流。Cost Explorer 中的预测功能使用历史支出数据；将其与业务信号（例如季度初的营销活动、待处理的工单）相结合，以设置切合实际的预算警报。对于运营决策：

• 使用预测阈值来及早发现增长趋势。
• 使用实际阈值来防止在月末超出预算。
• 将警报与非关键账户的自动化护栏（停止/缩减规模）相关联。

数据传输与特定服务的成本驱动因素

网络和存储是常见的、差异性大的成本驱动因素。请理解以下具体细节：

• 数据传输：跨区域出口流量按 GB 计费；跨可用区 (AZ) 流量可能免费，也可能收费，具体取决于服务（某些服务对跨 AZ 流量收费）。NAT Gateway 的费用包括每小时费用和每 GB 处理费用 —— 对于高吞吐量的工作负载，NAT Gateway 的账单可能在出口成本中占主导地位。
• 负载均衡器：ALB/NLB 会产生每小时和每 GB 处理量的费用；转发密集型流量会增加成本。
• S3/EBS：S3 存储定价取决于存储类别（Standard、Intelligent-Tiering、Glacier）和请求次数；生命周期策略可将对象移动到成本更低的存储层，以减少存储开销。EBS 快照存储按 GB-月计费，跨区域复制操作也会产生费用。
• 托管服务：RDS I/O、DynamoDB 读/写容量和按需备份，以及 ElasticSearch (OpenSearch Service) 的存储和快照成本。

优化策略：

• 使用 S3 的 VPC 端点以减少互联网出口流量，并在服务全球用户时使用 S3 Transfer Acceleration 或 CloudFront 来减少源站出口流量。
• 整合跨区域流量或将服务部署在同一区域，以避免跨区域出口成本。
• 在适当情况下，并在测试性能权衡后，使用 VPC 端点、Gateway Load Balancer 或 NAT 实例替换 NAT Gateway。

常见陷阱与决策标准

• 资源未打标签且无法追溯：使用 AWS Config 强制执行必要标签，并使用 Resource Groups Tagging API 自动查找和修复未打标签的资源。
• 误解 Savings Plan/RI 的范围：在购买前，请确认 Compute Savings Plans（跨服务）或 EC2 实例 Savings Plans / RI（实例族/可用区范围）是否与您的工作负载匹配。
• 仅依赖 CPU 进行规模优化：应结合内存、网络和磁盘 IOPS 指标（通过 CloudWatch 和 Compute Optimizer 获取）进行分析，以避免降级后出现性能衰退。
• 忽略跨区域/服务的数据传输成本：绘制流量流向图，通过 VPC Flow Logs/Athena 测量出口流量，并将流量产生和消费密集的服务部署在同一位置，或使用 CloudFront/VPC 端点。
• 预算配置错误：恰当选择“实际”与“预测”用量，并附加程序化操作（SNS → Lambda）以提早进行限制或发出通知。
• 遗留孤立的存储/快照和空闲的 ELB：为未挂载的 EBS 卷、过期的快照和未使用的负载均衡器安排自动化清理任务。

实践问题：用例场景

在一次营销活动后，ApexAnalytics 公司的成本环比飙升 40%；工程师们在多个区域启动了许多开发环境栈，并依赖 NAT Gateway 访问互联网。财务团队需要即时的可见性和修复措施。

1. 开启包含资源 ID 的小时级 CUR，并将其交付到一个专用的 S3 成本存储桶；创建一个 Athena 表，以便按 linkedAccountId、region 和 usageType 查询主要成本驱动因素。
2. 通过标签策略 (Tag Policies) 和 AWS Config 的必要标签规则，激活并强制执行成本分配标签（如 CostCenter、Project、Owner），并使用 Resource Groups Tagging API 回填缺失的标签。
3. 运行 Cost Explorer 规模优化报告和 Compute Optimizer 报告，识别稳定的基线计算量，并为基线小时数购买合适的 Savings Plan；为未充分利用的实例安排降级计划。
4. 使用 VPC Flow Logs → Athena 审计网络出口流量；在可能的情况下用 VPC 端点替换 NAT Gateway，并集中区域性测试工作负载以避免跨区域传输。
5. 创建带有预测阈值的 AWS Budgets，附加 SNS 以触发 Lambda 来隔离非关键的开发账户或通知所有者，并启用 Cost Anomaly Detection 以应对成本突然飙升的情况。

基本原理：交付 CUR 和强制执行标签可以建立精确的成本分摊和历史分析能力。规模优化和经过衡量的承诺（Savings Plans）可以减少可预测的开销，而网络优化和自动化预算操作则可以防止未来出现意外的出口成本。

← Serverless 与应用程序集成 · 所有领域

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

浏览 Amazon →