Clusters paying on-demand VM rates for workers that could ride spot capacity

Spot discounts one meter, not both

The Databricks bill has a VM layer and a DBU layer, and spot capacity only touches the first. A worker on a spot VM pays the discounted infrastructure rate but the identical DBU rate, so any savings claim computed against the whole cluster cost overstates reality. ZopNight prices this lever against the VM layer only, and further scales it by the worker share, because the driver node should never ride spot: losing the driver kills the cluster, while losing a worker merely re-runs tasks.

Reading availability across three clouds

The discoverer stores the raw SDK enum, which is cloud-suffixed (ON_DEMAND on AWS, ON_DEMAND_AZURE, ON_DEMAND_GCP), so matching is by prefix, and spot variants including spot-with-fallback are skipped as already converted. Worker count comes from num_workers, falling back to the autoscale maximum when the fixed count is 0, so an autoscaling on-demand cluster with real spot-eligible workers still fires. Stopped clusters and system-managed clusters (job, pipeline, SQL, serving) are out of scope.

A derived discount or none at all

The savings figure is worker share (workers divided by workers plus 1) times the cluster’s priced monthly VM cost, times a spot fraction derived from the live on-demand and spot tier rates for the actual instance type. There is deliberately no fallback percentage: an earlier version applied a flat 0.60 when rates were missing, which is fabricated savings, and it was removed. No live rate, no priced cluster, or a non-positive derived delta all end in abstention rather than a guessed number.

Check a cluster’s setting yourself

databricks api get '/api/2.1/clusters/get?cluster_id=0101-123456-abcde12' | jq '
  {aws: .aws_attributes.availability,
   azure: .azure_attributes.availability,
   gcp: .gcp_attributes.availability}'

Interruption is the price of the discount

The recommendation carries an explicit spot mechanism marker precisely so it is never classed as risk-free: spot workers can be reclaimed by the cloud with minutes or seconds of notice. Convert workloads that checkpoint and retry, which covers most Spark batch jobs, using a spot-with-fallback availability so reclaimed workers are replaced with on-demand capacity instead of stalling the job, and keep the driver on-demand without exception.