我们在 AWS、Azure 和 GCP 上运行了 7,600 多个云供应测试——以下是我们的发现

Source: Dev.to

引言

没有人公开这些数据，所以我们自己测量。云厂商会提供正常运行时间 SLA、计费计算器和功能对比表，但他们并未透露实际的资源创建需要多长时间——以及创建失败的频率。为填补这一空白，我们构建了 ProvisioningIQ，它持续真实调用 API（不做模拟），在 AWS、Azure 和 GCP 上创建并随后销毁资源。

方法论

• 范围：7,600 多次真实的创建测试（虚拟机或无服务器容器）。
• 频率：每天 3 次，跨每个云的三个地区，自 2026 年 1 月起持续运行。
• 流程：
  1. 创建真实资源（虚拟机或无服务器容器）。
  2. 在每个阶段记录时间：API 接受 → 分配中 → 就绪 → 可访问。
  3. 记录成功/失败以及失败类别。
  4. 立即销毁资源。

容器创建时间

观察：在 p50 水平上，GCP Cloud Run 的创建速度比 Azure ACI 快 10–20 倍，并且这种优势在所有测试地区都保持一致。

虚拟机创建时间

观察：AWS 在虚拟机方面领先，拥有最快的 p50 延迟和最高的可靠性。GCP 的虚拟机明显比其容器慢，使得 Cloud Run 成为对延迟敏感工作负载的首选 GCP 方案。

关键要点

• 值班影响：工程师面对的是 p95，而不是平均值。

  • AWS 容器 p95：约 40 秒
  • Azure 容器 p95：约 60 秒
  • GCP 容器 p95：约 20 秒

• 事件响应：20 秒的恢复（GCP）与 60 秒的恢复（Azure）之间的差距，可能决定用户是否会注意到故障。

• 地区差异：不同地区的创建时间差异显著。维护窗口期间，特定地区的创建时间可能临时翻倍，而供应商并不会对这些峰值发出警告。

• 决策因素：

  1. 负载下的自动扩容
  2. 灾难恢复速度
  3. CI/CD 流水线的速度

  更快的创建时间直接转化为可观的工程时间节省（例如，每个团队每年约可恢复 144 小时）。

其他洞察

• 谈判缺口：云合同通常涵盖价格、存储、网络出站流量和正常运行时间 SLA，但从未涉及创建延迟。业界没有针对该指标的统一承诺或基准。

• 未来基准：我们正在将测量范围扩展到托管数据库（RDS PostgreSQL、Cloud SQL、Azure Database for PostgreSQL）以及 Terraform 步骤级别的计时，以精准定位各云在创建过程中的耗时环节。

ProvisioningIQ 产品

• 免费层：每日基准快照，访问地址 provisioningiq.appswireless.com。
• 专业层：90 天历史记录、p50/p95 趋势、按地区的失败分析以及每日邮件摘要。

关于方法论、失败分类或清理处理有疑问？请在评论区留下。