你算过服务器，算过存储，甚至算过CDN。但你的成本模型里，大概率漏了一个每年吃掉数百万预算的项目——数据搬家费。
云厂商的定价表上，出站流量（egress，数据离开云环境）的价格藏在角落，字体比服务条款还小。但它会在账单上长成一头大象：不是一次性的大额支出，而是数千次微小数据移动的累积，每次几美分，每月几百万次。
AWS、GCP、Azure三家厂商的出站流量定价逻辑相似，陷阱却各不相同。本文按时间线还原一个典型架构如何从"零egress预算"滑向"月度超支告警"，以及哪些设计决策在事发三年前就埋下了伏笔。
第一阶段：只算互联网出站，漏掉同区域跨可用区
2019年，某SaaS团队设计多活架构。高可用性要求服务跨三个可用区（AZ）部署，负载均衡自动分发流量。这个决策在当时毫无争议——AWS官方最佳实践，金融级可靠性标准。
问题在两年后显现。微服务数量从12个增长到67个，服务间调用链平均长度达到5跳。每次跨AZ的API调用，AWS收取$0.01/GB双向费用。一个返回2MB JSON的查询请求，在三个AZ间跳转三次，产生6MB的跨AZ流量。
该团队2021年Q3账单显示：跨AZ数据转移费用$47,000，占当月总基础设施成本的18%。而互联网出站费用仅$12,000。
架构师复盘时发现，原始设计文档中"egress成本"章节只估算了对公网流量，跨AZ条目标注为"内部流量，预计免费"。
这个标注的错误在于混淆了"同一VPC内"和"同一AZ内"。VPC（虚拟私有云）跨AZ不收费，但数据包一旦离开本AZ，计费系统就开始计数。
GCP和Azure的定价结构略有不同，但陷阱位置一致：可用区之间的数据移动从来不是免费的午餐，只是账单上的科目名称足够晦涩——AWS叫"Data Transfer Between Availability Zones"，GCP叫"Network Egress to Same Region"，Azure叫"Availability Zone Data Transfer"。
第二阶段：存储便宜，读取昂贵
对象存储的定价极具欺骗性。S3标准存储$0.023/GB/月，GCS Nearline$0.010/GB/月，Azure Blob Hot Tier$0.0184/GB/月。这些数字让架构评审会上的存储成本估算总是很好看：100TB数据，月存储费不到两千美元。
存储成本是锚定效应的典型案例。决策者盯着存储单价，忽略了每次读取的出站费用。
2022年，某机器学习团队搭建训练流水线。训练数据存放于S3，GPU实例位于us-east-1的p4d.24xlarge节点。每个训练周期（epoch）需要从S3拉取800GB数据到实例本地NVMe存储。
S3到EC2的"同一区域数据出站"费用：$0.01/GB。单次epoch成本$8。模型训练需要500个epoch，总数据移动成本$4,000。而存储这800GB一个月的费用是$18.40。
读取成本是存储成本的217倍。
该团队的优化路径具有代表性：首先尝试S3 Express One Zone（单AZ存储，读取费降至$0.0025/GB），但牺牲了多AZ耐久性；最终迁移到FSx for Lustre，将热数据缓存到与计算节点同AZ的高性能存储，S3仅作为冷备份。
改造后，单次epoch的数据移动成本从$8降至$0.15，降幅98%。但架构复杂度显著增加——需要维护数据预热管道和一致性校验机制。
这个案例的普遍启示：存储定价和读取定价必须分开建模。任何涉及"从对象存储反复读取大量数据"的架构，都需要在成本估算阶段单独列出"存储读取出站"条目，金额按存储费的50-500倍预估。
第三阶段：跨区域复制，双向计费陷阱
多区域部署的egress成本最容易被低估，因为涉及两个维度的复合计费。
某金融科技公司2020年构建全球架构：主区域us-east-1，灾备区域eu-west-1，亚太区域ap-southeast-1。数据库采用主动-主动复制，三个区域实时同步。
AWS跨区域数据复制费用：$0.02/GB（传出区域收取）。三个区域两两复制，理论上有6条复制链路。实际架构中，每个写入操作会触发两次跨区域传输（主区域→另外两个区域），单次写入1KB数据产生2KB跨区域流量。
2022年业务高峰期，日写入量达到12TB。跨区域复制产生的出站流量：24TB/日。月度费用：$0.02 × 24,000GB × 30 = $14,400。
更隐蔽的成本在读取侧。亚太用户查询历史数据，请求路由到最近的ap-southeast-1节点。但该节点未命中本地缓存时，需要向us-east-1的主数据库发起查询——这又是一次跨区域数据移动，费用同样$0.02/GB。
该架构的egress成本呈现典型的"双向吸血"特征：写入时付一次复制费，读取时可能再付一次查询费。
云厂商的定价文档不会主动提醒你这种复合效应。AWS的S3 Cross-Region Replication定价页面只说明"复制操作本身不收费，只收数据传输费"，但不会在同一个段落告诉你"从复制目标区域读取数据时，如果源数据不在本地，可能产生额外费用"。
该金融公司的最终优化方案是区域数据分片：用户数据按注册地物理隔离，跨区域复制仅用于灾备而非实时服务。改造后跨区域流量下降87%，但牺牲了"任意区域实时服务全球用户"的架构灵活性。
第四阶段：第三方服务，隐含的egress税
云原生架构的egress成本不仅来自云厂商，还来自嵌入架构的第三方SaaS服务。这些服务的定价模型往往将egress成本转嫁给用户，但披露位置隐蔽。
2023年，某电商团队接入第三方日志分析平台。架构设计：应用日志→Kinesis Data Firehose→S3（暂存）→第三方平台（通过S3批量读取）。
第三方平台的文档说明："从S3读取数据不收取额外费用"。团队据此判断该集成无额外成本。
实际账单显示，S3的"请求者付费"（Requester Pays）功能被启用。第三方平台每次读取S3对象时，AWS向S3桶所有者收取标准S3出站费用。该团队月日志量45TB，第三方平台每日全量扫描一次，产生45TB/日的S3出站流量。
月度隐藏成本：$0.09/GB（S3标准出站费率） × 45,000GB × 30 = $121,500。
这个案例的关键细节：第三方平台的文档没有撒谎，"不收取额外费用"指的是平台方不向用户收费，而非该集成不产生任何基础设施成本。
类似陷阱广泛存在于数据仓库（Snowflake、BigQuery的外部表查询）、监控服务（Datadog的日志重hydration）、以及任何"从你的云存储读取数据"的第三方集成。
防御性架构设计原则：任何涉及第三方服务读取你的云存储数据的场景，必须在集成文档中搜索"requester pays""data transfer""egress"等关键词。若文档未明确说明成本归属，默认假设你的云账户会承担出站费用。
建模方法论：在架构评审阶段植入egress预算
事后优化egress成本，往往意味着架构重构。更高效的策略是在设计阶段建立egress成本模型，与计算、存储成本并列评审。
具体操作方法：
绘制数据流图时，标注每条链路的物理位置（区域-可用区-服务类型）。对跨越AZ边界、区域边界、或云边界的每条链路，标注预估数据量和对应费率。
建立egress成本基线：将历史账单中的egress条目按类型拆解（互联网出站、跨区域、跨AZ、VPC对等、Direct Connect等），计算单位业务量的egress系数（如"每订单产生多少MB出站流量"）。新业务场景按系数 extrapolate。
设计评审清单增加egress专项：多AZ部署是否必要？能否通过服务拓扑优化减少跨AZ调用？数据是否可以分区存放减少跨区域读取？第三方集成是否启用了requester pays？
某云成本管理平台的2023年调研数据显示：采用egress前置建模的团队，首年基础设施超支率比行业平均低34%。但调研同时显示，仅12%的团队在架构设计文档中包含egress成本估算章节。
这个比例与2019年的8%相比几乎无变化——egress仍然是云成本管理中被系统性忽视的领域。
当你下次评审架构文档时，可以问一个具体问题：这个数据流箭头，如果按当前费率计费，每月会产生多少账单？如果回答者需要打开云厂商定价页现查，说明egress建模还没有成为你们的设计习惯。
热门跟贴