在 Google Cloud 上部署网站、下载服务或图片 API，计算实例和存储有时不是账单里增长最快的部分。随着海外访客增多，Internet Data Transfer Out（出站流量，常写作 Egress）可能迅速上升。此时很多团队会问：接入 Akamai 能否让全球访问更快，同时降低 Google Cloud 的费用？
答案取决于采用的是 Akamai CDN 缓存、Akamai Cloud 计算与存储，还是二者组合。它们的计费对象不同，不能因为品牌相同就把云计算方案中包含的传输额度直接套用到 CDN 交付流量上。减少 Google Cloud 的出站字节数，也不等于总账单必然下降。
一、先把 Google Cloud 的 Egress 算对
在分析替代方案前，应当将账单至少拆成四组：
- 面向互联网的出站流量：由源区域、目标地区、Network Service Tiers、按量阶梯和具体 SKU 决定，部分服务走不同的计费路径。不要把所有地域流量简单乘同一个单价。参考 Google Cloud VPC 网络计费。
- 跨区域或其他网络转发：跨区域数据复制、负载均衡处理、Cloud NAT、专线或互连可能产生不同账单项；它们不应算作普通 Internet Egress 的一个统一价格。
- CDN 相关费用：无论是 Google Cloud CDN 还是第三方 CDN，边缘交付、缓存请求、回源/填充等都可能收费。Google Cloud 的Cloud CDN 官方价目表明确区分缓存命中、未命中以及非可缓存请求的成本。
- 非带宽支出：原始计算实例、持久盘、对象存储、日志、WAF、DDoS 防护和管理服务。只优化带宽一项，不应忽略迁移后其他费用的变化。
请用同一计费周期的账单导出数据核对 GiB/TiB，而不是把网络设备显示的 Gbps 峰值当作账单流量；1 TiB = 1,024 GiB。也要区分 HTTP 响应压缩前后的字节量以及按地区计费的响应头开销。
二、Akamai 的三种使用方式，节省的是不同部分
| 架构 | 主要变化 | 有机会降低的费用 | 可能新增的费用 |
|---|---|---|---|
| Google Cloud 直接面向用户 | 没有额外 CDN | 无；作为原始基线 | 原本的云出站费用 |
| Google Cloud 源站 + Akamai CDN | 静态和部分动态内容由边缘缓存交付 | 源站对互联网提供的重复内容流量 | CDN 交付、请求、回源、WAF、合同最低消费 |
| 静态资源或业务迁移至 Akamai Cloud，按需配合 CDN | Google Cloud 不再承担部分源站工作负载 | 对应源站的 Egress 与部分计算/存储 | Akamai Cloud 计算、存储、超额传输、迁移与双活成本 |
第二种方式的性能优势通常来自边缘更接近用户、降低源站请求数、减少高延迟的跨洲访问。但对实时交易、个性化登录页面、频繁变动的 API，如果内容不可缓存，缓存带来的源站流量减免就可能很有限。第三种方式需要实际迁移数据或工作负载；仅仅「申请 Akamai Cloud 账号」并不会改变 Google Cloud 现有应用的流量方向。
Akamai Cloud 的部分计算方案提供月度传输额度，超出额度后可能按地区收费。它的网络传输使用与费用文档还明确区分计入额度的公网出口、部分私网/同 VPC 流量以及对象存储出口，并说明全球池与特定数据中心池的区别。因此不能承诺「Akamai 全部出站流量免费」；应以计划规格、地域及当前合同核算。官方产品和价格入口见Akamai Cloud Pricing。
三、用缓存字节命中率测算：80% 命中不等于省 80% 总费用
假设某网站一个月向终端用户交付 10 TiB 内容，其中图片、JS/CSS、公开下载文件占大头，部署 CDN 后有 80% 的响应字节由边缘命中。为了说明计算方法，暂忽略预热、回源重试、验证请求、连接重用与地区账单差异。
- 未使用 CDN 的源站交付字节量：约 10 TiB。
- CDN 命中的边缘交付量：约 8 TiB。
- CDN 未命中需要回源的理论字节量：约 2 TiB。
- 源站理论卸载量：8 TiB；源站出口减少约 80%。
这不是「总成本减少 80%」：源站可能仍支付约 2 TiB 的相应网络费用，CDN 则为全部 10 TiB 的终端交付及其他服务收费；部分配置还有独立的回源成本。不同源站接入模式还可能适用专门的网络互连计价，不能把上表生搬硬套到每一张账单。
可以先使用以下可复核模型：
直接交付总成本
= Google Cloud 原有计算与存储 + 原有出站流量 + 其他相关服务
使用 Akamai CDN 后总成本
= Google Cloud 保留的计算与存储
+ 实际 Google Cloud 源站出口及相关互连费用
+ Akamai CDN 交付流量费、请求费和附加服务费
+ 仍需支付的负载均衡、日志、安全和存储费用
迁移部分业务至 Akamai Cloud 后总成本
= 留在 Google Cloud 的工作负载及流量费用
+ Akamai Cloud 实例、对象存储、超额传输等费用
+ CDN（如有）和跨云数据同步费用
+ 迁移摊销及双活期费用
如果需要更直观的代入，可假设源站出站平均有效价格为 P元/GiB，CDN 综合交付价格为 C元/GiB，回源和固定费用合计为 F元。在原有 10,240 GiB、CDN 字节命中率 80% 的理想模型里：
不使用 CDN 的流量成本 ≈ 10,240 × P
使用 CDN 的相关流量成本 ≈ 2,048 × P + 10,240 × C + F
只有当后者更低，且性能、稳定性与维护成本仍合适，才称得上这部分费用获得净节省。这里的 P/C/F 都必须来自双方实际 SKU 或报价，不是本篇给出的厂商现价。此外，在一部分 CDN 供应商的合同中，最低消费、峰值请求量、超额 WAF 请求或特定区域加价会显著改变模型。
假设账单演算：缓存节省多少才有意义？
为了展示算法，假设一个月对外发出 10 TiB 的静态资源，先统一按 1 TiB = 1,024 GiB 估算，原 Google Cloud 互联网出口暂按 0.10 美元/GiB、CDN 用户交付按 0.04 美元/GiB、其他 CDN 固定费按 100 美元/月计；三个数字均是虚构的建模参数，不代表 Google Cloud、Akamai 的现实报价。若有 80% 的字节缓存命中率，且忽略响应头/缓存回源次数等差异，则旧账单为 10,240×0.10＝1,024 美元；新架构模型为 2,048×0.10＋10,240×0.04＋100＝714.40 美元；差额为 309.60 美元。若源站填充、区域出口、请求费和合同保底额提高，则上述差额可能缩小、归零或转负。
因此采购时不要直接比较「每 GB 官网标价」：先用同一结算周期、相同币种和单位，记录实际源站字节数、CDN 交付量、缓存未命中回源、WAF/加速附加费、税费、折扣有效期与采购门槛，再还原真实账单。
四、CDN Interconnect 不能想当然套用
Google Cloud 有 CDN Interconnect，让参与该计划的特定第三方 CDN在支持的位置使用直连路径，相关出站流量可能适用不同计价。但必须核查两件事：一是选定 CDN 提供方、源站位置和流量路径是否满足条件；二是该路径实际落在哪个收费 SKU。
不能因为 Akamai 提供 CDN，就自动认定某个 Akamai 产品、某个源站区域或某条线路必然享受 CDN Interconnect 优惠。采购之前应由 Google Cloud 账单明细及 CDN 服务商确认支持情况，并做小流量测试。对于大规模回源流量，路由优惠可能有价值；对于命中率已经很高的网站，额外节省可能相对有限。
实用检查：Akamai 是否支持 Google Cloud 互连路径？
Akamai 的配置文档明确列出了「Cloud Interconnects for Google Cloud (GCP)」行为，可通过专用网络互连（PNI）将边缘节点的回源流量送往 GCP 源站，并按亚洲、欧洲、北美等选项选择源站区域。文档也强调只有受支持的源站区域才可能享有相应回源出口优惠。Google Cloud 的CDN Interconnect 说明进一步要求选择支持的 CDN 供应商与位置。存在官方集成选项，不代表任意 Akamai 产品、任意源站或全部流量都会自动按折扣价结算；须由双方对账户、区域和实际计费 SKU 逐项确认。Akamai Cloud Wrapper 也属于需要确认合同与配置前提的源站卸载方案，不能当作免费附赠。
五、真正影响性能的四个指标
1. 字节命中率优先于请求命中率。10 万次 2 KiB 的 API 小请求即使命中，节省的字节也未必超过一个几 GiB 大文件。分别记录 cache hit ratio（请求维度）和 byte hit ratio（字节维度），并分地区、文件类型和路径统计。
2. TTFB 和最终用户体验。对比接入前后 TTFB、页面最大内容绘制（LCP）、大文件下载速率和失败率。缓存可能改善部分地区的响应，但也可能受到源站首字节延迟、TLS 配置和动态页面逻辑限制。
3. 回源架构。避免多个 CDN 节点反复向同一源站拉取相同对象；按服务商支持的功能评估 Origin Shield、区域化回源、合理的 Cache-Control、压缩与图片变体。公开静态内容适合更长 TTL；涉及个人数据、Cookie 或授权信息的响应不可为了提高命中率而错误地公开缓存。
4. 退出与可迁移性。缓存规则、WAF 策略、证书、DNS 和日志接口是否容易迁移？最低合同期限、保底流量和终止费用可能抵消短期节省。
对回源逻辑有兴趣的读者，可进一步阅读站内《Akamai Cloud Wrapper 与 Fastly Shielding：源站卸载如何选？》，本篇侧重账单与迁移决策。
六、建议采用四周试运行，而不是一次性全站切换
第 1 周：建立基线。按源区域、用户地区和 SKU 导出至少一个完整账期的出站量、月账单、错误率、P95 TTFB，标出可以缓存的路径和不能缓存的 API。
第 2 周：控制变量灰度。选择一组公开且稳定的静态资源，通过独立子域或小比例流量接入 CDN。确保缓存键、Cookie、Authorization、Vary 头和失效逻辑正确，避免跨用户缓存泄漏；对账时只比较这组资源。
第 3 周：验证高峰与安全。模拟或观察真实高峰，关注 CDN 命中与回源带宽、DDoS/WAF 策略、缓存污染及区域故障恢复。压测前必须获得平台授权，不能把短时压测的高命中率当成稳定业务结果。
第 4 周：按实际账单决定。用 Google Cloud 真实减少的费用 - Akamai 真实新增的费用 - 迁移/运维增量 判断净收益；若净收益不佳，可只保留命中率高的静态资源，或评估将特定下载、图片处理、对象存储业务整体迁至更合适的源站。正式签长约之前保留可退出路径。
七、哪些场景值得优先研究 Akamai？
大体积静态资源、面向多洲用户的内容站、下载与软件分发等场景，存在较明确的边缘缓存卸载空间。大量个性化 API、不可缓存的低延迟交易或需要频繁跨云数据库访问的服务，则应首先优化应用架构、数据传输和缓存策略，而不是假设 CDN 可以解决所有 Egress 问题。
最终判断标准不是某一家云厂商的宣传口号，而是用户真实体验改善了多少、Google Cloud 实际减少多少可计费出口、Akamai 新增多少费用，以及迁移后能否稳定运维。三个数字都来自同一时间窗口的观测，才能做出可靠的成本决策。
交流与讨论