不是贵，是在闲着
一句话总结
云成本并不来自昂贵的资源，而是来自什么都没做却一直开着的资源。
为什么需要读懂账单
云服务按使用量计费，中途没有审批环节。启动实例不需要批准，关闭实例也不需要批准。因此，启动资源的事情不断发生，关闭资源的事情却很少发生。
几个月后账单越来越高，但没有人知道究竟为什么变高。 创建资源的人已经调到其他团队，财务团队只看总额。在这种状态下提出“降低成本”，人们就会先处理最显眼的部分，而最显眼的通常规模很小。
因此，处理顺序是固定的——先按项目拆分，再辨别这些钱购买的究竟是什么。 不经拆分就开始的成本削减，通常金额很小，或削减了不该节省的部分。
拆分项目之前什么也做不了
从“云成本太高”出发，通常会以这样的方式结束：先处理显眼项目，而显眼项目往往很小。
首先查看各项目所占比例。拆分实验中的账单后，结果如下。
batch compute 1,401.60$ 43.9%
db managed_db 747.52$ 23.4%
web compute 525.60$ 16.5%
snapshots snapshot 210.00$ 6.6%
...
합계 3,191.17$
排名第一的项目就占了 44%。其余所有项目加起来也不及它。
而排名第一的资源通常处于闲置状态
查看 batch 的备注，会看到以下内容。
批处理任务每天运行 2 小时，但实例一直保持开启。
每天 2 小时 × 30 天，只工作 60 小时，却计费 730 小时。92% 的费用都花在什么也没做的时间上。
只看 CPU 使用率很难发现问题，因为人们会看到平均 11% 后说“批处理本来就是这样”。真正应该查看的是资源在什么时候工作。
辨别这些钱购买的是什么
并非所有成本都是浪费。
cross-az 的 3000GB 流量源于 Web 与数据库位于不同可用区。把两者集中到同一可用区就能消除费用，但该可用区故障时，它们也会一起停止。
这不是浪费，而是为可用性支付的价格。如果要削减，必须先回答“能否接受一个可用区故障”。在没有答案时削减这笔费用，并不是节省成本，而是购买了风险。
备用数据库（两台 db 中的一台）也是如此。它平时什么也不做，但这正是支付这笔费用的用途。
通过改变路径即可消失的费用
这是最令人愉快的一类：流量保持不变，费用却会消失。
NAT 网关会分别收取小时费用和按流量计算的费用。如果通往对象存储的流量正在经过 NAT，改用网关端点后，这条路径就不再经过 NAT。
小时费用仍会存在，因为 NAT 本身依然需要保留；但流量处理费用会变为 0。
没有人会主动删除的资源
4200GB 快照是连续 7 个月的每日快照。为什么没有人删除？
因为没有人确定保留期限。 删除之前必须回答“需要恢复到多久以前的时间点”。如果没有答案，就没人敢为删除承担责任。
保留期限由恢复要求决定，而不是由成本决定。只要明确写下 30 天，超过期限的内容就能自动删除。
应该从哪里开始
按费用占比排序看似正确，但实际工作中，最好先从未使用的资源开始。
| 顺序 | 对象 | 原因 |
|---|---|---|
| 1 | 未使用的资源 | 容易发现，没有风险 |
| 2 | 闲置时间 | 金额大，容易恢复 |
| 3 | 保留策略 | 一旦确定，就能自动减少 |
| 4 | 改变路径 | 需要修改设计 |
| 5 | 改变架构 | 需要讨论与协商 |
没有人会反对第一项。团队在学习方法的同时取得成果，也会积累推进下一项所需的信任。如果从第五项开始，通常只会以争论告终。
生产现场会看到什么
- 账单第一名是批处理实例，但批处理每天只运行两小时。只需一行配置把运行时间改为 60 小时即可解决。
- 看到 CPU 平均使用率为 11%，便认为“批处理本来如此”，连续 3 年没有调整。应观察的不是使用率，而是什么时候工作。
- 把跨可用区流量视为浪费，将 Web 和数据库集中到一个可用区；该可用区故障时，整个服务随之停止，损失大于节省的金额。
- 快照已经累积 7 个月，却没人敢删除，因为没有文档回答哪些内容可以删除。
- 试图先处理最大项目，导致团队间争论持续两个月。先清理未使用资源的团队，却在同一期间取得了成果。
总结
- 按项目拆分并查看占比。
- 检查排名第一的资源实际工作了多久。
- 区分浪费与为可用性支付的成本。
- 寻找通过改变路径即可消除的费用。
- 从未使用的资源开始。