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

cherylone

最近看一些 AWS 账单时，发现有一种费用挺容易被忽略：
跨 Availability Zone 的流量。
很多人做 AWS 成本优化时，第一眼都会看 EC2、RDS、S3，或者公网 Data Transfer。
; a; _) H1 |0 C( v) D. D但有些项目服务器规格没变，公网流量也没明显增长，账单还是慢慢往上涨，最后一拆才发现，问题出在不同 AZ 之间的数据传输。
比如一个比较常见的架构：
EC2 在 AZ-A，RDS 在 AZ-B。
8 l8 I. L0 s' Y, P9 O应用每天大量访问数据库，从架构角度看完全没问题，甚至为了高可用，这种跨 AZ 部署本身就是正常做法。
/ A7 s0 l8 l  y$ J- B- m( h) H3 T但业务量起来以后，AZ 之间不断来回传数据，费用也会跟着增加。
还有一些情况也比较常见：
3 {; \. ^2 T) I+ \0 ?" y( I1 l

• EC2 和 Redis 不在同一个 AZ
  
• ECS / EKS 节点分布在多个 AZ
  & V; h& p- Z6 i& g8 n/ d. M
• NAT Gateway 放在一个 AZ，其他 AZ 的服务器跨区访问
    z, p/ D# B" P* v7 W6 j) Z
• Load Balancer 后面的流量跨 AZ 分发
    w0 @; ]0 A" K( N- S
• 大量服务之间互相调用
  2 R$ ]% c6 ~' c) X) S5 r) g+ M
  5 J, b5 \' \" F/ k% ^9 M

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