多云成本怎么控：跨云传输的隐性账单与四个架构问题

简介

多云架构确实给团队留出了灵活空间，可以按可用性、供应商能力和地理覆盖范围来挑方案。可这份灵活也有代价：数据在云服务商之间搬来搬去，隐性成本跟着冒出来。服务部署怎么选、通信怎么走、扩容怎么做，这些环节都会让成本一点点累积，时间一长还越滚越大。等到账单上能看见，架构层面的毛病早就落下了。

多数组织的做法偏被动：查账单、谈费率、生产环境上线后再调优。这些手段都没碰到根上。多云系统里，成本效率该在设计阶段就定下来。

这篇文章把后端 FinOps 落到多云架构上。涉及的内容包括用 FOCUS 做成本可视化、削减跨云数据传输的策略，还有工作负载部署、同步模型以及把成本治理接进 CI/CD 流程的工程做法。目标就一个：让成本控制变成系统的结构性特征，而不是事后补课。系统设计出来，就该自带控成本的能力。

生产观测

维护一个零售订单和支付平台的生产环境时，我注意到单个结账请求可能牵出促销评估、支付授权、订单持久化、履约服务好几摊事。分布式追踪的数据显示，下游的瞬时故障会通过重试和反复检索订单上下文，把一个逻辑操作变成多次网络调用。这件事推动我们把真正面向客户的关键路径交互，跟那些不必阻塞订单确认的下游处理分开。实际好处是故障耦合度降了，结账延迟也更可预测：非关键的下游消费者不会再拖慢客户响应。专有交易量和提供商拓扑信息我特意略去了。本文后面的受控实验把这个生产模式推广到多云环境，并量化了它的成本影响。

跨云数据传输的隐性成本结构

广告上的出站费率只是起点，不是全部。表 1 列出的是截至 2026 年 1 月、与官方提供商商定价核对后确认的分层成本结构。

表 1. 按提供商划分的实际出站流量成本结构（2026 年 1 月），数据来源：AWS、Azure 和 GCP（*通过 NAT 网关传输的私有子网流量）

公布的出站费率只反映数据传输的基础成本。真金白银上，NAT 网关处理、跨区域及中转流量这些费用会把每千兆字节的实际成本明显推高。拿 AWS 来说，流量走 NAT 网关，实际出站成本会比广告费率高出 50% 以上。类似成本层在所有主要提供商那里都存在，跨可用区和跨区域的流量尤其明显。

行业研究显示，不少组织都低估了这部分开销。问题核心在结构上。数据传输成本由架构和数据流动模式决定，可这些成本往往要等部署完成、看账单报告时才会暴露。

多云微服务中的四个架构问题

“后端 FinOps：在云端构建高性价比的微服务”一文讲过怎么在单个云边界内优化微服务，多云环境还得再往前看一步。下面要说的四种模式，占了可避免出站流量开支的绝大部分。

问题 1：跨云同步通信

不少多云系统里，单个用户请求会穿过由不同云提供商托管的服务。做法是灵活了，隐性网络传输成本也跟着来了。云与云之间每发一次同步请求，都会产生出站流量和网关费用，流量涨，费用跟着涨。

下面的基准测试基于已公布的 2026 年第一季度定价，模拟一个典型企业部署场景。产品目录服务跑在 AWS 的 EKS 上，推荐引擎跑在 Google Cloud 上，欺诈检测服务跑在微软 Azure 上。客户交易过程会同步调用每项服务。

主要发现

• 每多一次跨云服务跳转，运营成本就往上抬一截。

• 同样的工作负载放在单云部署，跨服务商的传输成本可以完全避开。

• 这些成本取决于架构设计决策，不是运行时配置能改的。

from enum import Enumclass TrafficClass(Enum):    INTERACTIVE = "interactive"    BACKGROUND = "background"class CrossCloudGateway:    def __init__(self, realtime_client, batch_queue):        self.realtime_client = realtime_client        self.batch_queue = batch_queue    def dispatch(self, request, traffic_class):        if traffic_class is TrafficClass.INTERACTIVE:            # Customer is waiting, e.g., for payment authorization.            return self.realtime_client.send(request)                self.batch_queue.enqueue(request)        return {"status": "accepted"}# Usagegateway = CrossCloudGateway(realtime_client, batch_queue)gateway.dispatch(payment_request, TrafficClass.INTERACTIVE)gateway.dispatch(analytics_event, TrafficClass.BACKGROUND)

这个简化的网关示例把流量分类说得很清楚。支付授权是交互式操作，客户要立刻拿到响应，所以请求得同步发出去。分析事件是后台操作，客户不用等，可以丢进队列，之后再批处理、压缩，或者挪到离数据源更近的地方处理。关键的设计决策不在网关实现本身，而在于让工作负载跨出服务提供商边界之前先分好类，确保交互式流量和后台流量不会自动共用同一套延迟、可用性和成本特性。

举个例子，AWS 里的结账服务如果在订单完成前调用 Azure 的欺诈检测服务，那结账的延迟和可用性就捏在这两个服务商以及它们之间的网络手里了。

重试、超时加上下游扇出效应，会进一步推高跨云调用次数和传输字节数。所以设计上要回答的关键问题是：调用方真需要即时响应吗？需要的话，团队就该用严格的超时设置、备用方案、小数据包和受控的重试机制；不需要的话，这种依赖关系可以换成异步消息传递。

问题 2：在不需要实时的情况下进行不必要的实时数据传输

大多数工程团队会不停地在云服务商之间传数据，因为从运营角度看，实时处理似乎才是对的。实际操作中，很少有人拿真实的使用模式去验证这个假设。分析管道、机器学习重新训练工作流以及合规系统，基本以小时或天为周期跑，而每传一次数据都会按 GB 产生出站费用。结果就是，企业为数据传输掏的钱，是按数据的生成速度算的，不是按实际使用情况算的。

这种情况下，问题不在应用程序之间的同步耦合。客户不用等分析系统。问题在于数据传输频率快过了业务对数据时效性的要求。定一个可接受的数据时效阈值（比如五分钟、一小时或一天），就能在传输前对记录做批处理、去重、压缩或聚合。

Expedia Group 发布的一个案例把这个问题讲得很明白。应用程序在不同的 AWS 区域之间反复取相同的数据集，跨区域出站成本一直降不下来，可底层数据几乎没变。为了不重复传同样的数据，Expedia 加了 Alluxio 缓存层，把频繁访问的数据放在本地。跨区域传输成本因此降了 50%，应用程序性能也上去了，业务逻辑和数据本身都没动。

跨区域数据传输发生的频次才是成本大头，每GB单价反倒不是关键，对数据时效要求不严的用户来说更是如此。

问题3：原始数据直接搬运，计算结果没传

把原始事务日志、特征数据或点击流数据跨云边界送到下游处理，属于代价最高的数据迁移方式之一。低效不只体现在传输量上：这些数据到了目的地，最后往往被过滤、聚合或者直接丢弃。

业内指南普遍把“近源处理”列为头号省钱手段。Azure Well-Architected Framework 和 Google Cloud 的混合架构文档都主张，数据在跨服务商边界之前先压缩，别指望目标端来做这件事。落地案例也能对上。西门子重做了分析管道，只在源头处理增量变化，不再每次运行都传完整数据集副本，管道维护成本降了 90%，每日加载时间从 6 小时缩短到 25 分钟。

平台架构里，这条原则体现得越来越明显。Google BigQuery Omni 就是把计算任务挪到数据所在的 AWS 或 Azure 环境，而不是把数据搬进 Google Cloud，符合条件的跨云分析工作负载因此完全免掉了出站数据传输费。架构上的共识很清楚：在数据源头算，只传处理结果。

问题4：跨云广播让流量翻倍

游戏、物联网平台这类事件驱动系统里，一次状态更新常常同时广播给多家云服务商。各家收到的信息一模一样，数据却是分别往每个目的地各传一遍，冗余的跨云流量就这么产生了，出站成本成倍往上走。

更省的做法是：更新信息只发布一次，放到共享的分发层，比如内容分发网络（CDN）或中央枢纽云，其他环境就地取用。信息照样送达，跨服务商的重复传输却省掉了。

生产系统里这种模式已经跑起来了。Amazon CloudFront 和 Cloudflare 这类服务在边缘缓存内容，重复请求就地响应，不用一遍遍跨服务商边界。分析领域也是同理，Google Cloud 的 BigQuery Omni 在数据所在位置处理，不在不同环境之间复制数据集。

数据传一次，消费端可以反复用。

受控实验：结账数据跨云传输

实验背景和设置

实验模拟的是一个常见的电商结账流程。客户提交购物车后，AWS 上托管的结账服务负责核验价格和库存、算税费和折扣、授权支付、创建订单，再返回订单确认信息。

订单完成后，另一云平台上的报表平台也要同样的订单数据，用来做销售仪表盘和运营分析。这个报表环节并不是客户完成购买的必要步骤，但架构没设计好，它照样可能被直接塞进结账流程里。

为了衡量这笔取舍，实验对比了三种传递已完成订单数据的做法：

• 同步传输：结账服务把完整订单负载发到远程报表平台，收到响应之后才确认订单。

• 每小时批量传输：结账服务立刻确认订单，把报告事件放进 AWS 队列，之后按小时批量发送去重、压缩过的记录。

• 近源处理：AWS 在本地算好仪表盘需要的指标，只把汇总结果传到远程平台。

三种方法都能满足每小时出一次报表的要求。所以实验专门看通信模式对结账延迟、跨云流量和网络成本的影响。

工作负载

测试用了十万个合成的已完成订单。每个订单产生的跨云有效载荷平均为 250 KB，含订单详情、明细行、支付元数据和履约信息。

流量生成持续了一小时，参数如下：

• 平均负载为每秒 25 笔订单

• 峰值负载为每秒 100 笔订单

• 每笔订单的有效载荷大小为 250 KB

• 远程服务的延迟落在 100-300 毫秒区间；一旦超时或失败，重试策略是最多重试两次。

接着，团队把测试数据推演到每月 1 亿笔已完成订单的生产级工作负载上。

指标

实验记录的项目包括结账页面第 95 百分位响应时间：

• 跨云请求数

• 跨云传输量

• 重试量

• 还有预计的月度网络成本，以及预计的年度节省金额。

网络成本按每 GB 0.09 美元的示例传输费率计算。另一套算法用每 GB 0.135 美元，其中每 GB 0.09 美元是传输费，另加每 GB 0.045 美元的示例网关处理费。

实验结果

批处理架构靠数据去重和压缩，把传输数据量压掉 60%。近源处理则压掉 95%，因为跨界传输的只剩订单数量、销售总额、付款分配和其他仪表盘指标。

成本影响

主要观察结果

同步通信带来两个问题：延迟变高，故障耦合也更严重。结账确认要依赖远程报表平台，远程延迟、超时和重试都会直接作用到客户交易上。

批处理在成本和可靠性两头都有改善。报表功能从结账流程里挪走后，p95 延迟由 420 毫秒降到 145 毫秒，预计网络成本同时下降 60%。

成本效益最大的是近源处理。只传汇总后的仪表盘结果，即便把网关处理费算进去，预计月成本也从 3375 美元降到 168.75 美元，降幅 95%，一年能省约 38475 美元。

架构的影响比服务商定价更大。基础传输费率从每 GB 0.087 美元调到 0.12 美元，同步传输的月成本会增加 825 美元；而把架构从同步传输换成近源处理，即使不计网关费用，每月也能省下 2000 美元以上。

实验结论

实验说明，最大的经济效益来自减少跨云边界传输的数据量，而不只是挑一家出站费率更低的云厂商。异步处理把远程报表平台从面向客户的交易路径中拿掉，批处理、压缩和源头聚合则让重复传输数据的成本降下来。

报表平台要的是每小时汇总数据，不是完整的实时订单记录，所以近源处理是合适的选择。至于需要立即做出欺诈决策、授权响应或交易级审计数据的工作负载，可能还是得用同步或记录级通信。

成本作为非功能性需求

可持续的成本控制不是靠定期翻账单，而是把成本当成一项非功能性需求，用管理延迟或可靠性的同等严谨度去管。

图 1 展示的是如何把成本管理当作持续的工程关注点，而不是事后才做的财务核算。这个循环把软件生命周期的设计、构建和运行时几个关键阶段，串成一个统一的反馈系统。

流程从设计阶段开始。团队要在这个阶段预先定好成本预期：估算数据传输量、弄清服务部署在哪里、为跨云交互设好成本预算。这些早期决定为后面所有阶段立下基准。

到了实施阶段，可以加一个轻量级的验证步骤，依据部署元数据、预期请求量和有效载荷大小，估算预计的月出站流量。一旦估算出的网络成本超过预设阈值，管道就可以要求在部署前做架构审查。这种做法跟安全门、质量门类似，让工程团队在低效通信模式变成运营成本之前就把它找出来。

在构建阶段，这些预期通过 CI/CD 管道落地。自动化检查会验证新增变更——比如新加的跨云调用或更大的有效载荷——是否仍在既定的成本范围内。这套自动化机制能拦住低效模式，不让它们进生产环境。

运行时，系统持续盯实际成本。支出一旦偏离预期预算，警报就直接发给负责该服务的团队。这样成本问题就能像性能或可靠性事件一样被快速处理。

jobs:  cost-impact-analysis:    steps:      - name: Estimate cross-cloud egress impact        run: python3 scripts/estimate_egress_cost.py      - name: Require review if threshold exceeded        run: |          if [ "$EGRESS_DELTA" -gt "$THRESHOLD" ]; then            echo "Cross-cloud egress impact requires architecture review"            exit 1          fi

这类检查不必拦住每一次部署。它要盯的是重大变更，比如多出一条跨云依赖、有效载荷变大，或者上了新的实时同步机制。

运行时数据随后被优化循环拿来用，找出低效环节，再做针对性改进——削减数据传输、压缩有效载荷、调整同步频率都算。这些优化得到的洞察会进入事后复盘，团队据此修正成本模型，也让后续设计更合理。

三个阶段都建在 FOCUS 1.4 标准化层上。各云服务商的成本数据经它统一处理，服务层面的成本可见性因此保持一致，整个生命周期里的成本都能跟踪、比较和管理。

整张图讲的是一个闭环：规划、执行、监控和持续优化都被直接嵌进工程工作流，成本不再被当成独立的财务活动。

实际限制：目前尚不完善之处

FOCUS 能解决计费标准化，但基于因果关系的服务级归因它给不了。企业折扣、云市场服务费、NAT 和跨区域费用，还有共享平台分配，往往还得按具体提供商逐一映射。账单导出数据本身也是回溯性的，只显示实际收了多少钱，至于这笔流量是哪次运行时请求、重试或扇出操作产生的，它说不出来。标准化之后的成本数据，其实必须跟所有权标签、分布式追踪和网络流量日志关联起来。说到底，FOCUS 是标准化的底子，替代不了可观测性，也替代不了内部费用分摊逻辑。

最终得到的是一个闭环模型：设计阶段估算成本，交付过程中核查，生产环境里观测，结果再回流到架构决策。成本由此成为工程生命周期的一环，而不是一项独立的财务活动。

基于 FOCUS 的多云 FinOps 框架

实施路线图

阶段 1：实现成本可见性（1 到 2 个月）

把 AWS、Azure 和 GCP 提供的兼容 FOCUS 输出用起来，将各家账单导出数据汇入同一个数据仓库。资源标记规范在所有环境里统一，成本才能分摊到对应的负责团队和服务。再建一个仪表盘，专门回答一个核心问题：上个月每对跨云服务产生了多少出站流量？没有这个基准，后面每个决策都只能靠估算，而不是事实。

阶段 2：着眼于短期成果（2 到 4 个月）

拿第一阶段的归因数据，找出出站流量成本的主要驱动因素。回报最高的干预措施先上：在支出最高的路径上做压缩、批处理调度和 CDN 路由。这些改动不用迁移服务，目标路径上的出站流量通常却能减少 30% 至 60%。部署策略也要更新，未经审核的新增跨云集成不得进入生产环境。两到四个月内拿出可量化的成本削减，组织信心就起来了，第三阶段的资金也有了着落。

阶段 3：架构调整（4 到 12 个月）

短期成果到手、归因数据建好之后，就该动结构性成本驱动因素了。具体说，把高频调用服务收进同一云服务商的共享边界内，重新设计数据管道，让数据在源头就处理掉而不是传原始数据，成本审查还要写进架构决策记录。到本阶段结束，成本治理应当已是常规流程：设计阶段审查，部署阶段落实，运行阶段归因到服务所有者。

这三个阶段对应 FinOps 成熟度序列：先度量，再优化，最后制度化。每一阶段都在为下一阶段铺路。

多云 FinOps 指标

每月总出站流量有参考价值，可它下降也可能只是需求少了。下面这些指标诊断性更强，因为它们把账单和系统行为连在了一起。

小结

多云成本控制是一门工程学科，不是计费问题。出站流量上花掉的每一美元，都映出设计阶段做过的部署决策、同步频率或数据迁移模式，并最终变成运行时账单。

改进之路宜循序渐进：先建归因机制，再做优化，最后调架构。有的团队没有可视化就跳过归因直接优化，结果往往在错误的路径上砍成本。先把可视化建起来的团队则能拿出有力证据，为更难的架构变更提供合理依据。

从 FOCUS 计费查询入手，把前五大跨云出站路径排个序。逐条问：这条路径的数据传输，形式对不对、频率对不对、跨的边界对不对？这个问题的答案，比任何费率谈判都更有价值。

系统要这样设计：成本效率来自架构决策，而不是运维干预。