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

cherylone

最近看一些 AWS 账单时，发现有一种费用挺容易被忽略：
跨 Availability Zone 的流量。
4 H9 I# S! Q8 q2 Q% U* m" B很多人做 AWS 成本优化时，第一眼都会看 EC2、RDS、S3，或者公网 Data Transfer。
但有些项目服务器规格没变，公网流量也没明显增长，账单还是慢慢往上涨，最后一拆才发现，问题出在不同 AZ 之间的数据传输。
( B' q+ `0 e* {( @比如一个比较常见的架构：
. g5 K9 d2 b9 X, J8 dEC2 在 AZ-A，RDS 在 AZ-B。
7 b# k4 O# z* l. B应用每天大量访问数据库，从架构角度看完全没问题，甚至为了高可用，这种跨 AZ 部署本身就是正常做法。
但业务量起来以后，AZ 之间不断来回传数据，费用也会跟着增加。
+ ]4 c$ @' \' i) d1 b还有一些情况也比较常见：

• EC2 和 Redis 不在同一个 AZ
  
• ECS / EKS 节点分布在多个 AZ
  ! U, n4 R( n* q
• NAT Gateway 放在一个 AZ，其他 AZ 的服务器跨区访问
  3 `) n! ^+ I6 D$ N+ r; G. m
• Load Balancer 后面的流量跨 AZ 分发
  
• 大量服务之间互相调用
  ( H* m3 k; |0 w  `- @  \
  7 r7 G# w( X. s! h

这些单独看都不算什么“大问题”。
真正麻烦的是，业务量一旦放大，原来每天几 GB 的内部流量可能变成几百 GB、几 TB。
& `* X- Q, t8 i5 J+ _7 j& P  C8 n" N这时候钱就开始慢慢出来了。
3 E5 l5 v5 [$ H% i" F, G3 Y2 i4 G* Y( B我们平时帮一些 AWS 项目看账单时，如果 Data Transfer 占比开始变高，我一般不会直接认为是“用户流量太大”。
% K7 j! X4 g6 @: c* v6 \+ c先拆 Region，再看 Usage Type，再结合资源拓扑看看流量到底是在：
* Y( t9 j+ V2 `2 H1 }2 I( Y! _公网出去，还是 AWS 内部跨 AZ 跑。
9 K# `( B' H4 }! u* [这两种情况的优化方向完全不一样。
( B" N3 r' N+ X: @* t7 W- U有时候甚至会碰到这种情况：
为了省事，所有 NAT Gateway 都集中放在一个 AZ，其他 AZ 的机器全部跨区过去走 NAT。
表面上看是少开了几个 NAT Gateway，好像更省。
5 C* f1 I# q) X+ s  Z但业务流量上来以后，跨 AZ 数据传输又产生了一笔额外费用。
所以 AWS 成本优化有时候挺有意思：
单独看某一项配置是“省钱”的，放到整个架构里未必真的省。
当然，这也不是说为了省一点跨 AZ 流量，就把所有资源全部塞进同一个 AZ。
0 G- ?' z/ V5 a2 E6 D. [生产环境的高可用性肯定比省这点费用重要。
更合理的做法是先弄清楚：
1 {# X9 G: H7 i4 K9 G- Z0 N哪些跨 AZ 流量是为了高可用必须存在的；
" k! X" F( o' P0 f" l哪些只是历史部署、资源位置不合理或者架构调整后留下来的额外流量。
) M& Y2 {  D7 q9 W/ @) S7 T前者正常付钱，后者才值得优化。
# W) D1 d5 g+ t( W如果 AWS 一个月已经有几千美元甚至更高的用量，我觉得 Data Transfer 很值得单独拿出来看一次。
尤其是长期跑 SaaS、API、出海站点这类业务，服务器本身可能已经比较稳定，后面真正缓慢增长的费用反而经常出现在网络这一块。
7 {( }3 P/ g$ E$ }& q7 I4 X我们这边平时也会帮客户做 AWS 账单拆分和成本梳理。
有时候优化不一定是“换便宜服务器”，而是先把钱到底花在哪条链路上搞清楚。
账单拆明白以后，很多优化方向其实自然就出来了。
7 C. L& ^8 D1 R+ N/ ~