Spot VMs

Name: Spot VMs
Brand: Google
Rating: 4.5 (2680 reviews)

Spot VMs are Google Compute Engine instances that run on excess cloud capacity at discounted rates and can be preempted at short notice, designed to run fault-tolerant and interruption-tolerant workloads while reducing compute spend.

Est 1998|Valuation $4081.3B|Raised $26.1M

LinkedIn 41.9M|Website|Web traffic 3.3M|FTEs 198,933|HQ Mountain View, California, US

MarketsCloud Infrastructure Providers (IaaS/PaaS)Cloud Cost Management

Published Oct 12, 2026

01Common complaints

Workloads requiring strong uptime guarantees
- Spot VMs are excluded from the Compute Engine SLA and are therefore inappropriate when VM-level uptime guarantees are required.
Stateful services without robust failover
- Databases, message brokers, and stateful storage systems that cannot tolerate abrupt stops or deletes.
Processes that cannot safely terminate within approximately 30 seconds
- Workloads that require minutes to flush state, drain connections, or checkpoint will face elevated risk of data loss or incomplete work.
GPU-constrained production ML training with fixed deadlines
- Community reports suggest GPU spot capacity can be limited; frequent interruptions and lack of immediate replacement capacity can jeopardize deadlines.
Teams with limited DevOps/SRE bandwidth
- Operational complexity may offset cost savings; fixed-price or reserved models (committed use discounts, reservations) may be more cost-effective for teams without platform maturity.
Environments with strict residency constraints and limited regions
- If workloads cannot move regions or zones, it may be difficult to leverage alternative spot pools or better pricing.
No SLA coverage
- Spot VMs are excluded from the Compute Engine SLA.
Preemption notice is short
- The preemption notice is best-effort and up to 30 seconds.
Limited visibility into specific preemption causes
- Documentation indicates limited visibility into the root cause of some preemption events.
Availability constraints
- Spot capacity is finite; some instance shapes (notably GPUs) may be unavailable or reclaimed frequently.
Pricing and policy changes
- Vendor communications and community discussion reference changes in price-update frequency and discount levels; procurement teams should confirm current policies and monitor announcements.
Premium image licensing
- Spot discounts do not reduce premium image licensing costs; billing behavior for premium images remains unchanged when Spot VMs are used.

- Workloads requiring strong uptime guarantees - Spot VMs are excluded from the Compute Engine SLA and are therefore inappropriate when VM-level uptime guarantees are required. - Stateful services without robust failover - Databases, message brokers, and stateful storage systems that cannot tolerate abrupt stops or deletes. - Processes that cannot safely terminate within approximately 30 seconds - Workloads that require minutes to flush state, drain connections, or checkpoint will face elevated risk of data loss or incomplete work. - GPU-constrained production ML training with fixed deadlines - Community reports suggest GPU spot capacity can be limited; frequent interruptions and lack of immediate replacement capacity can jeopardize deadlines. - Teams with limited DevOps/SRE bandwidth - Operational complexity may offset cost savings; fixed-price or reserved models (committed use discounts, reservations) may be more cost-effective for teams without platform maturity. - Environments with strict residency constraints and limited regions - If workloads cannot move regions or zones, it may be difficult to leverage alternative spot pools or better pricing. - No SLA coverage - Spot VMs are excluded from the Compute Engine SLA. - Preemption notice is short - The preemption notice is best-effort and up to 30 seconds. - Limited visibility into specific preemption causes - Documentation indicates limited visibility into the root cause of some preemption events. - Availability constraints - Spot capacity is finite; some instance shapes (notably GPUs) may be unavailable or reclaimed frequently. - Pricing and policy changes - Vendor communications and community discussion reference changes in price-update frequency and discount levels; procurement teams should confirm current policies and monitor announcements. - Premium image licensing - Spot discounts do not reduce premium image licensing costs; billing behavior for premium images remains unchanged when Spot VMs are used.

02Why they buy

Vendor-reported differentiators (described in vendor materials)
- Reported headline discount range
  - Vendor materials cite discounts up to 91% for certain machine types and attached resources when capacity is available.
- Integration with Google Cloud services
  - Spot VMs are integrated with GCP services such as GKE, Batch, Dataproc, and Dataflow, enabling use within existing GCP tooling and orchestration.
- Operational model
  - Vendor materials describe Spot VMs as running indefinitely until capacity is reclaimed rather than having a fixed maximum lifetime.
Competitor advantages
- Interruption notice time
  - AWS provides a longer documented interruption notice in many cases (commonly cited as 2 minutes) compared with Google’s up-to-30-second notice.
- Forecasting simplicity
  - Some competitors provide more predictable or consistent discount mechanics that simplify budgeting and modeling for certain customers.

- Vendor-reported differentiators (described in vendor materials) - Reported headline discount range - Vendor materials cite discounts up to 91% for certain machine types and attached resources when capacity is available. - Integration with Google Cloud services - Spot VMs are integrated with GCP services such as GKE, Batch, Dataproc, and Dataflow, enabling use within existing GCP tooling and orchestration. - Operational model - Vendor materials describe Spot VMs as running indefinitely until capacity is reclaimed rather than having a fixed maximum lifetime. - Competitor advantages - Interruption notice time - AWS provides a longer documented interruption notice in many cases (commonly cited as 2 minutes) compared with Google’s up-to-30-second notice. - Forecasting simplicity - Some competitors provide more predictable or consistent discount mechanics that simplify budgeting and modeling for certain customers.

Why customers chose Spot VMs (common themes)

Cost savings for spiky or bursty compute
Access to discounted capacity without long-term commitments
Integration with GKE and batch-style services (as described in vendor materials)

03Field reports

Availability of Spot VMs reviews on major platforms

Review platforms (G2, TrustRadius, Gartner Peer Insights) generally cover Google Compute Engine or Google Cloud broadly rather than the Spot VMs provisioning model specifically. Evidence for Spot VMs tends to come from community discussions and vendor-published case studies.

Review platforms (Compute Engine / GCP broadly)

G2 — Google Compute Engine (broad IaaS VM product)
- Aggregate signals
  - G2 shows a high overall rating for Google Compute Engine and highlights scalability and flexibility; some summaries note pricing complexity and potential for unexpected costs.
- Example user quote (from a G2 review)
  - "I really like how I can start a Google Compute Engine instance by clicking on the SSH button…" (verified-user excerpt).
- Example criticism themes (G2 summary)
  - "Pricing structure can be complex and may lead to unexpected costs if not monitored closely." (platform summary of user feedback)
TrustRadius
- A limited set of Spot-VM-specific reviews was not readily discoverable in accessible sources for this research.
Gartner Peer Insights
- Gartner Peer Insights is organized around software/service markets; Spot VMs are a consumption model within Compute Engine rather than a standalone product listing.

- G2 — Google Compute Engine (broad IaaS VM product) - Aggregate signals - G2 shows a high overall rating for Google Compute Engine and highlights scalability and flexibility; some summaries note pricing complexity and potential for unexpected costs. - Example user quote (from a G2 review) - "I really like how I can start a Google Compute Engine instance by clicking on the SSH button…" (verified-user excerpt). - Example criticism themes (G2 summary) - "Pricing structure can be complex and may lead to unexpected costs if not monitored closely." (platform summary of user feedback) - TrustRadius - A limited set of Spot-VM-specific reviews was not readily discoverable in accessible sources for this research. - Gartner Peer Insights - Gartner Peer Insights is organized around software/service markets; Spot VMs are a consumption model within Compute Engine rather than a standalone product listing.

Community discussions (Spot VMs specifically)

Price tracking and volatility concerns
- Community threads ask for easier ways to find lower spot pricing and reference Google’s pricing pages and APIs. Some reports indicate spot pricing can appear static when retrieved via billing APIs.
Reliability/availability frustrations
- Community discussions note that spot resources are finite and that large organizations with priority capacity can reduce availability for spot users.
GPU spot capacity challenges
- Some users report that GPU spot capacity can be difficult to obtain consistently, suggesting capacity scarcity and/or frequent interruptions.

- Price tracking and volatility concerns - Community threads ask for easier ways to find lower spot pricing and reference Google’s pricing pages and APIs. Some reports indicate spot pricing can appear static when retrieved via billing APIs. - Reliability/availability frustrations - Community discussions note that spot resources are finite and that large organizations with priority capacity can reduce availability for spot users. - GPU spot capacity challenges - Some users report that GPU spot capacity can be difficult to obtain consistently, suggesting capacity scarcity and/or frequent interruptions.

Why some customers avoid or leave (common themes)

Very short interruption notice can be problematic for workloads that cannot checkpoint or terminate safely in that window.
Capacity and availability unpredictability, particularly for GPU instances.
Policy or pricing changes over time can affect expectations about discounts and pricing update frequency.

Case Studies

Google Cloud blog case mention (vendor-published)
- A Google cost-management blog includes a vendor-published case that quotes a customer describing discounts and pricing predictability.
- Critical evaluation
  - This is vendor-published marketing content. The quoted language supports perceived value (discounts and pricing behavior) but does not provide independently verified metrics (for example, measured savings, interruption rates, or time-to-complete).
  - Readers should interpret vendor-published case study language with caution and validate claims against independent measurements where possible.
Spot.io case study (third-party vendor)
- A Spot.io case study describes customers using preemptible/spot capacity with orchestration.
- Critical evaluation
  - Spot.io’s business model aligns with promoting spot usage; claims about disruption mitigation depend on workload architecture and the availability of replacement capacity.

- Google Cloud blog case mention (vendor-published) - A Google cost-management blog includes a vendor-published case that quotes a customer describing discounts and pricing predictability. - Critical evaluation - This is vendor-published marketing content. The quoted language supports perceived value (discounts and pricing behavior) but does not provide independently verified metrics (for example, measured savings, interruption rates, or time-to-complete). - Readers should interpret vendor-published case study language with caution and validate claims against independent measurements where possible. - Spot.io case study (third-party vendor) - A Spot.io case study describes customers using preemptible/spot capacity with orchestration. - Critical evaluation - Spot.io’s business model aligns with promoting spot usage; claims about disruption mitigation depend on workload architecture and the availability of replacement capacity.

04Best fit

Company sizes
- Typical adopters
  - Mid-market to enterprise organizations with mature platform engineering or SRE practices
  - Startups with experienced cloud engineering teams that can trade engineering effort for compute savings
- Indicative ranges (not vendor-stated)
  - Organizations ranging from smaller teams to large enterprises depending on workload scale
  - Engineering teams able to implement retries, checkpointing, and orchestration
Industries and verticals
- Common fits based on typical spot use cases
  - Media rendering and transcoding
  - Life sciences and genomics pipelines
  - Quantitative and financial modeling and simulation
  - Adtech and analytics batch processing
  - ML training and large-scale experimentation (with checkpointing)
Roles and personas
- Decision makers
  - Head of Infrastructure / VP Engineering
  - FinOps lead or cloud cost owner
  - Platform engineering leadership
- End users
  - Data engineering teams
  - ML engineering and research teams
  - DevOps and SRE teams running batch platforms
Pain points addressed
- Lower compute cost for bursty workloads
- Elastic scale without long-term commitments
- Running parallel, retryable jobs at lower cost
Qualification criteria (good fit)
- Workloads are interruptible and can checkpoint quickly
- Architecture supports multi-zone and instance-type diversification
- Robust automation (managed instance groups, autoscalers, job queues) exists
Disqualifiers (poor fit)
- Hard uptime requirements or strict VM-level SLAs
- Stateful workloads without adequate replication or failover
- Long-running jobs with high restart costs and inadequate checkpointing
- Teams lacking platform engineering capacity to manage intermittent capacity loss

- Company sizes - Typical adopters - Mid-market to enterprise organizations with mature platform engineering or SRE practices - Startups with experienced cloud engineering teams that can trade engineering effort for compute savings - Indicative ranges (not vendor-stated) - Organizations ranging from smaller teams to large enterprises depending on workload scale - Engineering teams able to implement retries, checkpointing, and orchestration - Industries and verticals - Common fits based on typical spot use cases - Media rendering and transcoding - Life sciences and genomics pipelines - Quantitative and financial modeling and simulation - Adtech and analytics batch processing - ML training and large-scale experimentation (with checkpointing) - Roles and personas - Decision makers - Head of Infrastructure / VP Engineering - FinOps lead or cloud cost owner - Platform engineering leadership - End users - Data engineering teams - ML engineering and research teams - DevOps and SRE teams running batch platforms - Pain points addressed - Lower compute cost for bursty workloads - Elastic scale without long-term commitments - Running parallel, retryable jobs at lower cost - Qualification criteria (good fit) - Workloads are interruptible and can checkpoint quickly - Architecture supports multi-zone and instance-type diversification - Robust automation (managed instance groups, autoscalers, job queues) exists - Disqualifiers (poor fit) - Hard uptime requirements or strict VM-level SLAs - Stateful workloads without adequate replication or failover - Long-running jobs with high restart costs and inadequate checkpointing - Teams lacking platform engineering capacity to manage intermittent capacity loss

05The pitch

What the product does (core value proposition in objective terms)

Spot VMs are Google Compute Engine VM instances that run on excess Google Cloud capacity at discounted rates compared with standard (on-demand) VMs, with the tradeoff that Google can preempt (stop or delete) them at any time. Spot VMs are intended for fault-tolerant and interruption-tolerant workloads.
Preemption handling
- Compute Engine sends a best-effort preemption notice with a short shutdown window; after that, the VM is stopped or deleted depending on the configured termination action.
- Spot VMs are not covered by a Service Level Agreement (SLA) and are excluded from the Compute Engine SLA.
Pricing positioning
- Vendor-reported substantial discounts are cited for many machine types and certain accelerators/resources; pricing varies by machine type and region.

- Spot VMs are Google Compute Engine VM instances that run on excess Google Cloud capacity at discounted rates compared with standard (on-demand) VMs, with the tradeoff that Google can preempt (stop or delete) them at any time. Spot VMs are intended for fault-tolerant and interruption-tolerant workloads. - Preemption handling - Compute Engine sends a best-effort preemption notice with a short shutdown window; after that, the VM is stopped or deleted depending on the configured termination action. - Spot VMs are not covered by a Service Level Agreement (SLA) and are excluded from the Compute Engine SLA. - Pricing positioning - Vendor-reported substantial discounts are cited for many machine types and certain accelerators/resources; pricing varies by machine type and region.

Target market and market positioning

Recommended use cases
- Batch workloads (ETL, rendering, simulations)
- High-performance computing (HPC) and distributed compute that can checkpoint and retry
- Stateless services and horizontally scaled microservices
- Some machine learning training/inference pipelines when designed for interruptions (checkpointing, retries, multi-region capacity strategies)
Less suitable for
- Stateful systems without robust replication
- Latency-sensitive services without rapid failover
- Workloads that cannot checkpoint within a short interruption window
Market context
- Spot VMs compete with AWS EC2 Spot Instances, Azure Spot Virtual Machines, Oracle Cloud Preemptible Instances, and platform-level orchestrators (for example, managed batch services and Kubernetes autoscaling patterns) that facilitate interruption-tolerant compute.

- Recommended use cases - Batch workloads (ETL, rendering, simulations) - High-performance computing (HPC) and distributed compute that can checkpoint and retry - Stateless services and horizontally scaled microservices - Some machine learning training/inference pipelines when designed for interruptions (checkpointing, retries, multi-region capacity strategies) - Less suitable for - Stateful systems without robust replication - Latency-sensitive services without rapid failover - Workloads that cannot checkpoint within a short interruption window - Market context - Spot VMs compete with AWS EC2 Spot Instances, Azure Spot Virtual Machines, Oracle Cloud Preemptible Instances, and platform-level orchestrators (for example, managed batch services and Kubernetes autoscaling patterns) that facilitate interruption-tolerant compute.

Get a comprehensive analysis of Spot VMs including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →