AWS 每月账单上来以后，我反而建议先别急着谈折扣

cherylone

刚开始用 AWS 的时候，一个月几十、几百美元，账单其实没什么好研究的。
7 F  p5 w, e8 I3 R/ uEC2 几台、S3 一点存储，月底看一下总金额，大概也知道钱花在哪。
但等一个项目跑到每个月几千美元以后，我现在反而不太建议第一件事就去研究“能打几折”。
原因很简单：
: g% m. v) U+ G1 R如果账单结构本身就有问题，折扣只是把浪费一起打了折。
7 u* |) u8 D8 C( B1 s5 M) y3 U9 f比如一个月 5000 美元的 AWS 账单，看起来已经不算小了。
) y: f3 F# h4 n. y4 G7 q. Y; `但拆开以后，可能真正长期稳定的业务成本只有 3500 美元。
3 `+ p* U* b7 x, Z; f1 I4 Z: P剩下的 1500 美元里面，混着：
" V, p+ ^  X3 s" z: j; `

• 很久没用的测试资源
  & d0 t1 _( Y  h% b- z" @
• 历史 Snapshot
  
• 规格偏大的 EC2 / RDS
  
• 没人关注的公网 IP
  " l/ ?$ A. O7 ~+ \1 _
• 流量和 NAT
  
• Marketplace 订阅
  2 Z' Q! A" }/ g, T+ a7 f& M3 l# h" `
• 一些长期没重新检查的配置
  
  

这种情况下，先去研究 Savings Plans 或者长期折扣，其实顺序有点反了。
1 L& f0 h3 [  t$ _$ \% K  H我更习惯先把账单分成两块。
3 {* F  Z0 @- ]- f一块是：
/ l; X5 s0 e) R业务正常运行一定会花的钱。
9 z: V! u$ H0 ~9 H  `- ]3 f比如长期在线的核心服务器、数据库、正常流量和存储。
1 p4 j/ w7 d" Y" V" N! H* c3 N* W, V另一块是：
" a7 M$ P. i, r7 t' q  r. \理论上可以重新检查的钱。
& z! K2 u$ O, H7 D这部分不一定全是浪费，但至少值得看一下为什么还存在。
3 y: ~9 G* A3 U5 ^2 I  p账单先这么拆一遍，后面很多事情会清楚不少。
1 t* |6 a7 |6 n4 q1 v比如长期稳定的计算底盘有多少，哪些资源适合做长期承诺，哪些业务波动比较大，哪些费用其实根本不应该继续存在。
) ~* O* }) X2 i我们平时帮一些 AWS 项目看账单时，也会发现一个挺有意思的现象：
6 Y3 \' n, j( i0 B有些客户最开始问的是：
* K( n3 W6 s5 K4 ?0 _1 S

我这个 AWS 能不能再便宜一点？

但真正把账单拆开以后，最后省下来的部分，未必主要来自折扣。
有时候光把长期闲置、重复配置和不合理规格整理掉，效果反而比单纯换计费方式更明显。
而且这种优化还有一个好处：
3 S$ t) g6 c9 E4 j不会把未来的用量提前锁死。
# }4 O7 o8 a# O9 u7 H( H1 `Savings Plans、RI 这些方案当然很好，但前提是你已经比较确定哪些资源会长期稳定存在。
如果连基础用量都没算清楚，直接做长期承诺，后面业务一变，反而容易出现利用率不够的问题。
! `1 Z- q0 o, Y! v3 w/ r  ]( B7 q所以如果 AWS 每个月已经有一定规模，我觉得比较合理的顺序应该是：
$ H8 w! s1 I# S先看账单结构
→ 找异常和历史资源
→ 确认长期稳定用量
→ 再研究折扣和结算方式
8 c/ }: p. c. }5 T$ t( w0 C我们现在自己在做 AWS 账单和成本相关服务时，也基本是按照这个思路看。
, h/ n) T* X( X, w6 Z9 x2 Z+ ?- Q不是一上来就告诉客户“能省多少”，而是先看看这张账单到底有没有优化空间。
毕竟同样是每个月 5000 美元，有的账号已经很干净了，真正能动的地方不多；
有的账号用了两三年，里面各种历史资源、旧配置、临时项目堆在一起，空间就完全不一样。
; u- I7 t+ x: u& d- C5 l  _) }所以我现在越来越觉得：
AWS 成本优化的第一步不是找最低价格，而是先搞清楚自己到底在为什么付钱。
账单看明白以后，后面的折扣、长期承诺、结算方式，才有意义。