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

cherylone

最近看一些 AWS 账单时，发现有一种费用挺容易被忽略：
0 b9 B! ?" q# z" D4 ^跨 Availability Zone 的流量。
. n& x/ O" \1 [) E很多人做 AWS 成本优化时，第一眼都会看 EC2、RDS、S3，或者公网 Data Transfer。
但有些项目服务器规格没变，公网流量也没明显增长，账单还是慢慢往上涨，最后一拆才发现，问题出在不同 AZ 之间的数据传输。
, y- r8 y# ^  L& J+ x- N+ z比如一个比较常见的架构：
$ K$ `7 Z% o& n" V8 t! `8 CEC2 在 AZ-A，RDS 在 AZ-B。
应用每天大量访问数据库，从架构角度看完全没问题，甚至为了高可用，这种跨 AZ 部署本身就是正常做法。
5 Z$ r& Z8 L9 ^( {但业务量起来以后，AZ 之间不断来回传数据，费用也会跟着增加。
还有一些情况也比较常见：

• EC2 和 Redis 不在同一个 AZ
  
• ECS / EKS 节点分布在多个 AZ
  - g* @& L3 C2 d- g
• NAT Gateway 放在一个 AZ，其他 AZ 的服务器跨区访问
  " ~4 t1 }+ u$ D/ t8 J* m
• Load Balancer 后面的流量跨 AZ 分发
  
• 大量服务之间互相调用
  / E) j$ ^' m  ^0 f+ Y
  ! e" n4 G5 ]0 }, `! T; }  V! v: N

这些单独看都不算什么“大问题”。
真正麻烦的是，业务量一旦放大，原来每天几 GB 的内部流量可能变成几百 GB、几 TB。
这时候钱就开始慢慢出来了。
* ^+ }# i" i: @  n4 @# O) A% w我们平时帮一些 AWS 项目看账单时，如果 Data Transfer 占比开始变高，我一般不会直接认为是“用户流量太大”。
先拆 Region，再看 Usage Type，再结合资源拓扑看看流量到底是在：
9 n+ ^, y# O2 k/ }) V公网出去，还是 AWS 内部跨 AZ 跑。
这两种情况的优化方向完全不一样。
% o# O6 J9 D; L5 k6 V; B有时候甚至会碰到这种情况：
3 L# V5 f* Q* R- z. E为了省事，所有 NAT Gateway 都集中放在一个 AZ，其他 AZ 的机器全部跨区过去走 NAT。
表面上看是少开了几个 NAT Gateway，好像更省。
但业务流量上来以后，跨 AZ 数据传输又产生了一笔额外费用。
. G+ s# l9 U4 l: m5 @! e- d4 \所以 AWS 成本优化有时候挺有意思：
6 E$ ?( c5 X+ R$ n6 ]4 K: N单独看某一项配置是“省钱”的，放到整个架构里未必真的省。
当然，这也不是说为了省一点跨 AZ 流量，就把所有资源全部塞进同一个 AZ。
生产环境的高可用性肯定比省这点费用重要。
更合理的做法是先弄清楚：
哪些跨 AZ 流量是为了高可用必须存在的；
6 u: v# L$ j7 P  Y  w8 ~  L哪些只是历史部署、资源位置不合理或者架构调整后留下来的额外流量。
3 s& T5 ^5 o9 v4 M5 v前者正常付钱，后者才值得优化。
如果 AWS 一个月已经有几千美元甚至更高的用量，我觉得 Data Transfer 很值得单独拿出来看一次。
尤其是长期跑 SaaS、API、出海站点这类业务，服务器本身可能已经比较稳定，后面真正缓慢增长的费用反而经常出现在网络这一块。
我们这边平时也会帮客户做 AWS 账单拆分和成本梳理。
有时候优化不一定是“换便宜服务器”，而是先把钱到底花在哪条链路上搞清楚。
9 k! r  K8 |, T9 ]7 ]账单拆明白以后，很多优化方向其实自然就出来了。
* E- R# S. j$ H4 \4 k0 P