# 亚马逊云科技 RTB Fabric：广告技术公司的竞价收益增长引擎 > **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。 > > **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/ > > **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。 ## 一、基础信息 - **会议类型**：行业大讲堂 - **Persona**：行业创新者 - **时间信息**：6月23日 | 11:35 - 12:00 - **标题**：亚马逊云科技 RTB Fabric：广告技术公司的竞价收益增长引擎 - **PDF 资料**：有 - **视频回放**：有 ## 演讲人信息 ### 会议信息 - **地点**：上海世博中心（2026 亚马逊云科技中国峰会） - **日期**：2026年6月23日（Day 1） - **时间**：11:35 - 12:00 - **会议类型**：行业大讲堂 - **面向 Persona**：行业创新者 ### 亚马逊云科技演讲人 - **彭赟**：资深解决方案架构师 ## 二、会议资料 PDF 转录内容 --- Page 1 --- 2026年6月23日-24日 上海·世博中心 --- Page 2 --- 亚马逊云科技 RTB Fabric ---广告技术公司的竞价收益增长引擎 彭 赟 亚马逊云科技资深解决方案架构师 --- Page 3 --- 本次分享 广告技术行业的核心挑战 01 RTB workloads · Network · Cost · Operations 从行业挑战出发，看亚马逊云科技 RTB 隆重推出 亚马逊云科技 RTB Fabric Fabric 如何重塑实时竞价网络 02 Introducing 亚马逊云科技 RTB Fabric 三大核心能力解析 KEY OUTCOMES 03 Gateway · Modules · Traffic Management 您将收获什么 定价模型与成本优势 理解 RTB 工作负载痛点 04 Pricing · Real-world cost savings 掌握 RTB Fabric 架构 行业领袖背书 & 开始使用 评估自身成本节省空间 05 Customer testimonials · Getting started 了解快速落地路径 --- Page 4 --- RTB WORKFLOW · 业务背景 SECTION 01 实时竞价 (RTB) — 程序化广告的核心引擎 每一次广告展示，SSP / ADX / DSP 之间需在百毫秒内完成多轮请求与竞价响应 SSP ADX DSP ①Bid Request ②Bid Request 供应方平台 广告交易平台 需求方平台 代表媒体方 实时拍卖中枢 代表广告主 提供广告库存 撮合买卖双方 竞价投放广告 Supply ④Bid Response / No-Bid Auction ③Bid Response / No-Bid Demand KEY INSIGHT 单一广告位每秒触发数百万次跨平台请求，海量流量大部分以"No-Bid"结束 — 网络成本和延迟，直接决定广告技术公司的盈利能力 RTB = Real-Time Bidding · 每次广告展示通过 OpenRTB 协议在毫秒级完成竞价 --- Page 5 --- CUSTOMER CHALLENGES · 客户挑战 SECTION 01 广告技术公司在云上运行 RTB 工作负载，面临四大核心挑战 从合作伙伴对接到流量管理，每一环都是利润的隐形吞噬者 集成效率低下 网络性能瓶颈 ① ② INTEGRATION EFFICIENCY NETWORK PERFORMANCE 每接入一个新合作伙伴都需点对点对接， 公网走 RTB 流量延迟不可控、超时率高 单家对接动辄数月，扩展成本高昂 每多一毫秒，胜出率与广告收入直接下降 影响：错失合作机会、上线节奏滞后 影响：Win Rate 下降、Bidder 超时丢单 网络成本高企 运营效率瓶颈 ③ ④ COST OPTIMIZATION OPERATIONAL EFFICIENCY DTO + ALB 等公网带宽费用占比巨大， 无效流量需自行过滤、限流、做协议校验 无竞价（No-Bid）流量也按全价计费 每家自研一套基础设施，重复造轮子 影响：RTB 单位经济模型恶化 影响：工程资源被消耗在底层管道上 行业普遍痛点：网络成本可占 RTB 工作负载总成本的 50%+ --- Page 6 --- INTRODUCING · 隆重推出 SECTION 02 隆重推出 亚马逊云科技 RTB Fabric — 专为实时竞价工作负载打造 在云端专用网络上，与广告技术合作伙伴一起运行 RTB 工作负载的全新基础设施 80% 最多节省 80% 云网络成本 10 ms 个位数毫秒级延迟 绕开公网，通过 亚马逊云科技 专用骨干网络 优化的专用网络路径， UP TO LATENCY 运行 RTB 流量，DTO + ALB 大幅降低 超时率显著下降，Bid 胜出率提升 COST SAVINGS PERFORMANCE "模块化"提升交易有效性 小时 数小时完成对接，而非数月 在网络层内置流量管理、错误屏蔽、 合作伙伴无感知接入，无需改造现有系统， vs. MONTHS 协议校验、限流等模块，即开即用 配置时间可短至 5-10 分钟 MODULES EFFECTIVENESS TIME TO MARKET 基于交易的定价模型—与程序化广告经济学保持一致，只为发送的交易付费 --- Page 7 --- 亚马逊云科技 RTBFabric 亚马逊云科技 RTB FA B RIC 亚马逊云科技 RTB FA B RIC ② Bid Requests ① Bid Requests LB LB DSP ADX SSP Demand Side ③ Bid Response & No-Bid Ad Exchange ④ Bid Response & No-Bid Supply Side PRICING RTB Fabric 采用基于交易的定价模式，与程序化广告经济学保持一致，更符合广告技术行业的商业模式 --- Page 8 --- HOW IT WORKS · 工作原理 SECTION 02 RTB Fabric — 一张连接所有合作伙伴的专用 RTB 网络 广告技术合作伙伴通过 Gateway 接入 Fabric，流量在亚马逊云科技专用网络上流转，而非公网 亚马逊云科技 RTB Fabric Your company Your partners 专用网络承载 合作伙伴无感接入 网关内置 Modules 基于亚马逊云科技全球骨干，绕开公网 对方无需改造既有系统， 流量管理、限流、过滤， 延迟稳定、可观测 即使不在亚马逊云科技上也可对接 在请求到达应用前已完成 --- Page 9 --- CORE FEATURES · 三大核心能力 SECTION 03 RTB Fabric 的三大核心能力，覆盖从接入到流量治理 一组协同工作的能力，共同保证 RTB 流量的低延迟、低成本与高质量 01 02 03 RTB Fabric Gateway RTB Fabric Modules 自动网络流量分发 实时竞价网关 高级流量管理 智能路由 合作伙伴的统一接入点， 在网关内联运行的轻量逻辑， 根据合作伙伴位置和能力， 支持 Requester / Responder 双向角色 流量到应用前已完成过滤、限流、屏蔽 自动选择最优网络路径 可替代 ALB，内外部链路灵活组合 内置+ 自定义双模式 跨 Region 流量调度无需自行配置 PARTNER ENTRY TRAFFIC CONTROL AUTO ROUTING 三大能力协同工作 —接入即用、即用即省、即省即稳 --- Page 10 --- GATEWAY · 灵活接入 SECTION 03 RTB Fabric Gateway — 三种典型部署，合作伙伴零改造 无论合作伙伴是否在亚马逊云科技上，Gateway 都能搭起一座节省成本的桥梁 SCENARIO 01 · 内部链路 SCENARIO 02 · 外部链路 SCENARIO 03 · 跨区域 双方均接入 Fabric 单方接入，对方无感 跨 Region 全球分发 亚马逊云科技 RTB FABRIC FABRIC us-east-1 ap-southeast-1 SSP DSP DSP SSP Requester Responder Gateway 公网/亚马逊云科技 Gateway Gateway 收益最大化· 双方都享受最低费率 单边节省· 接入方独享 RTB Fabric 优惠 骨干网直连· 跨 Region 自动调度 推荐：有规模的 RTB 双方主动迁入 推荐：任意一方先行接入，逐步带动生态 推荐：全球部署的 RTB 平台 PARTNER EXPERIENCE 合作伙伴零改造接入 — 维持现有 OpenRTB 实现，Gateway 屏蔽底层网络细节 可替代 ALB，与既有架构平滑融合 · 单家配置时间约 5-10 分钟 External Inbound / Outbound Link 支持任意一方接入，渐进式生态扩展 --- Page 11 --- MODULES · 智能流量管理 SECTION 03 RTB Fabric Modules — 在流量进应用前完成治理 基于属性、特征、流量模式的内置控制· 内置模块+ 自定义模块双模式 流量管理 错误屏蔽 OpenRTB 过滤 限流器 TRAFFIC MANAGEMENT ERROR MASKING OPENRTB FILTER RATE LIMITER 基于属性、特征自动执行 RTB 处理过程中发生错误时， 基于 OpenRTB 协议规范 QPS 限流应对流量高峰， RTB 操作或集成自定义决策 屏蔽敏感信息保护下游系统 （格式、位置）过滤无效请求 保护下游 Bidder 性能 DEPLOYMENT MODES · 两种部署模式 自定义容器化模块 Marketplace 模块 CUSTOM CONTAINERIZED MODULES MARKETPLACE MODULES 在 RTB Fabric 网关内联运行业务逻辑， 在 RTB 网关旁运行的无服务器容器镜像， 优化延迟和性能，可读取共享缓存 基础设施由 亚马逊云科技 全托管 BETA 需联系亚马逊云科技客户经理申请 BETA 推出时配备内置亚马逊云科技模块，更多模块即将推出 --- Page 12 --- MODULES IN ACTION · 实战示例 SECTION 03 200 万 QPS 进入，只有 120 万有效流量到达 Bidder Modules 串联工作—流量在到达应用前完成40% 的预筛选 Format Geo Rate limiter SSP 2M QPS 1.2M QPS DSP VALUE OF PRE-FILTERING· 预过滤的价值 40% 0 ∞ TRAFFIC REDUCTION CODE CHANGES COMPOSABLE 40% 流量被预过滤 应用层零改造 模块自由组合 下游 Bidder 集群规模 Bidder 业务代码不需要 按需启用、按 Link 配置 可同步缩容 实现复杂的过滤规则 未来更多模块陆续上线 示例数据基于典型 RTB 流量画像· Modules 在1:1 Link 关系上独立配置 --- Page 13 --- FEATURE SUMMARY · 功能优势总结 SECTION 03 三大支柱合一，RTB Fabric 给到客户的承诺 从合作伙伴接入，到流量治理，到成本结构—全链路覆盖 01 02 03 简化接入 优化成本 降低延迟 SIMPLIFIED ONBOARDING COST OPTIMIZATION LATENCY REDUCTION · Gateway + Link 灵活组合 · 替代昂贵的 DTO + ALB 组合 · 亚马逊云科技 骨干网络专用通道 · 内部链路 / 外部链路双支持 · 基于交易计费，而非带宽 · 自动优化网络路径 · 跨 Region 自动调度 · 无竞价响应低固定费率 · 公网抖动隔离 · 对方无需改造，无感知接入 · Modules 过滤减少处理量 · 流量预过滤减少 RTT · 可替代 ALB · 分层折扣，规模越大越便宜 · 超时显著下降 RESULT 数小时完成对接，而非数月 最多节省 80% 网络成本个位数毫秒级延迟，胜出率提升 --- Page 14 --- PRICING MODEL · 定价模型 SECTION 04 定价与 RTB 经济模型同步 — 只为发送的交易付费 无预付承诺、无持续资本支出、无私人定价协议—公开透明 PRINCIPLE 01 PRINCIPLE 02 PRINCIPLE 03 PRINCIPLE 04 基于交易计费 分层折扣 No-Bid 低费率 单边付费 按 RTB 请求与响应数 2 万亿次以上享单价 无竞价响应单独计费 只为发送的交易付费 而非带宽计费 大幅下调，规模即优惠 且远低于普通响应 而非接收 PRICE TABLE · 计费分层结构 计费项目 分层 内部 · 欧美 内部 · 新加坡/东京 外部 · 欧美 外部 · 新东 RTB 响应/请求 2 万亿次以内 $4.5 / 十亿次 $4.5 / 十亿次 $34 / 十亿次 $45.33 RTB 响应/请求 2 万亿次以上 $1.5 / 十亿次 $1.5 / 十亿次 $10 / 十亿次 $13.33 RTB 响应包（超2K 部分） 分层适用 $0.0015 / GB $0.0015 / GB $0.011 / GB $0.0147 No-Bid 响应（低费率） 无分层 $0.5 / 十亿次 $0.5 / 十亿次 $3 / 十亿次 $3 / 十亿次 No-Bid = HTTP 204 标头响应，且≤400 字节· 超过400 字节按常规响应计费· 不计入响应大小均值 --- Page 15 --- REAL COST SAVINGS · 真实节省案例 SECTION 04 DSP 真实案例：每月成本从 $375K 降至 $90K — 节省 76% 基于真实 DSP 客户的 RTB 流量画像核算· 内部+ 外部混合接入 BEFORE · 直接接 ALB AFTER · 接入 RTB FABRIC 现状基础设施成本 RTB Fabric 总成本 DTO （公网数据传出） $351,000 迁入 RTB Fabric 内部链路（双方在 Fabric) $5,160 ALB （负载均衡） $28,000 外部链路（合作方未在） $84,470 SAVING UP TO 76% $379K $89.6K 月度合计 月度合计 无竞价（No-Bid）流量与中标流量同价计费 No-Bid 单独计费+ 内部链路享最低费率 85% 76% 月度成本节省$290K · 年节省超$3.4M $78K + $48K → $19K 另一 DSP 客户在更高内部链路占比场景下，实际节省达 85% BEST CASE DSP CASE 实际节省比例取决于内部/外部链路占比、流量规模· 接入越多生态伙伴，节省比例越高 --- Page 16 --- PRICING ASSESSMENT · 价格评估指引 SECTION 04 想评估自己能省多少？这些信息我们一起准备 根据您的角色不同，价格估算所需的关键指标也不同 作为请求方接入 作为响应方接入 REQ RES REQUESTER · SSP / ADX RESPONDER · DSP REQUIRED METRICS REQUIRED METRICS 每月请求次数 每月 Bid 响应次数 区分内部/外部合作伙伴占比 用于核心响应费计算 每次请求平均包大小 平均 Bid 响应包大小 影响响应包计费部分 超2K 部分按 GB 计费 合作方部署位置 每月 No-Bid 次数及大小 是否在亚马逊云科技/ 同 Region / 同 AZ No-Bid 单独低费率，影响巨大 下一步：联系您的亚马逊云科技解决方案架构师，我们将基于您的实际指标提供详细的成本节省评估 --- Page 17 --- “借助 Amazon RTB Fabric, GumGum 可以提高成本效益，从 而向 DSP 合作伙伴发送更多竞价请求，进而增加 GumGum 和 我们合作伙伴的收入。” Corey Gale Senior Director of Engineering, Global Cloud & Data, GumGum --- Page 18 --- “Amazon RTB Fabric 代表着广告技术基础设施向更开放、更互操作、更高效的 方向迈出了亟需的一步。随着生态系统日益全渠道化，像 Amazon RTB Fabric 这样的共享基础设施有望简化合作伙伴的连接，减少摩擦，并为买卖双方开辟 更智能的路径。我们很高兴看到 Amazon 投资于面向程序化广告未来的基础工 具。” Kyle Green VP, Marketplace Strategy, Kargo --- Page 19 --- “通过采用 Amazon RTB Fabric, Viant 显著提升了程序化广告供应链的效率和 透明度：在广告到达竞价方之前降低成本并优化流量。凭借 Amazon RTB Fabric 的早期使用权，我们平均节省了 80% 以上的网络成本（与公开定价相 比）。这些效率的提升使我们能够将资金重新投入到 Viant 平台的创新中，同 时保持我们在 CTV 和 AI 交叉领域作为独立市场领导者的地位。同样重要的是， Amazon RTB Fabric 也与我们对供应质量的关注相辅相成，而供应质量正是 Viant 提升广告客户绩效的众多途径之一。” Keith Petri SVP Product, Viant --- Page 20 --- “Amazon RTB Fabric 的部署过程非常顺利——只需点击几下即可完成，而且与我们现 有的基础设施无缝集成。我们无需重新架构或改动竞价系统，就能立即开始节省成本， 并立即与平台上的关键实时竞价合作伙伴建立连接。与主要合作伙伴的配置时间仅需 5-10 分钟，我们就看到了多项关键性能指标的立竿见影的效果，包括平均延迟降低 15-20%，广告支出增加 30%，以及在公共网络上的中标率提高 30%。更重要的是，与 公共定价相比，这些收益还伴随着网络成本降低 80% 以上，并且得益于 Amazon 网络 骨干的可靠性和弹性。” Sean Kumar VP, Infrastructure & Security, TripleLift --- Page 21 --- CUSTOMER OUTCOMES · 真实结果 SECTION 05 不只是降本，更是收入与效率的同时增长 TripleLift / Yieldmo / Amazon DSP / APS —实测数据，跨整个 RTB 价值链 80%+ 15-20% +30% 80% NETWORK COST LATENCY DROP AD SPEND & WIN TIMEOUT REDUCTION 网络成本节省 延迟降低 广告支出与胜出量增长 超时减少 较公开定价节省 关键性能指标改善 较公网增长30% Bid Rate 同步上升 5-10 分钟完成关键合作伙伴配置， 买卖双方需要一个中立、可扩展的 现有 Bidding 系统无需重构 — 网络以保持互通，RTB Fabric 立刻开始节省。 提供了行业期待已久的基础设施。 Sean Kumar Neal Richter / Scott Siegler VP Infrastructure & Security · TripleLift Director · Amazon DSP / Amazon Publisher Services 数据来自 GumGum / Kargo / Viant / TripleLift / Yieldmo / Amazon DSP / Amazon Publisher Services 公开证言 --- Page 22 --- GETTING STARTED · 开始使用 SECTION 05 现在就开始 — 三步落地 RTB Fabric 从评估到上线，与亚马逊云科技团队一起规划您的 RTB 现代化路径 评估 试点 扩展 1 2 3 ASSESS PILOT SCALE · 收集 RTB 流量画像 · 选择 1-2 家关键伙伴 · 全量伙伴接入 · 梳理合作伙伴清单 · 配置 Gateway + Modules · 跨 Region 流量调度 · 亚马逊云科技 SA 提供成本测算 · 真实流量验证 · 自定义 Modules 上线 TIMELINE: 1-2 WEEKS TIMELINE: 数小时配置 TIMELINE: 持续优化 NEXT STEPS · 联系我们 联系您的客户经理或解决方案架构师 由亚马逊云科技团队启动评估，提供定制化的成本节省测算与试点方案 --- Page 23 --- 反馈二维码 您的反馈信息对我们非常重要 请您扫描“调查问卷”二维码，填写问卷 --- Page 24 --- 谢谢 期待与您一起，重塑实时竞价的经济学 彭赟· 亚马逊云科技资深解决方案架构师 ## 三、会议回放视频转录内容 大家好，我是亚马逊云科技解决方案架构师彭赟。 接下来我给大家分享一个由亚马逊云科技新推出的服务，叫 RTB Fabric. 这个服务是专门针对广告行业推出的，用来帮助我们广告技术公司提升我们竞价收益的一个服务。 所以这是一个非常行业化、非常垂直的服务。 由于今天分享时间比较短，也不能够更加详细地讲解这个服务的很多功能。 希望我通过短时间给大家串一遍，然后让大家能够知道说 RTB Fabric 这个服务，它有什么样的功能特点。 能为我们广告行业解决什么样的痛点，带来什么样的收益。 希望大家听了以后能够说，我在什么样的情况下能想起来说，我可以用这个服务来试试。 首先在讲这个服务之前，或者讲这个产品之前，我们看一下在广告行业里面的一些业务情况。 在我们广告行业抽象的来讲，整个生态当中的参与者， 我们抽象可以把它分为供应方平台、需求方平台，跟广告交易平台。 所以我们日常打开一个手机，然后弹出一个广告的时候，它背后发生了什么事情。 其实我们手机的应用手机会去请求一个广告，这个请求会发到我们的 SSP. SSP 拿到广告请求以后，会把这个请求转发到 ADX，然后去请求一个竞价广告。 ADX 其实本身自己是没有广告的，它会把这个请求再传递到 DSP 去请求广告。 DSP 收到这个请求以后，就会判断说，这次的广告请求我要不要出价，要不要给出这个广告来。 所以它就会返回一个 BID 或者是 NOBID, NOBID 就是不带广告的时候，不参与这次竞价，我不返回广告。 所以当然 ADX 收到这个请求以后，再返回到最终我们看到的流量端。 所以实时竞价这个工作负载，它的特点我们就可以看出来，首先一个特点，它是流量比较大，就是 QPS 比较高的， 通常那种几十万到上百万的 QPS 很正常，所以第一个特点是 QPS 比较高。 第二个特点，它是对延迟比较敏感，竞价请求是有这个延迟敏感性的，你每降低一毫秒， 有可能你这个竞价就失败了，所以会很敏感。 第三个特点，就是它的流量比较大，大量的 QPS 会带来大量的流量， 所以在整个你广告平台的整体费用当中，流量费用的占比会比较高。 那第四个特点呢，就是说你有很大的 QPS, 但实际上这些上百万的 QPS 当中，真正给你产生价值的那些流量呢，其实少量的， 所以你大部分的响应都是 no bid 的，这些 no bid 的处理其实对你来讲是没有收益的， 所以这是这个程序化广告的一个特点。 那所以在这样的情况下，我们广告技术公司在云上去部署我们的广告技术平台， 部署我们的服务的时候，工作负载的时候，会面临什么样的问题呢？ 第一个，就是集成效率比较低，我们为了获得更多的流量，为了获得更多的预算， 我们在上游会接入很多很多的 DSP，我们在下游会接入很多很多的流量端， 那你要跟大量的生态当中的合作伙伴去对接，一个去对接的时候， 你的接入的成本，接入的时间是比较长的，在这个上花费的成本比较高。 通常你接一个对方要跟他的对接口调接口大概几周，甚至几个月的时间就过去了。 那第二个问题呢，就是网络的性能瓶颈。 我们刚才讲到这个 RTB 的工作负载特别就是对延时比较敏感嘛， 我们通过公网去访问你的对方，你的合作伙伴的时候，在公网上流量跟网速你是不可控的。 你一旦遇到一个这个丢包，遇到一个网络不稳定，你延迟一毫秒， 可能直接带来你的这个收入的下降。 第三个呢，就是网络成本高，我刚才讲到，流量成本占到你整个广告成本的50% 左右。 你大量的 QPS，你有这个有效的请求，有效的返回，也有 No-Bid 的。 这些呢，整个流量成本会比较高。 我们知道在云上，其实你是要，你的出口是要收流量费的。 所以这个呢，会带来你成本比较高。 第四个呢，就是运营效率，会成为你一个，作为一个广告技术公司， 你的运营效率的高低，直接决定了你是不是能够这个盈利的一个结果。 因为，其实你 QPS 还是很高，来了大量的流量，并不是所有的流量对你来讲都是能产生价值的。 所以我们通常要去做一些流量的过滤，流量的清洗。 流量，纵深越往后走，你需要花更多的计算资源去做这些流量的处理。 你就要付出更多的计算资源，这个带来的就是成本。 所以这四个痛点让我们广告技术公司就面临盈利的压力。 那在这种情况下，我们就推出了 RTB Fabric 这个产品。 这个产品呢，就专门为实时竞价的工作负载打造。 它有这么以下四个特点吧。 一个是流量成本，节约流量成本，最高节约。 这里我写了最高80%，实际在我们的案例当中，节约85% 流量费的这个案例也是有的。 因为它，我们提供了一个 RTB Fabric 专有的网络。 我们通过 RTB Fabric 这个网络去接入你的合作伙伴， 我们的收费模式就变了，不再是按流量费收费。 而且呢，也并不是你所有的流量都会去收费， 或者都用统一的价格收费，所以整个的成本呢，就会降得比较大。 另外呢，我们有这个专门的网络优化，会让你的网络响应，网络延时呢，会变得更低。 那第三个呢，在 RTB Fabric 这个产品当中，我们内置的这个 module 是这么一个模块， 这个模块呢，能够把我们那些刚才讲到的，你需要花大量的计算资源， 去做流量过滤，流量清洗的这部分工作呢，前置到 RTB Fabric 上去做。 那这个流量过滤的这个功能，越往前放，你后边的这个计算资源花费的就比较少了。 所以呢，能够降低你的整个计算资源的成本。 那第四个特点呢，就是能够降低我们的对接的这个时间， 大家统一的接入 RTB Fabric. 那整个生态都通过 RTB Fabric 去对接，我们的接入呢，基本上在数分钟，几十分钟就可以完成一次对接。 这个呢，是我们看到一个 RTB Fabric 的一个，你可以看到什么叫 RTB Fabric? 就是在我们的，我想强调一点的就是，我这里说的 SSP, ADX, DSP，我是把它抽象的去看。 实际上呢，指的是我们的上游跟下游，因为你可能是个 ADX，也可能是个 SSP，也可能是个 DSP. 如果你们是广告行业的话，其实当你号称 DSP 的时候，有可能，有可能你是个 ADX. 所以你总是有你的上游跟你的下游的。 当你跟你的上游跟下游去对接的时候呢，RTB Fabric 是在你们之间建立了一个专有的网络。 你之前是调你的合作伙伴的接口，那现在呢，你是要去调 RTB Fabric 给你提供的一个 Gateway. 由 RTB Fabric，帮你打通你跟你的合作伙伴之间的链接。 那这个服务呢，我刚才讲了它那么多功能，但我觉得其实它大规模的亮点，并不是给我们提供了那么多功能。 而是它是一个，我觉得是一次定价模式的一个颠覆。 我们知道你们如果使用云的话，都知道说云其实是按照底层的计算资源，或者底层的资源去收费的。 跟你上面跑什么业务，其实是没关系的。无论你这个业务盈利，或者你这个业务不盈利，它底层资源你只要消耗了，它就按照底层资源去收费。 那 RTB Fabric 第一次采用了跟这个广告经济学一致的一个计价模式。 它是怎么计呢，不再单纯的按照流量，或者是底层资源的方式去收费。 它根据你的广告交易的情况去收费。 我们刚才讲了，如果你这次交易是有效的，这次有效的交易，那它呢，正常的跟你去收费，按交易量收费。 按交易次数收费。 但如果你这次交易是无效的，是一个 No-Bid 的，那它呢，就会用非常非常低的一个价格来跟你收费。 那就是跟你的这个，跟你的这个自身业务的收益息息相关的一种收费模式。 所以我觉得这是一个比较创新，所以它能更符合广告行业的这个商业模式。 所以这个呢，是一个比较大的创新。 那我们可以看到，未来呢，就是说，它是一个生态，在我们整个广告行业里面。 当然这张图里面我画的是，目前已经接入到 RTB Fabric 网络当中的一些 global 的一些这个广告技术公司。 那实际上呢，国内也有很多公司接入了，那只是说，有些公司呢，不愿意让我们去公开，所以没有在这个图上。 那这是我们已经可以公开的案例，那实际上呢，会有更多的公司，已经接入到这个 Fabric 网络。 那未来的样子呢，就是，大家都形成一个生态，都接入到这个 RTB Fabric 网络。 你可以很方便的去发现，有哪家合作伙伴，接入了，你可以很方便的跟它去建立起这种连接来。 所以这是我们那个这个产品的目标，那通过 RTB Fabric，我们怎么实现刚才我讲到的那些优势，那些收益的呢。 它主要是有这三大核心能力。 第一个呢, RTB Fabric Gateway. 这个 RTB Fabric Gateway 呢，是整个 RTB Fabric 这个产品的一个核心模块。 我们通过这个 Gateway，去连接你跟你的上游，或者你的下游，你的合作伙伴之间的连接。 那这个 Gateway 呢，可以代替你原来的负载均衡器。 它除了可以帮你创建你跟你的合作伙伴之间的连接以外呢，它还能够做你流量的分发，流量的转发。 原来其实我们知道，在你的这个 workload 当中，除了你后端的计算资源，你的负载均衡器也是一部分很大的成本。 那有了 RTB Fabric Gateway 以后呢，可以代替到你的 LB，所以这是一个模块。 那另一个模块呢，就是我刚才讲的 modules. 这个 modules 模块呢，是你在你跟你的合作伙伴之间是通过 Gateway 去建立起这个连接的。 在 Gateway 之间呢，会有一个 link. 这个 modules 呢，是附在这个 link 上的一个模块。在这个模块里面，你可以去实现一些轻量的逻辑。 这些逻辑，首先会有一些内置的逻辑，比如说它可以去做一些流量的过滤。 你还可以去写自己另外的一些逻辑来做你想做的事情。 这样的话，把这部分的处理逻辑呢，就前移到了 modules 去做了。 第三个呢，可以做这个自动网络流量的分发。 我们可以让你尽早的接入亚马逊云科技的骨干网。 然后呢，底层呢，会有一些网络智能的路由网络的优化。 可以让你无需调度的快速的享受到最优的网络。 那我们可以分开来看我们，对，我们看一下 Gateway. 刚才我们讲，你跟你的合作伙伴通过 RTB Fabric，可以带来那么多收益。 那到底这个接起来是不是那么简单呢？ 这里嘛给大家讲，有三种接入模式。 第一种模式就是，你跟你的合作伙伴都在亚马逊云科技， 并且在同一个 Region 部署你的广告技术平台。 你们之前是直接对接的。 那现在呢，你们双方可以在一个共同的 RTB Fabric 专有网络上去对接。 它也接入一个 RTB Fabric 网络，你也接入一个 RTB Fabric 网络。 通过一个 Requester Gateway,跟一个 Responder Gateway,去建立起这个连接。 这是你们双方都能享受到的这个服务。 这个呢，会给你带来很大的，费率的降低。 但是呢，需要你双方都要去，都要去，去，去做这个对应的，改造。 都要去，把你的访问，把你的 endpoint 重新指到这个 Gateway 上。 那第二种模式呢，就是单方的接入，我在亚马逊云科技，对方在哪里无所谓。 你可以在无需通知他的情况下，你的合作伙伴无需做任何改造，无感知的情况下。 你自己单方面的，接入 RTB Fabric 网络。 你同样可以享受到 RTB Fabric 网给我们带来的那些刚才所讲的那一切收益。 那第三种情况呢，是你们都在亚马逊云科技，但是不在同一个 Region，不在同一个 Region. 比如说我在美东，对方呢，是在新加坡。 那在之前，如果你们对接的话呢，是要走很大的跨 Region 的流量费的。 那通过 RTB Fabric 网络，你们双方任何一方都可以自由的去接入 RTB Fabric 网络。 对方可以接，可以不接。 你自己可以在对方无感知的情况下，接入到 RTB Fabric 来享受 RTB Fabric 给我们带来的一些网络跟流量成本的收益。 所以有这么三种的接入模式。 那另外一个模块就是 module. module 呢，我刚才已经讲过说，是在 link 上附的一个模块， 这个模块里面可以放一些轻量级的逻辑。 现在呢，在这个产品里面内置了四种逻辑。 第一种逻辑呢，是 Rate Limiter 的。 你可以限定说，我这个服务呢，我需要限流。 比如说我只能承担这个100k 的 QPS，那超过100k呢，我就自动把它丢弃。 那之前呢，这个逻辑你需要写在你的自己的这个 workload 的这个前端。 这个需要你自己划计算资源去处理的。 现在呢，你可以把这部分呢，放到 RTB Fabric 的 module 上去处理。 那第二呢，可以去加一些过滤器。 基于 RTB Fabric 的那些属性，你可以去设定一些过滤。 比如说我这个，只要哪个国家的流量，或者不要哪个国家的流量， 或者根据那些属性做一些自定义的，自定义的 filter, 可以把一些不要的流量提前过滤掉。 那第三个呢，有这个错误屏蔽。 比如说你有些后台发生一些什么样的错误的时候， 你不希望这个错误直接反馈到你的合作伙伴， 你希望给一个自定义的错误提示， 那这个时候呢，你可以在 module 上去实现这个功能。 当然呢，在目前的规划当中还有一些功能， 比如说你可以自己做一个容器，部署到这个 module, 里面可以有你自己的逻辑，自己实现。 另外呢，未来会有个 marketplace, 我们这些 ISV，或者你们任何人可以开发自己的 module, 然后放到 marketplace，提供别人去订阅使用。 所以呢，这会是一个比较丰富的生态。 我们可以举个例子，比如说， 我们本来你来了这个200万的 QPS 的流量， 那其中呢，我其实有很多流量并不是说你想要的， 你通过加一些比如说地理位置啊， 或者是 rate limit 啊，或者其他属性的过滤器， 经过这些过滤以后， 实际上真正打到你系统的流量呢，就变成了120万。 那通过这种方式， 其实是把一些流量尽早的阻挡在了你的系统之外， 减少你系统资源的消耗。 这个呢，极大地提高了你的流量的利用率， 提升了你的资源效率， 当然你的成本也就会降低。 所以，总结下来呢， 我们 RTB Fabric 给我们主要提供了这么三个功能。 一个是呢，通过 Gateway 加 link, 这种方式呢， 简化了我们跟你的合作伙伴的接入。 第二呢，通过我们的计费模式的改变， 通过这个对 module 的方式去减少你的流量， 过滤你的流量，让我们节约成本。 第三个呢，是说，可以通过优化的网络， 帮我们降低网络的延迟。 刚才讲了它的特点， 然后也提到了，一直说降低成本，降低成本， 它是怎么降低成本的呢？ 这里面有一个它的定价的方式。 第一个呢，首先它是基于交易去定价， 我们知道，之前我们在云上呢， 是按照这个出口流量费去收费的， 一个 G 多少钱，这样流量方式定价， 那现在呢，我们是根据你的请求， QPS，根据你的 QPS 去定价， 另外呢，还有个分层， 就是你在两万亿次以下， 跟两万亿次以上， 我们有不同的一个定价， 那这样呢，就是你用的越多， 你的单价会越低， 另外就是我刚才一直强调的， 对 No-Bid 来讲， 我们会是一个比较低的一个， 这个价格，低的一个费率， 最后呢，就跟流量一样， 还是单边付费， 只有你流出的这方， 请求的这方去收费， 你接收方呢， 不会单独收费， 具体的费用， 我们可以看到下面有， 不同的 Region 价格会有些不一样， 然后就是有个内部跟外部的区别， 内部呢，就是我们刚才讲的那个， 你们还记得吗， 三个接入方式的第一种方式， 你们在同一个 Region, 接入了同一个 RTB Fabric, 这种呢，就是一个内部的方式接入， 那如果我接入了 RTB Fabric, 对方呢，没有接入， 这种方式呢，叫外部， 外部的接入方式， 这两种方式都有接收， 接收，跟我们原来 没有接 RTB Fabric 这种方式相比呢， 它都有非常非常大的成本节约， 只是内部的方式， 节约的会更多一些， 这是我们一个真实的案例， 我们根据客户的账单， 然后根据它的请求量， QPS，以及每个请求的 Body 的大小， 测算出来以后呢， 它实际上的成本节约呢， 能够达到76% 的样子， 这个在， 如果你是 DSP，跟你是 SSP, 这个节约呢，相对来讲， 会稍微有些差异， 因为如果你是 DSP 的话， 你还有个 ALB 可以节约， 如果你是 SSP 呢， 因为你是请求方， 所以呢，节约不了 ALB 的费用， 所以呢，相对来讲， 节约的稍微小一些， 如果你是 DSP, 你是流量的接收方， 然后你的节约的力度呢， 会更大， 如果我们想去评估， 我的当前的这个 Workload, 接入 RTB Fabric 合适不合适， 你可以去做一个评估， 评估方式呢， 如果你是请求方， 你可以收集以下这三个数据， 一个是你的每个月的请求次数， 然后你的请求包的大小， 然后你的合作方， 你的合作伙伴，他在什么地方部署， 然后如果你是一个响应方， 比如是 DSP, 要看你的 Bid 次数， No-Bid 次数， 以及每次 Bid 的响应包的大小， 那有这几个数呢， 我们有一个计算器， 大家可以通过这个计算器， 找你的 SA 来评估一下， 大概能省什么样的， 成本能省多少， 这个呢， 我们有一些其他的合作伙伴， 其他的广告技术公司， 他们之前使用以后的一些评价， 我们可以看到， 主要是， 我就不读了， 基本上说到的都是说， 能够帮我们降低成本， 能够帮我们， 减少网络的延迟， 然后能够帮我们提升， 接入的效率， 这是几个广告技术品牌， 那总结起来呢，就是说， 第一个， 确实网络成本， 节省了， 那第二个呢， 延迟呢，会降低， 第三个呢， 我们的广告的胜出率， 会增加， 第三个呢， 超时会减少， 我们刚才讲到， 对于一个广告技术公司来讲， 如果这三点做到了， 你的收益就会， 明显的会增加， 当然做到这三点， 其实也是广告技术公司， 现在面临的一个挑战， 所以最后， 如果， 你是一个广告技术公司的， 工作负载， 你想， 节约成本， 想提升你们的收益， 就可以来找你们的， 客户经理，或者 SA, 来做评估， 首先， 让你的 SA 帮你去， 评估一下，是否合理， 然后呢， 特别几个合作伙伴， 试着接入， 来看一下你的账单， 最后如果可以的话呢， 再把你们整个生态接入了， 我讲的内容呢，就这么多， 最后我想说， 如果你们是广告技术公司， 其实一定会面临成本的问题， 因为广告平台， 其实是这个， 利润比较薄的， 然后呢， 流量费用占比比较高， 那在这种情况下， 如果想， 提升你们的利润率， 那来亚马逊云科技， 试用 RTB Fabric, 可以帮你极大的降低成本， 然后这是一个二维码， 希望大家帮我做一个反馈。