多云Spot实例对比：AWS/Azure/GCP 2026

最后更新：2026年9月6日

AWS EC2 Spot、Azure Spot VMs 和 GCP Spot VMs 都是通过复用云服务商闲置容量、以最高约90%折扣（相较于按需价格）提供可中断计算实例的产品，三者在中断通知窗口、最长运行时长、竞价机制和 Kubernetes 集成路径上存在关键差异。老实说，选错一个可能让你的批处理管线每天要重跑好几次。本指南基于我在2026年为跨云工作负载做基准测试的实测数据，对比 AWS Spot、Azure Spot 与 GCP Spot 的价格、中断率、抢占策略和真实工作负载适配，帮你在多云架构中做出合适的 Spot 选型。

三家云 Spot 平均折扣区间：AWS 70–90%、Azure 60–90%、GCP 60–91%（2026 Q3 实测，因区域和实例类型浮动）。
中断通知窗口：AWS 提供2分钟、Azure 提供30秒、GCP 提供30秒（并额外发送 ACPI G2 软关机信号）。
GCP Spot VMs 自2022年起已取消24小时强制中断限制，Azure Spot 无最长运行时长；AWS Spot 同样无固定最长时长，但受容量池波动影响。
Kubernetes 场景推荐使用 Karpenter（AWS）、Cluster Autoscaler + 节点池（Azure/GCP）搭配多实例类型池化以降低单一容量池耗尽风险。
Spot 最适合无状态、可重试、批处理与 CI/CD 工作负载；有状态数据库和长事务应使用按需或 Savings Plans。
2026 年三家云都强化了 FOCUS 1.2 计费导出，Spot 折扣可直接映射到统一的 EffectiveCost 字段，便于跨云成本归因。

Spot 实例与按需实例有什么区别？

Spot 实例（Azure 叫 Spot VMs，GCP 曾叫 Preemptible VMs，2022 年后统一改名 Spot VMs）是云服务商把数据中心中未被按需和预留实例占用的闲置容量以极大折扣拍卖给用户的产物。核心权衡其实很简单：低价换来可中断性。当区域内按需请求飙升、或该实例类型容量池耗尽时，云平台会在很短的通知窗口内回收你的 Spot 实例。

相较之下，按需实例（On-Demand）价格稳定、不可回收，是零风险默认选项；预留实例（RI）和 Savings Plans 通过1年或3年的承诺换取30–72%折扣，但灵活性差。Spot 与承诺型折扣可以叠加使用：Savings Plans 折扣先应用到按需部分，Spot 折扣独立生效。我在一个 Kaggle 训练平台的迁移案例中，把80%训练节点切换到 Spot，月度 EC2 账单从 $48,200 降到 $9,600，同时把剩余20%控制节点绑定 Compute Savings Plans 兜底可用性。这种混合结构比单一策略更稳健，也更容易向财务部门解释账单构成。

关于 AWS 的承诺型折扣该怎么选，我在AWS Savings Plans vs Reserved Instances 完全对比里做了更详细的横评。

AWS/Azure/GCP Spot 实例对比表

下表基于 2026 年 8 月 us-east 区域的公开定价与技术文档整理，覆盖了 Spot 选型时最常被问的六个维度。价格折扣使用同等 vCPU/内存规格的通用型实例（m6i.large / D4s v5 / n2-standard-2）做基准。

维度	AWS EC2 Spot	Azure Spot VMs	GCP Spot VMs
典型折扣（相对按需）	70–90%	60–90%	60–91%
中断通知窗口	2 分钟（EventBridge/元数据）	30 秒（Scheduled Events）	30 秒（ACPI G2 + 元数据）
最长运行时长	无（受容量池波动影响）	无	无（2022 年后取消 24h 上限）
竞价 / 定价机制	基于容量池的实时市场价，上限=按需价	可设 max price，或 -1 代表容量优先	固定 Spot 价（每月调整），无竞价
Kubernetes 集成	Karpenter / EKS Managed Node Groups	AKS Spot Node Pool / Cluster Autoscaler	GKE Spot Node Pool / Autopilot Spot Pods
Fleet / 多池分散	EC2 Fleet + Spot Fleet + capacity-optimized 分配	Scale Set 多实例大小	MIG（Managed Instance Group）+ 多机型
计费导出（2026 FOCUS 1.2）	CUR 2.0 支持 EffectiveCost	Cost Management Exports v2	BigQuery Billing Export FOCUS 视图

AWS EC2 Spot 深度解析

AWS EC2 Spot 的核心优势是 2 分钟中断通知窗口，这是三家云中最长的，为优雅关机、检查点保存和请求排空提供了充足时间。中断信号可以从实例元数据服务 IMDSv2 拉取，也可以通过 EventBridge 广播到 Lambda、SQS 或 Systems Manager Automation。AWS 官方推荐使用 capacity-optimized 分配策略：SDK 会自动选择当前容量最充裕的池，把中断率降到平均 5% 以下（AWS 2026 Q1 Spot 建议白皮书数据）。

下面是一段用 EventBridge 监听 Spot 中断并触发排空的实用代码，我在生产 EKS 集群里已经跑了两年，没出过大问题：

# EventBridge 规则：捕获 EC2 Spot 中断警告
aws events put-rule \
  --name spot-interruption-drain \
  --event-pattern '{
    "source": ["aws.ec2"],
    "detail-type": ["EC2 Spot Instance Interruption Warning"]
  }'

# Lambda 处理器：将节点从 EKS 集群优雅排空
import boto3, os
def lambda_handler(event, context):
    instance_id = event['detail']['instance-id']
    ec2 = boto3.client('ec2')
    tag = ec2.describe_tags(Filters=[
        {'Name':'resource-id','Values':[instance_id]},
        {'Name':'key','Values':['k8s-node-name']}
    ])['Tags'][0]['Value']
    # 通过 SSM 调 kubectl cordon + drain
    ssm = boto3.client('ssm')
    ssm.send_command(
        DocumentName='AWS-RunShellScript',
        Targets=[{'Key':'tag:role','Values':['k8s-admin']}],
        Parameters={'commands':[
            f'kubectl cordon {tag}',
            f'kubectl drain {tag} --ignore-daemonsets --delete-emptydir-data --force --grace-period=90'
        ]}
    )

参考 AWS Spot Instance interruption 官方文档了解完整的中断行为矩阵。想直接借用现成脚本，可以看 aws-node-termination-handler 的 GitHub 仓库，它已经把 IMDS 轮询、EventBridge 消费和 Kubernetes 事件都封装好了。

Azure Spot VMs 深度解析

Azure Spot VMs 与 AWS 最大的差异是 驱逐策略（Eviction Policy）分离设计。你可以选择 Deallocate（保留磁盘，可稍后重启，但仍占配额）或 Delete（连同 VM 一起删除，不占配额）。对于 AKS 节点池和 CI/CD 工作负载，我一律选 Delete；否则被驱逐的实例即使停机也会顶用配额，妨碍新节点开机。这个坑我在第一次上线时踩过，凌晨三点被 quota 报警叫醒的滋味不好受。

Azure 的价格模型有两种：设定最大 max price（超过则驱逐），或用 -1 表示按当前 Spot 价格购买、直到容量不足才驱逐。后者在 2026 年几乎总是更划算。Azure Spot 的价格波动比 AWS 平缓得多（Azure 每月调整一次基础 Spot 折扣），几乎不会因价格变动被驱逐，绝大多数驱逐都来自容量回收。

Azure 中断通知只有 30 秒，且通过实例内的 Scheduled Events 元数据端点轮询获取，没有类似 EventBridge 的外部广播机制。这意味着你的应用必须自己起后台协程每隔 1–5 秒轮询一次：

# Python 后台协程：轮询 Azure Scheduled Events
import requests, time, subprocess

METADATA_URL = "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01"
HEADERS = {"Metadata": "true"}

def poll_events():
    while True:
        try:
            r = requests.get(METADATA_URL, headers=HEADERS, timeout=3)
            for evt in r.json().get("Events", []):
                if evt["EventType"] in ("Preempt", "Terminate"):
                    # 立即触发本地 drain 与状态保存
                    subprocess.run(["/opt/app/graceful_shutdown.sh"], check=True)
                    return
        except requests.RequestException:
            pass
        time.sleep(2)

GCP Spot VMs 深度解析

GCP Spot VMs 是三家中定价最简单的：没有竞价、没有 max price，Google 每月发布固定 Spot 折扣（通常60–91%），价格公开在 GCP VM 定价页。这种"固定折扣"模型让预算预测极其简单：你只需要用当月的 Spot 单价乘以预期使用小时数就行，不需要建模竞价峰谷。

2022 年 GCP 把 Preemptible 升级为 Spot 后，取消了 24 小时强制中断上限，这是 Spot VMs 相较原 Preemptible 最大的改进，批处理和训练作业不再需要人为分片。GCP 的中断信号同样是 30 秒窗口，但除了元数据端点，还额外向操作系统发送标准 ACPI G2 软关机信号，因此 systemd 或 Kubernetes kubelet 的 shutdown grace period 会自动被触发，无需自己写轮询协程。这大概是 GCP Spot 对开发者最友好的一点。

GCP MIG（Managed Instance Group）配合 Spot 提供了自动再造能力：一旦实例被抢占，MIG 会自动尝试重新创建，容量可用时立即上线。对于长时间运行的 BigQuery ETL 或 Dataflow 作业，这种"自愈"能力大幅降低了人工介入。

如何处理 Spot 实例中断？

无论哪家云，健壮的 Spot 中断处理都遵循同一模式：监听信号 → 停止接收新请求 → 排空进行中的请求 → 保存状态 → 优雅退出。以下是我为跨云统一封装的 shutdown handler 结构：

# graceful_shutdown.sh —— AWS/Azure/GCP 通用
#!/bin/bash
set -euo pipefail

echo "[$(date -Iseconds)] Spot 中断信号收到，开始优雅关机"

# 1. 从负载均衡摘除（AWS ALB / Azure LB / GCP LB 通用做法）
kubectl cordon "$(hostname)" || true

# 2. 排空 Kubernetes 工作负载，宽限期 90s（AWS）或 25s（Azure/GCP）
GRACE=${GRACE_PERIOD:-25}
kubectl drain "$(hostname)" \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --force \
  --grace-period="$GRACE" \
  --timeout="${GRACE}s"

# 3. 触发状态持久化（写入 S3/Blob/GCS）
if [ -x /opt/app/checkpoint.sh ]; then
  /opt/app/checkpoint.sh
fi

# 4. 通知监控系统
curl -sSf -X POST "$METRICS_ENDPOINT/spot_shutdown" \
  --data "host=$(hostname)&cloud=${CLOUD_PROVIDER}" || true

echo "[$(date -Iseconds)] 优雅关机完成"

关键教训：Azure 与 GCP 只有 30 秒，宽限期不能设置成 60 秒以上，否则 drain 命令会在实例断电时被强杀，Pod 无法完成 preStop 钩子。AWS 因为有 120 秒窗口，可以留出 90 秒给 drain。此外，checkpoint 一定要写到对象存储（S3/Blob/GCS），不要写本地 SSD。Spot 实例的本地盘会随实例一起消失，我第一次做训练任务时就因为这个丢过一次两小时的进度。

Kubernetes 集群如何使用 Spot 节点？

三家云都有各自成熟的 Kubernetes Spot 集成路径，选型取决于你已经在用什么工具链。我在两家客户处的 EKS 集群上跑 Karpenter 已经有 18 个月，明显感觉到它比传统 Cluster Autoscaler 更适合 Spot：Karpenter 会根据 Pod 的资源请求实时选择最合适的实例类型，天然避免了"单一实例类型池耗尽"这种最容易踩的坑。以下是一个 Karpenter NodePool 配置片段，覆盖 12 种通用型实例、只在 Spot 池调度：

# karpenter-nodepool-spot.yaml
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general-spot
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["m6i", "m6a", "m7i", "m7a", "c6i", "c6a"]
        - key: karpenter.k8s.aws/instance-size
          operator: In
          values: ["large", "xlarge", "2xlarge", "4xlarge"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: topology.kubernetes.io/zone
          operator: In
          values: ["us-east-1a", "us-east-1b", "us-east-1c"]
      taints:
        - key: spot
          value: "true"
          effect: NoSchedule
      terminationGracePeriodSeconds: 90
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 60s

Azure AKS 的 Spot Node Pool 与 GCP GKE 的 Spot Node Pool 都遵循类似模式：单独一个节点池、加上 kubernetes.azure.com/scalesetpriority=spot 或 cloud.google.com/gke-spot=true 的 taint，让业务 Pod 通过 toleration 显式声明可以调度到 Spot 上。切记不要把整个集群跑在 Spot 上，始终保留至少一个按需节点池承载 kube-system、Ingress Controller、Prometheus 等控制面组件。关于 K8s 节点调优的完整策略，可以参考我们的Kubernetes 成本优化实战指南。

哪些工作负载最适合 Spot 实例？

基于我给多家客户做的 Spot 采纳评估，可以按可中断容忍度把工作负载分成三类：

强烈推荐（预期节省 70–90%）：批处理 ETL、CI/CD Runner、机器学习训练（检查点频繁）、渲染农场、无状态 API 后端、Kubernetes 通用工作负载池、Spark/Dask 分布式计算、A/B 测试影子流量。
谨慎使用（预期节省 30–50%，需混合策略）：有状态但快速冷启动的服务（Redis 缓存节点、Elasticsearch 搜索副本）、面向用户的 Web 前端（配合 ALB 自动摘除）、开发/测试环境（IDE 后端、临时数据库）。
不推荐使用：主生产数据库（PostgreSQL primary、MongoDB replica set primary）、有状态 WebSocket 长连接、单点服务、监控/告警控制面、支付/结算等强一致场景。

对于生成式 AI 训练工作负载，GPU Spot 是巨大的省钱杠杆，三家云 GPU Spot 折扣通常在 60–80%，但要注意 A100/H100 类高端 GPU 的容量池非常拥挤，中断率明显高于通用型 CPU。相关实践可以参考生成式 AI 与 LLM 云成本优化实战指南中的 GPU Spot 章节。

多云 Spot 混合策略与 FOCUS 归因

如果你像我一样服务多云客户，跨 AWS/Azure/GCP 混合 Spot 有两种典型模式：按区域分工（用最便宜或容量最充裕的云跑该工作负载）和 按容量池分散（同一批任务跨云打散，规避单云容量抖动）。第一种适合稳定的批处理管线，第二种适合大规模 ML 训练。

下面是一段跨云 FOCUS 数据聚合的 SQL 示例，我在 BigQuery 里用它给客户生成月度多云 Spot 节省报告：

-- 跨云 Spot 节省汇总（FOCUS 1.2 视图）
SELECT
  BillingPeriodStart AS month,
  ProviderName        AS cloud,
  ServiceCategory,
  ROUND(SUM(EffectiveCost), 2)                    AS spot_effective_usd,
  ROUND(SUM(ListCost - EffectiveCost), 2)         AS estimated_savings_usd,
  ROUND(1 - SAFE_DIVIDE(SUM(EffectiveCost),
                        SUM(ListCost)), 4) * 100  AS discount_pct
FROM `finops.focus_unified_v1_2`
WHERE PricingCategory = 'Spot'
  AND BillingPeriodStart >= DATE '2026-01-01'
GROUP BY month, cloud, ServiceCategory
ORDER BY month DESC, spot_effective_usd DESC;

常见问题解答

哪个云服务商的 Spot 实例最便宜？

没有绝对最便宜的赢家。2026 年三家云在通用型实例上的 Spot 折扣接近（65–90%）。GCP 通常在 n2/n2d 家族最激进（可达 91%），AWS 在旧代实例（m5/c5）最有价格优势，Azure 在 D 系列有稳定 70% 上下折扣。真实决策要基于你目标区域的当前定价 API 报价，不能只看行销素材。

Spot 实例最长可以运行多长时间？

没有硬性上限。GCP 已于 2022 年取消了 Preemptible 的 24 小时强制中断，AWS 和 Azure 从未设置最长运行时长。实际持续时间取决于该实例类型在你所在区域的容量池是否有按需请求进来。我在 AWS us-east-1 的 m6i.large Spot 上见过连续运行 40 天不中断的案例。

Spot 实例可以运行数据库吗？

不建议把主数据库放到 Spot 上。可以考虑放到 Spot 的场景包括：只读副本（配合自动重建）、缓存节点（Redis/Memcached）、开发环境数据库、以及可从对象存储秒级重建的分析型数据库（如 DuckDB 只读工作节点）。生产 primary 应始终使用按需或 RI 实例。

Spot 中断率一般是多少？

AWS 官方发布的 Spot Placement Score 显示，选用 capacity-optimized 分配策略并多池分散后，中断率通常低于 5%/月。Azure 与 GCP 未公开统一指标，我实测的经验值约 3–8%/月，冷门实例类型或高峰季节可能上升到 15%。使用多实例类型池化是降低中断率最有效的手段。

Spot 实例可以和 Savings Plans/预留实例一起用吗？

可以，且强烈推荐混合使用。Savings Plans 与 RI 折扣先应用于按需部分，Spot 折扣独立生效，两者不会相互抵消。典型健壮架构是：60–80% 使用 Spot 承接弹性容量，20–40% 使用 Compute Savings Plans 兜底基线负载，从而在最大节省和高可用之间取得平衡。