AWS 账单里有一种费用很容易被忽略：跨 AZ 流量
最近看一些 AWS 账单时，发现有一种费用挺容易被忽略：跨 Availability Zone 的流量。
很多人做 AWS 成本优化时，第一眼都会看 EC2、RDS、S3，或者公网 Data Transfer。
但有些项目服务器规格没变，公网流量也没明显增长，账单还是慢慢往上涨，最后一拆才发现，问题出在不同 AZ 之间的数据传输。
比如一个比较常见的架构：
EC2 在 AZ-A，RDS 在 AZ-B。
应用每天大量访问数据库，从架构角度看完全没问题，甚至为了高可用，这种跨 AZ 部署本身就是正常做法。
但业务量起来以后，AZ 之间不断来回传数据，费用也会跟着增加。
还有一些情况也比较常见：
[*]EC2 和 Redis 不在同一个 AZ
[*]ECS / EKS 节点分布在多个 AZ
[*]NAT Gateway 放在一个 AZ，其他 AZ 的服务器跨区访问
[*]Load Balancer 后面的流量跨 AZ 分发
[*]大量服务之间互相调用
这些单独看都不算什么“大问题”。
真正麻烦的是，业务量一旦放大，原来每天几 GB 的内部流量可能变成几百 GB、几 TB。
这时候钱就开始慢慢出来了。
我们平时帮一些 AWS 项目看账单时，如果 Data Transfer 占比开始变高，我一般不会直接认为是“用户流量太大”。
先拆 Region，再看 Usage Type，再结合资源拓扑看看流量到底是在：
公网出去，还是 AWS 内部跨 AZ 跑。
这两种情况的优化方向完全不一样。
有时候甚至会碰到这种情况：
为了省事，所有 NAT Gateway 都集中放在一个 AZ，其他 AZ 的机器全部跨区过去走 NAT。
表面上看是少开了几个 NAT Gateway，好像更省。
但业务流量上来以后，跨 AZ 数据传输又产生了一笔额外费用。
所以 AWS 成本优化有时候挺有意思：
单独看某一项配置是“省钱”的，放到整个架构里未必真的省。
当然，这也不是说为了省一点跨 AZ 流量，就把所有资源全部塞进同一个 AZ。
生产环境的高可用性肯定比省这点费用重要。
更合理的做法是先弄清楚：
哪些跨 AZ 流量是为了高可用必须存在的；
哪些只是历史部署、资源位置不合理或者架构调整后留下来的额外流量。
前者正常付钱，后者才值得优化。
如果 AWS 一个月已经有几千美元甚至更高的用量，我觉得 Data Transfer 很值得单独拿出来看一次。
尤其是长期跑 SaaS、API、出海站点这类业务，服务器本身可能已经比较稳定，后面真正缓慢增长的费用反而经常出现在网络这一块。
我们这边平时也会帮客户做 AWS 账单拆分和成本梳理。
有时候优化不一定是“换便宜服务器”，而是先把钱到底花在哪条链路上搞清楚。
账单拆明白以后，很多优化方向其实自然就出来了。
页:
[1]