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

cherylone

最近看一些 AWS 账单时，发现有一种费用挺容易被忽略：
6 O5 u9 F0 W1 c* Y( A) ^跨 Availability Zone 的流量。
$ ^: h/ @7 h6 Q* L; A3 a6 Z8 z% p很多人做 AWS 成本优化时，第一眼都会看 EC2、RDS、S3，或者公网 Data Transfer。
, J& Y& r* l  k; z! M* H但有些项目服务器规格没变，公网流量也没明显增长，账单还是慢慢往上涨，最后一拆才发现，问题出在不同 AZ 之间的数据传输。
$ o9 I( P& b( T7 \6 [. k比如一个比较常见的架构：
- V% q$ g# [, X5 \- ~6 |EC2 在 AZ-A，RDS 在 AZ-B。
应用每天大量访问数据库，从架构角度看完全没问题，甚至为了高可用，这种跨 AZ 部署本身就是正常做法。
但业务量起来以后，AZ 之间不断来回传数据，费用也会跟着增加。
& s, J4 e5 p% I. s) Z还有一些情况也比较常见：

• EC2 和 Redis 不在同一个 AZ
  
• ECS / EKS 节点分布在多个 AZ
  - d" X' m& \& V0 V' u+ P
• NAT Gateway 放在一个 AZ，其他 AZ 的服务器跨区访问
  4 u0 S* I1 t: ]. _6 a! ?
• Load Balancer 后面的流量跨 AZ 分发
  
• 大量服务之间互相调用
  , R  g& ^( q4 r: s9 ?8 k1 }. s
  8 ^8 m$ L% R0 X( P4 B/ r

这些单独看都不算什么“大问题”。
真正麻烦的是，业务量一旦放大，原来每天几 GB 的内部流量可能变成几百 GB、几 TB。
) \# I5 o1 y, Y9 j$ [' w/ ?这时候钱就开始慢慢出来了。
我们平时帮一些 AWS 项目看账单时，如果 Data Transfer 占比开始变高，我一般不会直接认为是“用户流量太大”。
. S3 X3 ]/ _/ Z% |8 h+ [1 Q先拆 Region，再看 Usage Type，再结合资源拓扑看看流量到底是在：
  L" ]% p) C6 ]3 R- K& n3 ~  q公网出去，还是 AWS 内部跨 AZ 跑。
% R2 [, Z' ^, N: G1 W5 e这两种情况的优化方向完全不一样。
. N* A4 g$ R  }) [9 y有时候甚至会碰到这种情况：
为了省事，所有 NAT Gateway 都集中放在一个 AZ，其他 AZ 的机器全部跨区过去走 NAT。
表面上看是少开了几个 NAT Gateway，好像更省。
但业务流量上来以后，跨 AZ 数据传输又产生了一笔额外费用。
所以 AWS 成本优化有时候挺有意思：
. e* V9 M& [. U; g1 X, H单独看某一项配置是“省钱”的，放到整个架构里未必真的省。
% ^: F! C/ o7 C5 ^, {当然，这也不是说为了省一点跨 AZ 流量，就把所有资源全部塞进同一个 AZ。
+ [1 _" D' ]9 I5 {; p生产环境的高可用性肯定比省这点费用重要。
更合理的做法是先弄清楚：
哪些跨 AZ 流量是为了高可用必须存在的；
: V4 }( T2 [. F# P& Y哪些只是历史部署、资源位置不合理或者架构调整后留下来的额外流量。
- \7 }" e) T$ Y" i/ h$ F) j$ K1 `前者正常付钱，后者才值得优化。
. f6 M2 @/ e8 g+ }7 H: X0 `/ \# T如果 AWS 一个月已经有几千美元甚至更高的用量，我觉得 Data Transfer 很值得单独拿出来看一次。
& \/ l2 ^' u+ ?& S4 @尤其是长期跑 SaaS、API、出海站点这类业务，服务器本身可能已经比较稳定，后面真正缓慢增长的费用反而经常出现在网络这一块。
) ~" X5 a, t7 m5 a  V我们这边平时也会帮客户做 AWS 账单拆分和成本梳理。
% Z! P) B- y& d1 t& E有时候优化不一定是“换便宜服务器”，而是先把钱到底花在哪条链路上搞清楚。
3 F, p" Y8 ], X  q" }账单拆明白以后，很多优化方向其实自然就出来了。