打开账单的第一眼，先看什么
一句话总结
成本优化应当先看金额最大的项目，再做风险最低的措施。 顺序反过来，不但投入得不到相称的效果，还会破坏服务。
为什么需要它
如果一开始就签折扣合约或修改架构，可能会把根本没在使用的资源长期锁定下来， 也可能为了很小的节省而增加服务风险。从容易回退的浪费清理开始， 再进入需要测量的规格调整，才能同时守住成本和运行稳定性。
它如何运作
顺序
1. 안 쓰는 것 지우기 ← 위험 0, 효과 즉시
2. 안 쓸 때 끄기 ← 위험 낮음, 효과 큼
3. 크기 줄이기(right-sizing) ← 측정 필요
4. 저장 계층 옮기기 ← 수명주기 정책
5. 아키텍처 바꾸기 ← 효과 크지만 오래 걸림
6. 약정 할인 구매 ← 위 5개를 끝낸 뒤에 한다
**第 6 项必须放在最后。**如果浪费原封不动就购买承诺折扣， 等于用三年合约把浪费固定下来。先完成清理，再以清理后的基线购买承诺折扣。
1. 清理不用的资源
把它做成检查清单，每个季度执行一次。
- 已分离的卷（unattached）
- 未使用的固定 IP
- 没有任何目标的负载均衡器
- 陈旧的快照和 AMI
- 空的数据库实例
- 30 天内没有日志的日志组
- 从来没人查询的表
仅这一项就经常能让成本下降 10～20%。
2. 按计划启停
让非生产环境只在工作时间运行。操作简单，效果却很大。
需要注意的是，关闭前要先发送通知——可能有人正在加班使用。
同时设置例外标签（AlwaysOn=true），保留确实需要持续运行的资源。
3. 缩小规格
没有指标就动手会造成事故。至少应检查以下内容。
- CPU 峰值连续两周低于 40%，可以列为降低一级规格的候选
- 内存——它往往才是真正的约束，必须一并查看
- 突发积分——突发型实例必须检查积分是否耗尽。 即使平均 CPU 很低，只要积分见底，就已经处在性能受限状态。
每次只降低一级，然后观察。一次降低两级，出现问题需要回退时就没有判断依据。
4. 存储生命周期
为日志、备份和镜像设置策略。
0~30일 자주 접근 계층
30~90일 저빈도 계층
90~365일 아카이브
365일 이후 삭제
加入删除规则之前，必须确认保留要求。其中可能混有因监管要求而必须保存数年的数据。
5. 架构
也就是前面讨论过的内容——引入端点、使用 CDN、调整 AZ 布局，以及迁入或迁出托管服务。 这些措施效果很大，但前置时间较长，因此要与前四个阶段并行推进。
如何让节省持续下去
即使成功降下成本，六个月后也很容易恢复原状。要维持成果，就需要流程。
- 预算和告警——为各团队设置预算，在预计超支时告警
- 强制标签——阻止创建没有标签的资源
- 定期评审——每季度共同审查费用最高的十个项目
- 可见性——让团队能看到自己的成本。看不见，就不会减少
最后一点最关键。如果只有财务团队查看成本，没有人会主动削减。 必须让创建资源的人也能看到其价格。
在实际工作中会遇到的情况
- 先买了承诺折扣，结果无法改变架构 → 顺序错了。
- 一次缩小两级规格而引发故障 → 没有根据指标判断。
- 优化后半年便恢复原状 → 那只是一次性工作，不是流程。
后续实验要做什么
用真实数字验证这个顺序。如果只看表面指标就缩小规格，五台实例中有三台会受阻， 真正的限制不是 CPU，而是内存和突发积分。你还会亲自计算： 如果在清理前购买了承诺折扣，三年里会多付多少钱。
削减之前要确认什么
前面的五个阶段告诉你该削减什么，但是否可以削减需要另行判断。 跳过这一步造成的事故，往往比优化省下的钱更加昂贵。
真的没有人在用吗。指标为 0，不等于无人使用。每月运行一次的结算批处理、 每季度使用的报表实例，以及为灾难恢复而关停的资源，平时看起来全都是 0。 只有观测期长于该资源最长的使用周期才能作出判断；否则，删除前必须询问所有者。
知道是谁在用吗。没有标签、找不到所有者的资源最难删除。 这时不要直接删除，而应当先尝试关闭。放置几天仍无人寻找，再将其删除。 只要插入一个可回退的阶段，判断就会容易得多。
**有依赖它的东西吗。**降低存储等级前，要确认读取方能否承受更高延迟； 更换实例类型前，要确认其上是否绑定了固定许可证或 IP。
决定何时回退了吗。缩小规格后，应提前写明依据什么信号回退，以及观察多少天。 前面提到一次降低两级而引发故障的案例，其本质问题不在幅度大， 而在于没有预先定义回退条件。
最后，**记录节省的金额。**留下在何时削减了什么、节省了多少， 下个季度就不必从头重复相同讨论；更重要的是，需要回退时可以用数字说明代价。
接下来要看什么
可用性也有价格。接下来学习如何用 RTO/RPO 确定这个价格。