4. 预算与预警机制

在 FinOps 的治理闭环中，成本可视化只是起点，真正让成本“可控”的关键在于预算约束与预警响应。AWS Budgets 正是承担这一职责的核心服务：它把“我们希望花多少钱”变成可度量、可告警、可自动干预的规则。理解它的预算类型、阈值机制、通知链路和自动响应能力，是构建成本护栏的基础。

一、AWS Budgets 的定位与预算类型

AWS Budgets 允许你为账户、组织、OU 或按标签/成本类别筛选出的资源集合设定预算，并持续跟踪实际支出与预测支出。它支持多种预算类型，各自解决不同问题：

• 成本预算（Cost Budget）：跟踪一段时间内的实际支出金额，最常用于月度总成本控制。
• 使用量预算（Usage Budget）：跟踪某项具体用量的消耗，例如 EC2 运行小时数、S3 存储 GB-月、数据传输 GB。适合按用量而非金额治理的场景。
• 预留实例预算（RI Budget）：跟踪 RI 的利用率或覆盖率，防止已购承诺被浪费。
• Savings Plans 预算：跟踪 Savings Plans 的利用率与覆盖率，确保承诺折扣被充分消耗。

预算的作用范围由筛选维度决定。常见维度包括：按服务（如 Amazon EC2）、按标签（如 Project=Alpha）、按成本类别、按关联账户、按可用区等。一个实用的做法是“双层预算”：账户级总预算 + 按项目/团队标签的明细预算，前者防止整体失控，后者定位责任归属。

二、预警阈值：绝对额与百分比

预算是容器，阈值才是触发器。AWS Budgets 的阈值有两种表达方式：

• 绝对金额阈值：例如“实际支出超过 8000 美元时告警”。适合有明确硬上限的场景。
• 百分比阈值：例如“实际支出达到预算的 80% 时告警”。适合预算金额会调整、但比例关系稳定的场景。

阈值还可区分实际值（Actual）与预测值（Forecasted）。实际值告警是“已经花了这么多”，预测值告警是“按当前趋势月底会花这么多”。预测告警的价值在于提前量——它能在超支发生前数天甚至数周发出信号，为干预留出时间窗口。

一个典型的阈值阶梯设计如下（示例参数，非实测）：

阈值不是越多越好。过多阈值会造成告警疲劳，团队逐渐忽略通知。建议每个预算保留 2～3 个关键阈值，并确保每个阈值都有明确的“收到后做什么”。

三、SNS 通知链路

AWS Budgets 本身不直接发邮件或短信，它通过 Amazon SNS 主题投递告警。完整链路是：

1. 创建 SNS 主题，例如 finops-budget-alerts。
2. 为主题添加订阅者：邮件、短信、Lambda、SQS、HTTPS 端点（如企业微信/钉钉/Slack 的 Webhook 中转）。
3. 在 Budgets 的告警配置中，将阈值与 SNS 主题绑定，并填写订阅者邮箱（Budgets 也支持直接指定邮箱，但底层仍走 SNS）。
4. 确保 SNS 主题策略允许 Budgets 服务发布消息，否则告警会静默失败。

通知内容包含预算名称、当前实际值、预测值、阈值和账户信息。为了让通知可被自动化系统消费，建议在 SNS 消息上叠加 Lambda 订阅者，把 JSON 解析后路由到不同渠道：80% 阈值发给团队群，100% 阈值同时创建工单。

四、自动响应动作

告警只是“知道”，自动响应才是“行动”。AWS Budgets 支持配置 Budget Actions，在阈值触发时自动执行两类操作：

• IAM 策略动作：为指定用户、角色或组附加一条限制性策略，例如拒绝创建新的 EC2 实例或拒绝启动新资源。
• SCP 动作：在 Organizations 层面对某个 OU 或账户应用服务控制策略，限制其继续产生高成本资源。

自动响应必须谨慎设计。直接“关停资源”风险极高，可能影响生产。更稳妥的模式是先限制新增、再人工确认：达到 100% 阈值时，自动附加“禁止创建新实例”的 IAM 策略，阻止成本继续扩大，但不影响已有业务；同时通知负责人评估是否需要调整预算或优化资源。达到 120% 时，再考虑更严格的 SCP 限制。

五、预算偏差分析

预算告警之后，真正有价值的问题是：为什么偏差了？预算偏差分析就是把“超支”拆解为可归因的原因。常用方法包括：

• 按服务拆解：用 Cost Explorer 按服务分组，看是 EC2、S3 还是数据传输导致增量。
• 按标签拆解：定位到具体项目、团队或环境，判断是哪个责任单元超支。
• 按时间对比：对比本月与上月同期、本周与上周，区分“一次性突增”与“持续爬升”。
• 实际 vs 预测：若预测值远高于实际值，可能是短期波动被线性外推；若预测值持续高于预算，则趋势性超支已成立。

偏差通常归为几类：用量增长（业务真实扩张）、价格变化（折扣到期、按需比例上升）、资源泄漏（忘记释放的实例、未清理的快照）、架构变更（新服务上线、跨区流量增加）。不同原因对应不同对策：用量增长应调整预算并评估优化空间；资源泄漏应立即清理并加监控；价格变化应检查 RI/SP 覆盖情况。

六、落地要点与常见陷阱

把上述机制组合成可运行的治理方案，需要注意几个实践细节：

• 预算金额要有依据：不要拍脑袋填数字。用过去 3 个月的实际支出均值加合理增长作为初始预算，再按季度校准。
• 预测告警需要足够历史数据：新账户或数据不足时，预测值波动大，容易误报。建议先只启用实际值告警，积累 2～3 个计费周期后再加预测阈值。
• SNS 权限容易遗漏：主题策略未授权 budgets.amazonaws.com 发布消息时，告警不会报错但也不会送达，必须显式验证。
• 自动响应要有解除路径：IAM 策略动作触发后，需要有人或流程在确认后移除限制，否则会长期阻塞正常操作。
• 预算不是财务核算：Budgets 的数据有延迟（通常数小时到一天），不能替代精确的账单对账，它的价值在于趋势预警而非精确计量。

总结来说，AWS Budgets 提供的是“定义约束—监控偏差—触发通知—执行响应—归因分析”的完整链路。预算类型决定监控什么，阈值决定何时触发，SNS 决定通知谁，自动响应决定能做什么，偏差分析决定下一步怎么改。五者配合，才能把成本从“事后惊讶”变成“事前可控”。