摘要

  • AWS 官方文档规定，最终月账单按当月最后一天 23:59:59 UTC 时设置的折扣共享偏好计算；月内估算账单采用最近一次设置。
  • 购买账户先用、组内优先或严格限于组内，会改变折扣的去向。全公司最低费用与部门独立核算各有目标，集中采购之后，谁承担承诺、谁拿走节省，仍需要分配规则。

公司组织图如果也有下班打卡时间，AWS 给出的答案精确到了秒：当月最后一天，23:59:59，UTC。

AWS 的账单偏好文档写明，最终月账单依据这个时点的折扣共享设置计算。月内看到的估算账单，则按最近设置计算。一个部门已经盯了几周的成本数字，到结账时仍要接受最后那张共享地图的安排。

这里分配的是 Savings Plans 带来的费率优惠。服务器可以原地不动，代码也不必改，只要购买账户或共享边界不同，先享受优惠的账户就可能不同。组织图在这件事上有了相当具体的经济效力。

三张地图，三种去向

默认的开放共享，把优惠提供给组织内已启用共享的账户。优先分组共享先照顾购买账户，再照顾指定组，之后才轮到组织内其他已启用共享的账户。限制分组共享则让优惠留在组内。

组通过 Cost Categories 定义。一个账户只能属于一个组，组不能重叠，管理账户不能加入共享组；Savings Plans 的所有者账户必须在共享偏好中处于启用状态。这些都是文档明确写出的边界。

在限制分组下，隔壁部门即使恰好有合适的需求，也不能越线拿走组内剩余优惠。AWS 自己说明，优先照顾组内分配，可能削弱全组织的折扣优化。

对独立核算的部门，边界可以保护费用责任。对追求全公司总价最低的采购中心，它可能是一项机会成本。两边都能拿出合理目标，控制台里的一条“推荐”无法替公司把这个利益分配决定做完。

不跑业务的账户，可能最适合买折扣

优惠的分配顺序先认所有者。AWS 会先把 Savings Plans 用到拥有它的账户的合格用量，再按共享规则转向其他账户。在相应分配阶段内，才优先选择节省比例较高的用量。

AWS 10 月 25 日的官方文章给了一个例子：某个账户只用 Lambda，自己购买 Compute Savings Plan 后，自己的用量先享受优惠。另一账户的 m8g Linux EC2 用量原本可能带来更高比例的节省，却要排在这个所有者之后。文章没有给这项差别标上损失金额；它解释的是购买身份怎样进入分配次序。

同一篇文章建议，集中采购可以放在管理账户，或一个不跑工作负载的指定账户。所有者没有自己的合格用量抢先消耗优惠，优惠便能按共享规则流向其他账户。应用无需搬家，采购的位置发生了变化。

一个不跑业务的账户，可能因此比一个忙碌的账户更适合做采购。这不是云计算突然欣赏起了闲人，而是所有权和使用权放在不同位置后，优惠的优先顺序变了。

不过，集中购买仍留下实际工作：内部费用分摊。集团把承诺买下来，不等于各部门已经同意由谁承担剩余承诺、又由谁领取节省。省钱的总数和省钱的归属，需要放在同一张批准单上。

为什么总部看见 100，部门加起来只有 70

AWS 的说明文章用一个一年期、无预付款的 Compute Savings Plan 场景解释推荐差异：管理账户看到每小时 100 美元的建议，成员账户的建议加起来却只有每小时 70 美元。这是解释机制的示例。

总部视角把可共享的合格用量放在一起；部门视角按单个账户及其已有优惠计算。逐小时需求能否互补、哪些账户允许共享，都会改变优化对象。所有者优先也可能让反方向出现：各部门分别买，合计承诺反而高于集中推荐。

推荐还有自己的时间边界。官方计算指南说，它依据历史用量，不预测未来，也不计入排队或已安排的未来购买；它面向立即购买。共享组改变后，推荐所覆盖的账户范围也随之改变。旧地图算出的数字，不宜当成新地图的采购答案。

要给一家公司的实际分配变化定价，还缺所有者账户、共享设置、逐小时合格用量和现有承诺库存。这几项数据决定了具体谁得益、谁承担。

月底最后一秒锁定的，并非一张好看的分类表，而是一张决定优惠去向的地图。公司不会把组织重组当成无关紧要的点选动作，折扣边界也值得同样明确的责任。毕竟，财务里的“共享”从来都带着一个问题：共享给谁？

来源