为何在此时重新比较边缘计算
- 年以前，「用 Cloudflare Workers 就够了」是许多日本企业的结论。然而自2025年起，Fastly Compute 的 WebAssembly 运行时趋于稳定，AWS 将 Lambda@Edge 更新为 CloudFront Functions 2.0，Akamai 提升了 EdgeWorkers 的内存上限，各方选项再度势均力敌。尤其对于布局东南亚（新加坡、雅加达、曼谷、马尼拉）的日本企业而言，各供应商的 PoP 分布与法规合规能力在战略层面举足轻重。
本文将从「冷启动」「实效内存」「每 GB-秒单价」「地理分布」「WAF/Bot 管理整合」五个维度对比四个平台，并提供按使用场景的选型矩阵。数值基于2026年4月的公开信息，以及本公司在东京、新加坡、孟买三个区域各持续1小时、1,000 req/s 的生产基准测试结果。
冷启动与实效内存
Cloudflare Workers 基于 V8 Isolate，冷启动时间几乎无法计量（p99 低于5ms），但单个 Isolate 的内存固定为128MB。Fastly Compute 使用基于 wasmtime 的 WebAssembly 运行时，冷启动 p50 约0.3ms、p99 约5ms，速度与 Workers 相当，同时内存可扩展至512MB。AWS Lambda@Edge 延续传统的 Firecracker MicroVM 架构，冷启动 p50 为150ms，p99 可能超过600ms，定期预热必不可少。Akamai EdgeWorkers 基于 V8，但 CPU 时间与内存上限按套餐分级，Dynamic 套餐上限为256MB / 200ms。
基准测试结论一目了然：「需要1ms级响应的热路径」选 Cloudflare 或 Fastly，「需要100ms以上重逻辑处理」选 AWS Lambda@Edge，Akamai 居于两者之间，对已签有 Akamai CDN 合同的组织而言，零额外成本使用是其优势。
``` # 东京 PoP 简单 JSON 返回 p99 延迟（2026年4月内部测试） Cloudflare Workers : 4.8ms Fastly Compute (WASM) : 5.2ms Akamai EdgeWorkers : 12.1ms AWS Lambda@Edge (cold) : 612ms / (warm) 38ms ```
每 GB-秒成本与计费模型
Cloudflare Workers 采用独特的「仅按 CPU 时间计费」模型，I/O 等待不计入费用。Bundled 方案每月500万次请求 + 50ms CPU 时间为5美元，Unbound 方案1,000万次请求 + 3,000万 CPU-ms 为5美元。Fastly Compute 采用「按核心实例月费」模型，1个实例起价50美元，超出时按量计费。AWS Lambda@Edge 按1ms 粒度的 GB-秒计费，查看者请求侧单价约为源请求侧的3倍。Akamai EdgeWorkers 基于合同计费，Dynamic 套餐每月50万次执行约500美元，超出按量收费。
以「每百万次请求 / 平均 CPU 10ms / 负载10KB」为口径估算实效单价：Cloudflare 约0.5美元，Fastly 约0.4美元（在核心实例合同范围内），AWS Lambda@Edge 约2.1美元，Akamai 约3.0美元。从简单单价来看，Cloudflare 与 Fastly 有压倒性优势。但 AWS 的数据传输在 CloudFront / S3 / DynamoDB 生态内免费，综合成本来看有时会出现逆转。
地理分布与日本至东南亚流量
日本发起、东南亚到达流量的 PoP 覆盖情况如下。Cloudflare 覆盖东京、大阪、胡志明市、河内、雅加达、马尼拉、曼谷、新加坡、吉隆坡等主要城市。Fastly 在东京、大阪、新加坡、香港表现突出，印度尼西亚与越南经互联互通运营商转接，平均 RTT 约增加20ms。AWS Lambda@Edge 依托 CloudFront PoP，覆盖东京、大阪、新加坡、雅加达、马尼拉、曼谷，但 Lambda 实际执行在最近的区域边缘缓存节点（东京、新加坡、孟买等11处），并非纯粹的 PoP 执行。Akamai 全球 PoP 数量最多，但运行 EdgeWorkers 的 PoP 仅为其中一部分。
追求「整个东南亚地区均等低延迟」首选 Cloudflare，「以日本、新加坡轴线为主」则可发挥 Fastly WebAssembly 的性能优势，「与 AWS 现有资产深度整合」则选 Lambda@Edge。面向东盟电商网站、需要在 p95 维持80ms以下的场景，Cloudflare + Durable Objects 分片在成本效益上表现最优，这是本公司三个项目一致得出的结论。
WAF / Bot 管理整合度
边缘计算早已不只是「执行逻辑」，而需与 WAF、Bot 管理、DDoS 防护一并评估。Cloudflare 的 WAF（OWASP 核心规则集 + 自有规则）、Bot Management、Turnstile 均在 Workers 同一管理界面完成，并可在 Workers 内直接引用 cf.botManagement.score 动态调整行为。Fastly 基于 Signal Sciences（2020年收购）的 Next-Gen WAF，支持在 Compute 内调用 RulesEngine。AWS 的 AWS WAF + Shield 在 CloudFront 层运行，在 Lambda@Edge 内需自行编写检查 event.Records[0].cf.request.headers 的逻辑。Akamai 的 App & API Protector（原 Kona）最为成熟，在金融行业至今仍是首选。
Bot 判定精度方面，四家企业均于2025年后迁移至基于机器学习的方案，OWASP ATP（自动威胁防护）检测率横向约95%，差距收窄。关键差异体现在「误报时的申诉流程」与「SOC 联动」——Akamai 与 Cloudflare 标准提供 SIEM 联动（Splunk / Sentinel / Datadog），Fastly 仅支持 Datadog，AWS 则需通过 CloudWatch 进行转换。
选型矩阵：按使用场景推荐
以下摘录自本公司客户提案时使用的选型矩阵。
- 超低延迟 API（1ms 级响应）：Cloudflare Workers 或 Fastly Compute
- 有状态边缘逻辑（协同编辑、信令）：Cloudflare Workers + Durable Objects 唯一选项
- 与现有 AWS 技术栈（S3 / DynamoDB / Cognito）深度绑定：AWS Lambda@Edge + CloudFront
- 金融、医疗等监管行业，重视 WAF / SOC 要求：Akamai EdgeWorkers + App & API Protector
- 月数亿次请求大规模 B2C，成本优先：Fastly Compute 月度核心实例方案
- 日本 + 东南亚全域一致 SLO（p95 80ms）：Cloudflare Workers
- 视频、图片实时转换（超过100ms 的 CPU 密集处理）：AWS Lambda@Edge 或 Fastly Compute（512MB 内存）
结论：告别单一平台依赖的时代
- 年的边缘架构中，对单一平台的依赖无论在技术上还是业务连续性上都构成风险。Cloudflare 大规模故障（2023年11月、2025年2月）和 AWS us-east-1 故障曾多次造成全球影响，在此现实下，采用「主用 Cloudflare，静态内容用 Akamai，批处理用 AWS」等多边缘策略的大企业正在增多。通过 OpenTelemetry 统一指标、Terraform 横向管理基础设施即代码，可在降低供应商锁定成本的同时保障可用性。
选型已不再是「选出最快的那一家」的问题，而是「按工作负载设计最优组合」的问题。基准数值会随时间过时，但平台设计理念的差异是长期有效的判断基准。将自身流量特性、监管要求、现有资产明确化，并以季度为周期定期复盘，是边缘时代的标准运营形态。