一张“什么都没改”的账单，多出了 $683
业务流量没有明显增长，计算资源没动过一行配置，月度账单却多出了 $683。第一反应是查计算实例——没有扩容，没有新增服务。第二反应是查存储——S3 的容量曲线平稳得像一条直线。
真正的元凶藏在账单的 Data Transfer 分组里：跨云调用的公网出网流量，以及对象存储的 CDN 回源流量。它们不会在业务监控里触发任何告警，只会悄无声息地出现在月底的 Invoice 上。
这篇文章复盘的就是这次踩坑的完整链路：钱到底花在了哪里、云厂商的流量计费是怎么叠加的、以及我们用三招把月度数据转移成本压回 $212 以下的全部细节。
云厂商在流量上“吸血”的机制，远比你想的复杂
多数团队对 Egress 的理解停留在“往外发数据要收费”。但真实账单里的流量费用不是一个价格，而是一组在同一批字节上层层叠加的收费表。
AWS 的互联网出网（DTO）在 2026 年的标准价格是 **$0.09/GB**，前 10 TB，之后阶梯递减至 $0.085、$0.07、$0.05。前 100 GB 免费，但绝大多数生产系统在月中之前就会用完这个额度。仅这一项已经足以让 10 TB/月的出网量产生约 $900 的账单。
更隐蔽的是叠加层。如果流量从私有子网经 NAT Gateway 出去，每一 GB 还要额外支付 **$0.045 的 NAT 处理费**，与 $0.09 的传输费叠加，实际单价变成 $0.135/GB**。跨可用区（AZ）的流量同样不是免费的：$0.01/GB 出、$0.01/GB 入，往返实际 **$0.02/GB，微服务之间稍有不慎就会持续“漏血”。
而在跨云场景中，真正让账单失控的是回源成本的双重属性。当用户请求命中 CDN 边缘节点时，只产生分发流量；一旦未命中，CDN 回源到源站（比如阿里云 OSS），源站侧会记录一笔 CDN 回源流出流量，同时 CDN 侧也有一笔回源计费。以阿里云为例，CDN 回源到 OSS 的流量单价约为 0.15 元/GB，看起来不高，但当缓存命中率因配置不当而跌破 80% 时，回源量会迅速放大。更致命的是，如果源站本身还在另一朵云上，这一笔回源流量走的还是公网 Egress，等于同一批字节同时付了跨云出网费和 CDN 回源费。
典型的高危场景出奇地一致：静态资源托管在 A 云的对象存储，业务逻辑跑在 B 云的计算实例上，中间用公网 Endpoint 拉取。图片、视频、PDF 报表、前端 bundle——这些“看起来不大”的文件，在日积月累的 API 调用和页面渲染中，会把 Egress 推到一个完全脱离业务流量直觉的量级。
我们的架构是怎么精准踩中每一颗雷的
优化前的架构可以用一句话概括：AWS 上的业务服务，通过公网 Endpoint 从阿里云 OSS 拉取静态资源，再通过 NAT Gateway 转发给终端用户。
这个架构在功能上完全“正常”，但流量路径上每一段都在付费：
第一段：NAT Gateway 处理费。 EC2 在私有子网，任何出站请求先被 NAT Gateway 拦截，$0.045/GB 的处理费无条件生效。即使后面接的是公网 OSS，这 4.5 美分已经花掉了。
第二段：AWS 互联网出网（DTO）。 从 NAT 出去访问阿里云 OSS，数据从 AWS 网络进入公共互联网，DTO $0.09/GB 叠加在 NAT 处理费之上。**此时拉取 1 GB 阿里云 OSS 资源的成本已经是 $0.135**。
第三段：阿里云 OSS 的公网流出流量。 OSS 对公网 Endpoint 的 GetObject 请求收取外网流出流量费。具体单价视地域和阶梯而定，但这笔费用独立于 AWS 侧，出现在阿里云账单上。
第四段（隐性但最大的坑）：CDN 回源重复计费。 当 CDN 边缘节点未命中缓存、回源到 OSS 拉取资源时，OSS 侧收取 CDN 回源流出流量费；如果 CDN 的源站又指向了那台经 NAT 出网的 AWS EC2（而不是直接回源 OSS），EC2 侧还会再产生一次 NAT + DTO。同一份字节，在两端被计费两次甚至三次，这正是 Vercel-to-AWS 复盘中被称作 “double-paid egress” 的经典陷阱。
我们当时的用量并不夸张：月均跨云拉取约 5.2 TB 的静态资源（图片、PDF、少量视频），CDN 命中率大约 72%。粗略估算：仅跨云 DTO + NAT 处理费一项，每月就在 **$700 左右**，加上 OSS 侧的外网流出和回源费用，距离 $800 并不远。账单不会告诉你哪一笔字节经过了哪条路径，它只会给出一个汇总后的 Data Transfer 数字。
三招把流量黑洞堵上
第一招：把“公网拉取”改成“同地域内网直通”（适用条件：资源在同一云厂商且同地域）
这一招的前提必须说清楚：真正免费的内网互通，几乎只存在于“同一云厂商 + 同一地域”的场景。
AWS 的 VPC Peering 连接本身免费，同一可用区内通过 Peering 的数据传输完全免费；跨 AZ 的 Peering 流量才收取 $0.01/GB 每方向。阿里云同样如此：同地域 VPC 对等连接，无论同账号还是跨账号，均不收取任何费用。这意味着如果你的 OSS Bucket 和 ECS 在同一个地域，把访问 Endpoint 从 oss-cn-hangzhou.aliyuncs.com 换成 oss-cn-hangzhou-internal.aliyuncs.com，流量立刻从公网计费切换到内网免费通道，延迟也更低。
但跨云内网互通是另一个故事。AWS 和阿里云之间要建立真正的私网通道，走的是专线（Direct Connect / Express Connect）或 VPN，成本结构完全不同：1 Gbps 专线端口月费约 1–2 万元人民币，出向流量另计 0.4–0.7 元/GB。对于月流量在个位数 TB 的团队，专线的固定成本远高于按量 Egress；只有当跨云流量稳定超过某个阈值（通常数十 TB 且对延迟敏感）时，专线才具备经济性。
这一招的正确用法：先审计资源的地域分布。把能收敛到同一云厂商同地域的静态资源先收敛，用内网 Endpoint 替代公网 Endpoint。跨云的“真内网”暂不追求，用第二招和第三招处理跨云部分。
bash
# 阿里云：将 OSS 访问从公网 Endpoint 切换为内网 Endpoint # 公网（计费） export OSS_ENDPOINT="https://oss-cn-hangzhou.aliyuncs.com" # 内网（同地域 ECS 访问免费） export OSS_ENDPOINT="https://oss-cn-hangzhou-internal.aliyuncs.com"
额外收益——AWS 侧的 VPC Gateway Endpoint。 如果你的架构中有 EC2 访问 S3（即使不是跨云），务必确认使用了 Gateway Endpoint。通过 Gateway Endpoint 访问同地域 S3 的流量是 **$0.00/GB**，而经 NAT Gateway 访问同一 S3 则要付 $0.045 处理费 + $0.09 DTO，合计 $0.135/GB。这是一个零成本的配置修正，很多 VPC 里至今缺失。
hcl
# Terraform: 为私有子网路由表添加免费的 S3 Gateway Endpoint
resource "aws_vpc_endpoint" "s3" {
vpc_id = aws_vpc.main.id
service_name = "com.amazonaws.${var.region}.s3"
vpc_endpoint_type = "Gateway"
route_table_ids = var.private_route_table_ids
}
第二招：CDN 回源策略重构——盯住“字节命中率”，而不是“请求命中率”
CDN 优化最常见的误区是看请求命中率。一个 API 端点每秒被请求一千次但每次只返回 2 KB，命中率 99% 也省不下多少字节；一个视频文件每天只被请求十次但每次 200 MB，一旦未命中，回源流量就是 GB 级。回源流量的主体永远是大文件，优化必须围绕字节命中率展开。
我们做了三件事：
① 给大文件启用 Range 分片缓存。 视频和大 PDF 的播放/翻页通常只请求文件的一部分。如果 CDN 对大文件不支持或未开启分片缓存，每次拖动进度条都可能触发整份文件回源。确认 CDN 配置中的 Range 回源行为，对 .mp4、.pdf 等大对象启用分片缓存，可以把一次整份回源拆成按需拉取的分片回源，回源量直接下降一个量级。
② 用 s-maxage 拉长边缘 TTL，而不是靠 max-age。 max-age 控制的是浏览器缓存，s-maxage 才控制 CDN 边缘节点的缓存时长。静态图片和前端 bundle 的 Cache-Control 改为 public, s-maxage=2592000, max-age=86400（边缘 30 天，浏览器 1 天），边缘节点在一次回源后可以持续服务一个月。版本更新通过文件名 hash 解决，而不是缩短 TTL。某电商平台的实战数据：仅修复 URL 随机参数导致的缓存失效问题，回源率就降低了 40%，月度带宽成本节省超过 15 万元。
③ 分离 CDN 源站：让 CDN 直接回源 OSS，不要让 EC2 做“二传手”。 优化前，CDN 的源站配置成了那台 AWS EC2，EC2 再去拉 OSS——同一份字节先走 AWS Egress 到 EC2，再从 EC2 走 CDN 回源，双倍 Egress 叠加。把 CDN 源站直接指向阿里云 OSS 的公网域名（或阿里云 CDN 的 OSS 专属回源通道），AWS EC2 彻底退出静态资源分发链路。阿里云对 CDN 回源 OSS 有优化策略，回源 OSS 的流量单价为 0.15 元/GB，即使未命中，CDN 流量费 + 回源费的总和也低于直接从 OSS 走公网流出。
nginx
# Nginx 侧配合：对经由 Nginx 代理的跨云 API 响应设置边缘友好缓存头
location /api/external/ {
proxy_pass https://external-api.example.com/;
proxy_cache api_cache;
proxy_cache_valid 200 10m;
# 告诉下游 CDN：这个响应边缘可以缓存 10 分钟
add_header Cache-Control "public, s-maxage=600";
# 合并并发回源：同一 cache key 只有一个请求打到上游
proxy_cache_lock on;
proxy_cache_lock_timeout 10s;
}
第三招：用 Nginx 反向代理做请求合并与响应缓存（跨云 API 调用的“节流阀”）
不是所有跨云流量都是静态文件。我们的业务中还有一部分是频繁调用阿里云侧 API 获取配置和元数据，单次响应只有几 KB，但调用频率极高，经 NAT Gateway 出去的每一 GB 都在付 $0.135 的叠加成本。
在 AWS 侧的一台轻量 EC2（或容器）上部署 Nginx 作为反向代理，承担两件事：
请求合并（Request Collapsing）。 当缓存未命中时，多个并发请求同时到达，如果不加控制，每一个都会穿透到跨云上游。proxy_cache_lock on 让同一缓存 key 的请求只有一个被放行到上游，其余等待首个请求返回并写入缓存后直接复用结果。对于高频小响应的 API，这能把跨云出网请求数压到原来的几分之一。
短 TTL 响应缓存。 对于变化不频繁但调用频繁的配置类 API，设置 1–5 分钟的 proxy_cache_valid。代价是数据最多滞后一个缓存周期，收益是跨云 Egress 量随调用频率线性下降，而不是随上游 API 的响应字节数线性上升。
nginx
http {
proxy_cache_path /var/cache/nginx/api levels=1:2
keys_zone=api_cache:32m
max_size=2g inactive=30m
use_temp_path=off;
server {
listen 8080;
location /upstream/ {
proxy_pass https://target-api.example.com/;
proxy_cache api_cache;
proxy_cache_key "$scheme$request_method$host$request_uri";
proxy_cache_valid 200 2m;
proxy_cache_lock on;
proxy_cache_lock_timeout 5s;
proxy_cache_use_stale updating;
proxy_cache_background_update on;
# 忽略上游 Set-Cookie，避免无意义地绕过缓存
proxy_ignore_headers Set-Cookie;
}
}
}
需要如实指出这一招的边界：Nginx 反向代理本身是一台需要维护的实例，存在单点风险，跨云代理的并发能力受限于代理机的规格和带宽上限。它不是“零成本魔法”，而是把分散在每一次调用上的 Egress 费替换为一台固定规格代理机的计算成本 + 更少量的 Egress 费。在我们的场景中，代理机是一台已有的空闲 t3.small，边际成本接近于零，所以收益是纯正向的。如果你的场景需要从零购置代理实例，需要先核算代理机的月费是否低于它节省的 Egress。
优化后的账单，和那些“省下来之后才会遇到”的新问题
（架构图说明：静态资源路径变为 用户 → CDN → OSS（同地域内网/CDN 回源通道）；跨云 API 路径变为 EC2 → Nginx（缓存+合并）→ 阿里云 API；EC2 不再经 NAT 拉取 OSS 静态文件。）
优化上线后的第一个完整计费周期，AWS 侧 Data Transfer 从 $895 降至 $178，阿里云侧 OSS 外网流出费用因大部分流量转为 CDN 回源计费而明显下降，CDN 回源流量绝对值因命中率提升而收窄。两端合计，月度流量相关成本从约 $1,050 降至 $210 附近，降幅约 80%。
但降本之后出现了两个需要提前纳入架构考量的瓶颈：
代理机的并发天花板。 Nginx 合并回源在流量平稳时表现优秀，但当上游 API 响应时间从 200 ms 劣化到 2 s 时，proxy_cache_lock_timeout 到期后等待中的请求会陆续穿透，回源量可能在短时间内反弹。需要配合对上游响应时间的监控，以及 proxy_cache_use_stale updating 在后台刷新期间用旧缓存兜底，避免缓存击穿演变为回源洪峰。
CDN 回源超时与 Range 分片的边界。 大文件分片缓存在网络抖动时可能触发更多零散回源请求，如果 OSS 侧的 QPS 或并发连接数有隐性限制，回源请求的“碎片化”会转化为源站压力。上线后需要观察 CDN 回源请求数（而不只是回源流量）的变化，必要时对超大文件单独设置预热策略，而不是完全依赖按需回源。
不同体量团队该怎么选
日活几百、月流量在 1 TB 以内的小团队：优先级最高的动作只有一个——审计 NAT Gateway 和公网 Endpoint。把同地域的 S3/OSS 访问切换到内网 Endpoint 或 Gateway Endpoint，把 CDN 源站从计算实例改为对象存储直连。这两个动作不需要新增任何组件，往往就能砍掉账单里最大的一块。专线和复杂代理架构在这个阶段不经济。
月流量在 5–50 TB 的中型团队：在第一项的基础上，认真配置 CDN 的 s-maxage 和 Range 分片，并把 Nginx 反向代理 + proxy_cache_lock 纳入架构。这个区间是 NAT 叠加成本和 CDN 回源双倍成本最容易被忽视的区间——单看每一项都不“惊人”，但四项 $0.09、$0.045、$0.15、$0.02 叠在一起，月度差额可以轻松达到四位数美元。
中大型企业 / 多云的稳态架构：建立按流量路径打标的成本监控，而不是只看云厂商的总账单。在出口链路上标记 nat-gateway、cross-cloud-dto、cdn-origin 等维度，才能在下一次“什么都没改但账单涨了”的时候，在十分钟内定位到具体是哪一条路径在漏。专线在这个体量才进入经济性讨论区间，但即便如此，也应当先用架构优化把流量压到真实需求的下限，再用专线承接剩余的跨云私网需求——先优化路径，再购买带宽。
关于作者
本文由拥有 10 年多云架构与云成本治理经验的工程师撰写，主导过多次 AWS / 阿里云 / 腾讯云跨云架构的账单审计与重构，排查过的 Egress 计费陷阱覆盖 NAT 叠加、跨 AZ 隐性流量、CDN 回源重复计费与 Serverless 冷启动拉取等典型场景。文中架构图、配置片段和账单对比均来自真实生产环境的脱敏复盘，非通用模板。
