文 | 刀客 doc
10 月 31 日，亚马逊发布 25 年第三季度财报：其旗下云计算业务 AWS 收入实现近三年来最快增速，这带动公司对下一季度的销售额预期高于市场预估，从而在盘后交易中股价大涨约 14%。
在分析师电话会上，CEO Andy Jassy 表示：" 从目前的增长势头来看，我相信我们能够在接下来的时间里保持这样的发展节奏。我认为我们在多个领域都具备持续增长的潜力。" 他指出，这其中包括广告业务和零售销售。
就在 10 月 23 日，AWS 推出了一项名为 RTB Fabric 的新服务。根据官方的解释，它是一个面向实时竞价（RTB）广告场景的云托管产品，核心就是缓解广告技术公司在跨平台连接中常见的性能瓶颈，其中之一就是延迟问题。
这一举措被认为是 AWS 在广告营销行业上的一个重要举措。
因为在程序化广告世界里，竞价必须在极短的时间内完成：当用户打开一个 App 或网页，后台会立刻触发一次广告竞价：不同广告商同时出价，系统要在几十毫秒内选出最高价并返回结果。
问题在于，广告公司分布在不同的云上、不同国家、不同系统里，信号在传输时绕来绕去，速度就会产生延迟，进而影响广告主的投放效率。
简单来说，RTB Fabric 就是亚马逊在公有云的基础上，专门为 DSP、SSP、adx 等广告技术公司铺了一张低延迟的云服务。这些公司不再需要自己去搭建复杂的点对点连接，只要接入这张网，就能在 AWS 的基础设施上完成广告请求的传输和竞价。
从亚马逊的描述来看，这项服务主打 " 个位数毫秒级延迟 " 与最高可达 80% 的网络成本优化，并整合了包括 Amazon Ads、GumGum、Kargo、MobileFuse、TripleLift 等合作方在内的链路资源。
过去人们对亚马逊广告业务的关注往往聚焦在 Amazon Ads 上，
这一次对广告行业的举措，出手的是 AWS。虽然与 Amazon Ads 分属不同部门，不过目标指向如出一辙：谷歌。
其实，大厂之间的广告竞争，暂时可以分为两层来看：
第一层是我们最熟悉的，也是广告行业最 " 显眼 " 的部分——平台之间的较量。
广告产品、投放工具、闭环能力、预算承接……所有和广告主、代理商直接打交道的环节，都在这层发生。这一层拼的是转化效率、数据能力，还有对投放链路的掌控力。
但还有另一层，不那么为人所见，却同样关键——更基础的广告 " 云 " 层。
它服务的不只有广告主和代理商，还有负责 " 搭系统 " 的广告技术（Ad Tech）公司。这个层面比拼的是更基础的东西：算力调度、延迟控制、跨平台连接能力，以及数据传输的稳定性。
01
我们先看第一层。
在广告市场，谷歌依然具有巨大的统治力，也因此不断成为反垄断审查的对象。所以谷歌很明显是守擂的一方，而亚马逊依然处于推进阶段。
谷歌几乎主导了 RTB（实时竞价）的底层协议。
这到不是说谷歌定了 RTB 的规则，行业里早已有 IAB（互动广告局）制定的 OpenRTB 标准。
但是因为谷歌在整个广告链路里占据了太多关键节点、占据着绝对性的市场份额——从流量入口到交易通道，再到通信协议，它几乎都在场，所以市场里的行业标准依然不可避免地被谷歌生态 " 校准 " 了方向。
因为当广告主想和最大的流量源、最大的买方平台（DV360）、最大的移动系统（Android）建立连接时，就必须确保——自己的请求格式、数据字段、加密方式、连接节奏，都能在谷歌的系统里跑通。
十多年下来，整个 RTB 世界已经在谷歌的协议和传输逻辑上，沉淀出巨大的惯性。
当然了，理论上广告公司可以不走谷歌那条 " 默认高速 "，但要付出代价。
要么自己修路——也就是去和各大媒体、平台做直连，在主要城市部署服务器、拉专线、做多区域备份和隐私合规。那是一笔真金白银的投入，还有人力投入。如果无法在市场上形成规模，这样的基础设施建设往往得不偿失。
另一种做法是 "借非谷歌的路"。可以对接多个第三方交易所（如 Magnite、PubMatic、OpenX 等），或者使用一些开源中间层（如 Prebid、APS），再加上零售媒体和 CTV（联网电视）平台的流量，绕过谷歌的高速，走一条更分散的省道。
听起来确实更灵活，选项更多，但实际操作远没有这么轻松：每家系统的对接标准都不同，用户身份体系也不兼容（有的用 UID2，有的用 RampID，还有的全靠自家第一方 ID）。广告请求虽然能发出去，但协议五花八门，数据结构不统一，连用户是谁都要重新翻译一遍。
结果就是，" 省道 " 虽然没收费站，但不够直、不够快、也不够稳。广告公司得花大量精力维护接口，做跨平台的统一识别和频控管理。碎片化是自由的代价，也是效率的挑战。
亚马逊选择架桥铺路，自己做基建。
对那些不愿将自己的广告系统搭建在谷歌生态上的公司来说，RTB Fabric 的出现提供了一个现实可行的替代方案。
它的大概逻辑是这样的：
它不改 OpenRTB 所谓的交通规则，是把在 AWS 上的伙伴拉到同一条托管快道上。只要双方同云同区，非谷歌路径也能跑出高速的平顺感。
这样广告请求可以不经过谷歌的协议链路，也能完成实时竞价。你只要用我的接口，自动获得和谷歌差不多的传输速度，但更便宜、更开放。
从对谷歌的影响看，结合美国司法部（DOJ）对谷歌广告的反垄断起诉，就有了更清晰的对比视角：
DOJ 反垄断是在 "监管层面" 拆谷歌广告业务的塔，AWS 是在 "技术层面" 松谷歌广告的地基，多少有点釜底抽薪的意思。两者的结果其实相通：都在削谷歌对广告系统的控制力。
02
在云市场，双方攻守易型：亚马逊是主导方，谷歌是更进取的一方。
根据 Synergy Research Group 的二季度数据，AWS 是全球云基础设施服务领域的绝对领导者，市占 30%，谷歌占比 13%。
广告技术公司历来是 AWS 的大客户，正如在分析师会议中对广告业务的提及，在 AWS 的官网行业分类里，广告与营销业务是 11 大垂类行业之一。
在云计算的诸多行业中，广告科技公司可能是最早一批 " 全栖云端 " 的使用者——他们需要极高的计算吞吐能力、实时的数据处理、以及对全球节点的弹性调度，而这些，AWS 恰好擅长。
从 AWS 的官网看，过去十年间，不少包括雅虎 DSP、the trade desk 等公司几乎都把 AWS 视作默认选项，有的处于稳定定，有的出于与谷歌广告业务的竞对关系。
不过这种 " 默认 "，开始在过去几年被撼动。
从整个云市场来看，谷歌在二季度的增速达到 32%，AWS 只有 17%。三季度财报显示，AWS 收入同比增长 20%，高于市场预期的 17.95%。（Synergy Research Group 数据）
GCP 在广告行业的渗透，谷歌向潜在客户抛出的计算积分（credit）极其慷慨，直接抵扣费用，变相 " 补贴 " 迁移成本——这让不少广告技术公司开始认真考虑 " 搬家 "。
" 过去三年里，谷歌下手相当狠。" 一位参与 RTB Fabric 测试计划的广告技术公司高管对行业媒体 digiday 说。
他认为，AWS 推出 RTB Fabric，很大程度上就是对谷歌云攻势的一次回击。" 因为很多广告技术公司已经转向使用 GCP"。
就 10 月中旬的时候，广告集团 WPP 与 GCP 签署了一项协议：双方合作关系将继续延长五年，WPP 承诺投入 4 亿美元用于谷歌技术和云服务。
广告行业是一个特殊的垂直领域——数据密度高，时延要求极致，一次竞价需要毫秒级完成，一场活动可能动用数十亿条请求。
在这个语境下，" 云 " 就是一种直接影响竞价效率、广告收益的关键变量。
AWS 的优势过去是 " 通用性 " 和 " 稳定性 "，而无论是计算补贴、客户绑定，还是与广告集团的深度捆绑，谷歌云在用一种近乎 " 贴身肉搏 " 的方式向广告技术公司争夺份额。
OpenX 的工程高级副总裁 Joel Meyer，OpenX 与谷歌的 GCP 的多年合作伙伴。
他对媒体 digiday 说：AWS 推出的 RTB Fabric 显示出云计算在当前广告技术格局中的价值——在这个需要快速反应、快速上线新方案的行业背景下更是如此。
" 他们正在努力简化 RTB 领域中存在的种种复杂性……如果这个方案成功，我认为它将迫使谷歌也推出类似的产品。" 他认为，" 云计算的本质，就是降低创新门槛——无论是扩展 AI 解决方案，还是实现实时集成，而 RTB Fabric 其实正是推动这一目标的最新一步。"
03
谷歌手里有全球最完整的广告系统，从广告主、投放平台，到媒体资源，几乎每一个环节都有布局。它还有谷歌云平台 GCP 这个全球前三的云服务商，技术能力一流。
按理说，它也可以修出一条 " 广告专用的云高速 "，像亚马逊这次做的 RTB Fabric 一样。
这里的问题是，谷歌一直是广告市场老大，为什么没有先一步做出类似 fabric 的产品？
答案可能是：现在不方便做。
谷歌正在被盯得很紧，特别是在美国和欧洲，反垄断的官司一个接一个。这个时候，如果它再推出一个 " 所有广告都跑在我这条云轨道上 " 的服务，不管初衷是什么，都会被外界看成是在进一步巩固垄断地位。
想想，之前要取消 cookie 的时候，谷歌就推出了隐私沙盒的方案，英国的反垄断机构就立刻开启了事前审查机制，最终沙盒方案在 6 年后搁浅。
在这种 " 风口浪尖 " 的阶段，谷歌的策略只能保守一点，少惹麻烦。
还有一个是不同生态位，做出的不同战略选择。
对数字广告来说，精准是目的，速度是手段。
这几年谷歌广告把更多火力放在 " 算得准 " 的一侧，而不是跑得快。
谷歌这些年在模型与测量、Ads Data Hub、隐私计算与归因工具，目标是让广告主更聪明地花钱。
不过谷歌并不是不做速度与网络：它只是没有把 "RTB 低时延 " 产品化。
换句话说，谷歌更多依赖通用云 + 个案工程去追速度，而不是把 " 快 " 变成一个独立、标准化的商品卖点——这正好给了 AWS 一个切入口。
从目前来看，我们很难说谁对谁错。
在广告领域，谷歌和亚马逊的生态位本就不同，打法自然也各有逻辑。
谷歌是行业的领导者，这一地位使它更倾向于维护现有秩序，强化生态闭环，确保平台收益最大化。在它的系统里，即便开放接口，真正的优先权也掌握在自己手中。
而亚马逊，则是一个仍在扩张中的挑战者。
它的广告业务并不是独立存在，而是深度嵌入在零售、内容、数据、物流等更大一盘棋中。它更关注 " 全链路 " 的掌控——从用户触点、转化行为，到最终的订单与履约。
这让它的策略更具侵略性，也更务实。
所以我们看到的，不是谷歌做不到，而是它一方面投鼠忌器，一方面在当下生态位上的自然选择。
总之，谷歌和亚马逊两种路线，一种是制定规则，一种是重新定义问题。
04
对于整个广告生态而言，正在发生一种悄然但深刻的变化。
平台之间的竞争，正从前台的流量争夺、预算分配，延伸至后台的云服务。在数字广告这个技术高度密集、传输极度敏感的行业中，" 谁掌控了链路 "，往往也意味着 " 谁掌控了规则 "。
正如鲁迅所说，地上本没有路，走的人多了，也便成了路。
RTB Fabric 能不能跑出一条新路，关键不在技术规格，而在行业意愿。
广告技术公司是否愿意把竞价请求交由 AWS 调度？是否愿意放弃对协议链路的自主掌控，把 " 方向盘 " 交给一家平台型公司？这不是工程问题，而是信任问题。
而最现实的矛盾也恰恰源于这一点：亚马逊，不只是云服务提供者，它自己也做广告。
AWS 虽然只是 " 跑数据 " 的管道，但当这个管道足够宽、足够快，足以承载起整个广告请求的实时传输时，中立的基础设施的定位还成立吗？
如果一个控制传输链路的公司，同时也有自己的广告业务，那行业是否可能再次走进 " 谷歌广告垄断 " 的老路？
虽然 AWS 与 Amazon Ads 在组织架构上属于不同体系，但行业里没有人会天真地认为二者之间是完全割裂的。
这就是为什么，RTB Fabric 在带来 " 非谷歌选项 " 的同时，也让行业多了一层新的焦虑。
对亚马逊而言，这场基础设施的重构，是一次雄心勃勃的布局，也是一场需要耐心的豪赌。
赌的是行业对谷歌广告生态惯性的松动，也赌他们愿意为一条看似更开放、可控的链路重新下注。
只有当更多人愿意上车，新的秩序才有可能真正成立。
否则，它就只是一条速度很快的 " 备用道 "。而主路依旧会在谷歌手中。
