读懂账单再削下去
目标
云成本如果**不知道归属在哪里，就无法削减。而且成本通常不在“昂贵的资源”上，而在“什么都没做却一直开着的资源”**上。
这里提供了某个团队一个月账单的逐项明细。请阅读、修正，并确认减少了多少。
开始
cp -r /opt/lab/cost/* . && python3 cost.py
总计大约为 $3,191。
文件
| 文件 | 作用 |
|---|---|
architecture.json |
费率与资源，需要逐步修改此文件 |
cost.py |
逐项计算，不要修改 |
请务必阅读每项资源的 메모。浪费不写在数字里，而写在备注中。
评分
从第 3 步开始，评分器会**直接使用你的 architecture.json 计算。**只填写数字无法通过。
步骤
- 各项占比 →
01-breakdown.txt - 闲置时间 →
02-idle.md - 修正后减少多少 →
03-fix-idle.txt - 快照保留 →
04-snapshot.txt - 更改路径 →
05-path.txt - AZ 间流量 →
06-az.md - 未使用资源 →
07-unused.txt - 总结 →
08-notes.md
参考
费率随供应商与区域变化。重要的是数量级，以及“什么与什么成正比”。
把账单拆分成项目
复制 /opt/lab/cost/ 并运行 python3 cost.py，把最大的三个项目及各自占比记录到 01-breakdown.txt。
cp -r /opt/lab/cost/* . && python3 cost.py
降低成本时，第一步就是做这件事。拆分项目之前，不知道应该从哪里着手，通常只会先处理显眼但很小的项目。
总计大约会是 $3,191。
最大项目实际工作了多久
阅读排名第一项目的 메모，比较真实工作时间与计费时间，写入 02-idle.md。
查看 architecture.json 中的 메모。每天只运行 2 小时的批处理，实例却开启了 730 小时。
**超过 90% 的成本都花在什么也没做的时间上。**这是云成本中最常见的浪费，仅看 CPU 使用率很难发现，因为即使平均值低，也容易被解释为“这种工作负载本来如此”。
修正后能减少多少
先保持 architecture.json 原样并创建副本，再把批处理改为只运行实际需要的时间。最终可以覆盖文件名 architecture.json。修改后的文件仍使用 architecture.json，并把 python3 cost.py 的结果保存到 03-fix-idle.txt。
每天 2 小时 × 30 天 = 60 小时。把 가동시간 从 730 改为 60。
评分器会直接使用你的 architecture.json 计算。只填写数字无法通过。
请观察只改一行减少了多少，这就是“应从哪里开始”的答案。
那些没有删除的内容
查看快照项目的备注，制定保留策略后按该策略缩减，并写入 04-snapshot.txt，同时说明为何选择这个期限。
已经积累了 7 个月的每日快照。如果保留 30 天，大约会降到原来的 1/7。
**保留期限应由恢复需求决定，而不是由成本决定。**答案在于“必须能够恢复到多久以前的时间点”。没有答案时，就没人敢删除，于是会积累 7 个月。
通过更改路径消除成本
阅读 NAT 项目的备注，改成能让流量处理费用消失的结构，并记录到 05-path.txt。
NAT 会分别收取每小时费用与按流量计费。如果大部分流量都流向对象存储，使用网关端点后，这条路径就不再经过 NAT。
尝试减少 처리GB。流量本身不变，只改变路径就能让成本消失。每小时费用仍会保留，因为 NAT 本身依然需要。
跨越 AZ 的流量
从备注中找出 cross-az 项目为何是 3000GB，并把减少方法写入 06-az.md。
Web 与数据库位于不同 AZ，因此每个请求都会跨越 AZ。每 GB 费率虽低，但因数量很大而不断累积。
不过这里有个陷阱：把它们集中到同一 AZ 后，该 AZ 故障时会一起中断。该项目可能不是“应削减的浪费”，而是为可用性支付的费用。请区分这笔钱购买的是什么。
无人使用的资源
浏览备注，找出并删除当前无人使用的资源，把最终总计写入 07-unused.txt。
三个月前使用的负载均衡器仍然运行。
金额很小，但这类资源**最容易发现，风险也最低。**从这里开始降低成本，团队可以一边学习方法一边取得成果；若一开始就处理大项目，通常只会陷入争论。
总结
在 08-notes.md 中至少写三行：应从哪里开始、如何区分浪费与可用性成本，以及通过更改路径消失的成本示例。
正文中必须包含 비중、가용성、경로。