Cloud spot instances (called Spot Instances on AWS, Spot VMs on Azure, and Preemptible VMs on GCP) offer discounts of 60–90% on on-demand compute pricing by selling spare capacity that the cloud provider would otherwise leave idle. The catch is simple: the provider can reclaim that capacity with as little as 30 seconds' notice. Australian IT teams drawn in by the headline savings often discover that catch only when a workload dies mid-run.
Getting spot instances right isn't about avoiding them. It's about knowing exactly where they fit and where they'll cause more damage than the discount is worth.
How spot instance pricing actually works
Each cloud provider runs a slightly different model. AWS sets a spot price per instance type and availability zone that fluctuates with capacity demand. When that price exceeds your bid (or when AWS simply needs the capacity back), your instance is terminated. Azure and GCP work on similar principles, though GCP's Preemptible VMs use a fixed discount structure rather than a bid-based one, with a hard 24-hour maximum runtime.
The discount varies significantly by instance type and region. Compute-optimised families in Sydney's ap-southeast-2 region often sit at 70–80% off, but popular GPU instance types can shrink to 30–40% off during periods of high demand. Spot savings are real, but they're not uniform across your stack.
Interruption rates also vary. AWS publishes its own interruption frequency data per instance type, and some families run for days or weeks without reclamation while others are pulled back within hours. Choosing the right instance family is as important as choosing the right workload.
Workloads where spot instances genuinely deliver
Batch processing is the canonical spot use case. Jobs that checkpoint their state, can be retried cleanly, and have no fixed completion deadline absorb interruptions without data loss. Machine learning training runs, genome analysis pipelines, video encoding queues, and large-scale data transformation jobs all fit this profile. An interrupted batch job restarts from its last checkpoint. Nobody notices except the billing system.
CI/CD build agents are another strong match. A build runner that dies mid-compile simply triggers a retry. Most modern CI platforms handle this natively, and the cost reduction across a fleet of build agents can be significant. CI/CD pipelines built with retry logic baked in absorb spot interruptions cleanly.
Stateless web tier scale-out is worth considering if your auto-scaling group mixes spot and on-demand instances. AWS's Spot Fleet and Azure's Spot Instance support in virtual machine scale sets both let you define a mix. You keep a baseline of on-demand instances for reliability and layer in spot capacity for burst handling. If a spot node disappears during a traffic spike, the load balancer routes around it.
Dev and test environments are an obvious fit. Engineers don't need their test boxes running overnight. Scheduled spot instances that spin up at 8am and terminate at 7pm cost a fraction of always-on dev infrastructure, and nobody is relying on them for production uptime.
Workloads where spot instances will hurt you
Any stateful workload that can't checkpoint is dangerous on spot. Primary database instances, in-memory session stores, and message queue brokers all carry state that isn't trivially recreated. Losing an RDS read replica to a spot interruption is survivable. Losing a primary Postgres instance mid-write is not.
Long-running interactive user sessions sit in the same category. If a user is actively working in an application and their session terminates because the underlying compute was reclaimed, the interruption is visible and disruptive. This includes anything with open WebSocket connections or streaming output.
Tightly coupled distributed jobs are also a trap. Some workloads split work across a cluster of nodes that must all complete for the result to be valid. If spot interruption hits 20% of your nodes mid-run, you don't just lose those nodes. You potentially invalidate the entire run. MPI jobs and certain distributed computing frameworks fall here. Only use spot for these if your framework explicitly handles partial node failure.
Production web tiers without an on-demand baseline are risky. Running your entire production fleet on spot to save money is the kind of decision that looks sensible in a cost review and catastrophic during a capacity crunch when AWS reclaims nodes across an availability zone simultaneously.
Spot instances and Australian compliance requirements
Data residency obligations add a layer of complexity that many teams overlook when sizing spot capacity. Spot inventory isn't uniformly available across all availability zones in ap-southeast-2. If your compliance requirements mandate that data stays in a specific region and zone, you can't simply fail over to wherever spot capacity exists. This particularly affects teams operating under the Australian data residency requirements that have tightened under recent Privacy Act reform.
Government and regulated workloads typically can't rely on spot for anything sensitive. The interruption model conflicts with availability guarantees most agencies need, and the non-deterministic termination makes audit trails harder to maintain. For those environments, reserved instances or savings plans are a more appropriate cost lever.
Building interruption tolerance: the practical steps
If your workload is a genuine candidate for spot, a few engineering choices determine whether it works in practice.
- Checkpoint aggressively. Write job state to durable storage (S3, Azure Blob, GCS) at frequent intervals. The checkpoint interval determines how much work you lose when a node is reclaimed.
- Handle the termination notice. AWS provides a two-minute warning via instance metadata before reclaiming a spot instance. Your application should poll
http://169.254.169.254/latest/meta-data/spot/termination-timeand trigger a graceful shutdown, including flushing in-memory state and deregistering from load balancers. - Use diversified instance fleets. Request capacity across multiple instance types and availability zones. A Spot Fleet or Auto Scaling group with 5–6 instance families is far more resilient than one targeting a single type, because interruption events are rarely correlated across families.
- Set a sensible fallback. Define what happens when spot capacity isn't available. For batch jobs, the answer is usually "wait." For latency-sensitive workloads, you need on-demand fallback already provisioned.
Mixing spot with other commitment models
Spot instances work best as one layer in a broader cost strategy, not as a standalone approach. Most Australian teams that get real value from spot pair it with a foundation of reserved instances or savings plans covering their stable baseline workload. Cloud reserved instances vs savings plans each carry different flexibility trade-offs, and understanding that distinction matters before you decide what to commit to and what to leave on spot.
A common pattern: reserve 60–70% of your baseline compute at 1-year or 3-year rates, run steady-state on-demand for the remainder, and push burst and batch work onto spot. This structure gives you predictable costs on the baseline while capturing spot savings on the elastic portion where interruption tolerance is highest.
What the actual savings look like in practice
The headline 90% discount is real but rare. For workloads that genuinely fit the spot model, 60–75% savings over equivalent on-demand pricing is a realistic expectation in Australian regions. An ML training job that previously cost $400 on on-demand c5.18xlarge instances can run for $80–120 on spot, with the right checkpointing in place. That's meaningful budget recovery, particularly for teams running frequent training cycles.
Where teams lose those savings is in over-engineering the interruption handling. If your team spends three weeks building a sophisticated retry and state management layer for a batch job that runs weekly, the engineering cost likely exceeds the savings for the first year. Evaluate the complexity cost honestly before committing.
Spot instances are a genuine tool. The Australian teams that use them well have spent time understanding exactly what their workload needs when the compute disappears. The ones that get burned treat the discount as a reason to skip that analysis.