AWS 账单里有一种费用很容易被忽略：跨 AZ 流量

cherylone

最近看一些 AWS 账单时，发现有一种费用挺容易被忽略：
  ]% o8 s# w, a, a$ o3 u' l; F跨 Availability Zone 的流量。
0 U% u$ t5 ~. r2 ]很多人做 AWS 成本优化时，第一眼都会看 EC2、RDS、S3，或者公网 Data Transfer。
' ^( L3 t* M, ?$ y但有些项目服务器规格没变，公网流量也没明显增长，账单还是慢慢往上涨，最后一拆才发现，问题出在不同 AZ 之间的数据传输。
# ~% D- \0 k9 Z9 _1 v! U6 V7 x比如一个比较常见的架构：
0 {* _" j, `- pEC2 在 AZ-A，RDS 在 AZ-B。
应用每天大量访问数据库，从架构角度看完全没问题，甚至为了高可用，这种跨 AZ 部署本身就是正常做法。
但业务量起来以后，AZ 之间不断来回传数据，费用也会跟着增加。
还有一些情况也比较常见：

• EC2 和 Redis 不在同一个 AZ
  
• ECS / EKS 节点分布在多个 AZ
  * z" x4 {% o9 s7 @# R
• NAT Gateway 放在一个 AZ，其他 AZ 的服务器跨区访问
  , D6 k; S& I7 B' N
• Load Balancer 后面的流量跨 AZ 分发
  
• 大量服务之间互相调用
  
  & B4 O8 ?7 {& Z! z/ o! k

这些单独看都不算什么“大问题”。
真正麻烦的是，业务量一旦放大，原来每天几 GB 的内部流量可能变成几百 GB、几 TB。
这时候钱就开始慢慢出来了。
我们平时帮一些 AWS 项目看账单时，如果 Data Transfer 占比开始变高，我一般不会直接认为是“用户流量太大”。
5 ^  v/ N& k5 o& Z# y先拆 Region，再看 Usage Type，再结合资源拓扑看看流量到底是在：
公网出去，还是 AWS 内部跨 AZ 跑。
这两种情况的优化方向完全不一样。
! @% ^1 V5 j2 ]有时候甚至会碰到这种情况：
3 N5 A8 e0 X* I为了省事，所有 NAT Gateway 都集中放在一个 AZ，其他 AZ 的机器全部跨区过去走 NAT。
# y4 {0 q; s# a* E表面上看是少开了几个 NAT Gateway，好像更省。
) n! V1 G1 `* {& D但业务流量上来以后，跨 AZ 数据传输又产生了一笔额外费用。
所以 AWS 成本优化有时候挺有意思：
( Z+ V+ j% ~3 c% `5 o单独看某一项配置是“省钱”的，放到整个架构里未必真的省。
当然，这也不是说为了省一点跨 AZ 流量，就把所有资源全部塞进同一个 AZ。
$ Z, D7 ?. b& K/ h" w! O生产环境的高可用性肯定比省这点费用重要。
更合理的做法是先弄清楚：
9 e% f0 t; Q8 q9 X9 v4 v哪些跨 AZ 流量是为了高可用必须存在的；
哪些只是历史部署、资源位置不合理或者架构调整后留下来的额外流量。
$ @/ E- e5 U1 e. n& G前者正常付钱，后者才值得优化。
1 s! ^! z' b3 ~8 s如果 AWS 一个月已经有几千美元甚至更高的用量，我觉得 Data Transfer 很值得单独拿出来看一次。
) B) U+ P3 V5 b! w# j$ l1 H尤其是长期跑 SaaS、API、出海站点这类业务，服务器本身可能已经比较稳定，后面真正缓慢增长的费用反而经常出现在网络这一块。
8 M: m& }' X9 n* x7 r+ ~$ ]我们这边平时也会帮客户做 AWS 账单拆分和成本梳理。
有时候优化不一定是“换便宜服务器”，而是先把钱到底花在哪条链路上搞清楚。
$ F+ L( m7 D. o3 c账单拆明白以后，很多优化方向其实自然就出来了。