同一个区域，为什么还要收费

一句话总结

流入流量通常免费，而流出流量和跨越边界的流量会产生费用。不理解这种不对称，就无法解释账单。

为什么需要了解这些

多可用区和 CDN 能提升可用性与性能，但也会改变数据跨越边界的次数。如果只比较计算资源价格，就会遗漏应用与数据库之间反复通信、以及源站出站流量造成的费用。因此，必须把架构中的所有主要流量路径换算为每月传输量。

工作原理

方向与边界

路径	费用
互联网 → 云（入站）	通常免费
云 → 互联网（出站）	昂贵
同一可用区内	通常免费
跨可用区	双向计费
跨区域	计费
VPC 对等连接（同一区域）	与跨可用区费用相近

最容易被忽视的是跨可用区费用。为了可用性采用多可用区架构后，如果应用服务器（AZ-a）与数据库（AZ-b）持续通信，所有这些流量都会计费。单次查询的数据量很小，但每秒数千次累积一个月后，费用就会显著增加。

减少费用的设计方法

1. 布置资源时考虑可用区 尽量让处理发生在同一可用区内。在 Kubernetes 中，可以通过拓扑感知路由（优先使用同一区域端点的配置）解决很大一部分问题。但这会与可用性形成取舍，因此必须验证单个可用区故障时系统如何运行。

2. 使用端点 就是前面课程讲过的方案。S3 网关端点免费，并且可以绕过 NAT。

3. 在前方部署 CDN 对于出站流量很大的服务（图片、视频、下载），CDN 缓存命中就等同于节省费用。CDN 的出站单价比源站低，而且请求根本不会到达源站。

4. 压缩数据 使用 gzip 发送 API 响应可以显著减少传输量。但不要压缩流式响应——数据块会积压在缓冲区中，使流式传输失去意义。

5. 检查容易忽视的部分 确认是否正在把日志和指标发送到其他区域，以及备份复制是否运行得比实际需要更频繁。

常见误解

• “内部通信免费”——只有在同一可用区内才免费。
• “压缩总是有利”——压缩会消耗 CPU。对图片、视频等已经压缩的格式没有效果，只会浪费资源。
• “CDN 很贵”——出站流量大时，CDN 通常更便宜。应实际计算后再判断。

养成计算的习惯

代入数字计算，就能建立直觉。

API 응답 평균 20KB, 초당 500 요청, 한 달 30일
= 20KB × 500 × 86,400 × 30
= 25,920 GB ≈ 26TB/월

이그레스 단가를 GB 당 100원으로 가정하면 약 260만 원/월
gzip 으로 5KB 까지 줄이면 약 65만 원/월 — 월 195만 원 절감

如果能在设计会议中完成这种计算，争论就会缩短。讨论内容不再是“似乎应该压缩”，而是“每月节省 195 万韩元”。

生产现场会看到什么

• 采用多可用区后费用增加 → 原因是跨可用区流量，应调整部署策略。
• 图片服务的大部分费用来自出站流量 → 引入 CDN。
• 日志被发送到其他区域的采集器 → 产生跨区域费用，应迁移到同一区域。

让费用变得可见

传输费用令人担忧的原因不只是金额，而是看不出它来自哪里。计算资源的每个实例都有名称，可以知道是谁在使用；传输费用却会以“跨区域传输”这样笼统的一行出现在账单中。因此，要降低费用，首先必须让它可见。

启用流日志。 记录从哪个地址向哪个地址传输了多少数据后，就能准确指出费用较高的路径。记录本身也会产生费用，但节省额通常远大于此；找到问题后，还可以降低采样比例。

添加标签，并按标签维度查看。 按团队或服务拆分后，在总账单中看不到的某项服务异常通信模式就会暴露出来。

按传输量而不是金额进行管理。 单价会变化，也会应用折扣；但“这条路径每月流过多少 TB”源自架构设计，是更稳定的数值。讨论设计时，最好使用这个数字。

此外，还需要一种发现意外激增的机制。费用告警通常来得太晚。 当收到已超过月度预算一半的通知时，往往已经产生了数天费用。如果把传输量本身作为指标，在达到平时数倍时告警，速度会快得多。尤其要警惕调用无限循环的事故。两个服务形成相互调用的环，或重试触发更多重试时，传输量可能在几小时内增长到平时的数十倍。这类事故在功能层面可能没有任何症状，常常只能从账单中发现。因此，画出服务间的调用关系并确认不存在环路，从成本与可靠性角度看具有同样价值。

下一步要看什么

接下来将建立一套实际查找浪费的步骤。