Skip to main content
Optimization

Spot instances

Spot instances are spare cloud capacity sold at a steep discount, up to 90% off on-demand prices on AWS and Azure and up to 91% on Google Cloud, which the provider can reclaim at short notice. They suit work that can stop and restart, such as batch jobs, CI pipelines and stateless services.

In plain English

Think of flying standby. You get a seat for a fraction of the fare when one is spare, but you can be bumped when a full-fare passenger turns up, so you don't fly standby to your own wedding.

Formula and worked example

Spot savings = on-demand cost − Spot cost

On-demand cost
= what the same capacity would cost at on-demand prices
Spot cost
= the Spot price paid, plus the cost of work lost and rerun after interruptions
Worked example. Northwind Labs' Data team moves its nightly batch jobs from on-demand instances to Spot in March. The jobs checkpoint their progress, so an interruption only loses the work since the last checkpoint.
The batch fleet at on-demand prices$8,000
The same capacity at an illustrative 70% Spot discount$2,400
Work rerun after interruptions, at Spot prices$200
Spot cost$2,600
Spot savings for the month$5,400

Spot cuts the batch bill by two thirds, even after reruns. The same move would be a mistake for the Checkout API or the main database, which can't stop at short notice.

Why Spot instances matter

For work that can tolerate interruption, Spot is the deepest discount the clouds offer, and it needs no commitment: you pay the Spot price for the time you run. On AWS, EC2 sets Spot prices, which adjust gradually with long-term supply and demand rather than by auction.

The trade-off is the interruption. AWS gives a two-minute warning and Azure 30 seconds, and Google Cloud gives Spot VMs up to 30 seconds to shut down, so workloads need to checkpoint, retry or spread across many instance types to run well on Spot.

Common mistakes

  • Running critical or stateful work on Spot. Databases, single-instance services and anything users wait on need capacity that stays. Use Spot for work that can be retried.
  • Asking for a single instance type. Spot capacity varies by type and zone. Allowing many instance types and zones, through EC2 Auto Scaling groups, EC2 Fleet or Azure scale sets, makes interruptions rarer and capacity easier to get.
  • Committing before moving to Spot. A commitment sized for capacity you then move to Spot goes unused. Move fault-tolerant work to Spot first, then size commitments for the steady usage that's left.
  • Ignoring the early warning. AWS can send a rebalance recommendation before the two-minute notice when a Spot Instance is at higher risk. Handle it, and the notice, to drain work cleanly.

Where to find it in AWS, Azure and Google Cloud

Where to find Spot instances by cloud provider
AWSSpot InstancesUp to 90% off on-demand prices, with a two-minute interruption notice and an earlier rebalance recommendation. Spot prices are set by EC2 and adjust gradually with long-term supply and demand.
AzureAzure Spot Virtual MachinesUp to 90% off pay-as-you-go prices, with 30 seconds' notice through Scheduled Events and no SLA. Choose whether an evicted VM is deallocated or deleted, and set a maximum price, or -1 to be evicted only when capacity runs out.
Google CloudSpot VMsUp to 91% off on-demand prices, with no maximum runtime; the older preemptible VMs stop after 24 hours. Compute Engine can preempt Spot VMs at any time, and flexible committed use discounts cannot cover them.

How CloudYali helps

CloudYali's Azure and Google Cloud savings checks flag on-demand VMs that could run on Spot, priced at the difference to Spot pricing, and its EC2 by Purchase Option cost view shows how much AWS compute already runs on Spot.

  • Billing & cost types

    On-demand price

    On-demand price is the public, pay-as-you-go price for cloud usage with no commitment: you pay per second, hour, gigabyte or request for what you use. It is the baseline that every commitment discount, and metrics such as coverage and effective savings rate, are measured against.

  • Commitments & rates

    Savings Plan (SP)

    A Savings Plan is an AWS or Azure commitment to spend a fixed amount per hour on eligible compute for one or three years. Usage up to that amount is billed at lower rates, and the discount follows your usage across instance sizes and, with the most flexible plans, instance families and regions.

  • Commitments & rates

    Committed use discount (CUD)

    A committed use discount (CUD) is Google Cloud's commitment discount: you commit to a set amount of resources, such as vCPUs and memory in one region, or to an hourly spend, for one or three years, and pay lower prices on that usage. The commitment is billed every month of the term, used or not.

  • Optimization

    Rightsizing

    Rightsizing is changing a cloud resource to the smallest size or type that still meets its workload's real needs, based on measured CPU, memory, storage and network use. It's one of the largest usage savings in FinOps, and it should come before buying commitments, so you don't commit to capacity you don't need.

  • Optimization

    Cloud waste

    Cloud waste is cloud spend that buys nothing the business needs: idle resources, over-provisioned resources and commitments paid for but not used. It's measured in money rather than resources, and removing it lowers the bill without changing what users get, which is why cost optimization usually starts there.

Frequently asked questions

  • What is the difference between Spot VMs and preemptible VMs?

    On Google Cloud, Spot VMs are the newer version of preemptible VMs. Both are discounted and can be preempted, but preemptible VMs stop after 24 hours, while Spot VMs have no maximum runtime.

  • How much notice do I get before a Spot interruption?

    Two minutes on AWS and 30 seconds on Azure; Google Cloud gives Spot VMs up to 30 seconds to shut down. Design the workload to checkpoint or retry rather than relying on the notice.

  • What workloads suit Spot?

    Fault-tolerant, flexible work: batch and data processing, CI/CD, rendering, containers and stateless web servers. Avoid it for databases and anything that can't be interrupted.

Sources

Ready to optimize your cloud costs?

Start your free trial today and see how CloudYali can help you save.