IBM Cloud Docs
Spot instances (Select availability)

Spot instances (Select availability)

Select availability

Spot instances are available for select customers. Contact IBM support if you're interested in getting access.

Spot instances are highly discounted versions of the standard instances. They are designed to use available compute resources for interruptible or stateless workloads. Spot instances can be preempted (or evicted) at any time.

With Spot instances, you can choose the best compatible profile that fits your workload characteristics, performance needs, and price point. Spot instances are ideal for fault-tolerant, interruptible workloads because IBM Cloud VPC preempts these instances based on resource demand.

Spot instances are ideal for, but not limited to, the following workloads.

  • Development test servers
  • Data analytics
  • Image rendering
  • Containerization
  • Batch processing

Spot instance benefits

Spot instances have the following benefits.

  • Cost-efficient
  • Scalable - you can add or remove Spot instances through Auto scale for VPC]
  • Spot instances don't use the standard instance quota. Spot instances have their own quotas (the default is 100).
  • No minimum or maximum runtime
  • Resizable (instance must be stopped to resize)

Spot instance limitations

Spot instances aren't compatible with the following features.

  • Burstable instances
  • Dedicated hosts
  • Reservations

Spot instances details

  • Spot instances support only GPU profiles and Flex profiles.
  • Auto Scale and instance groups support Spot instances.
  • Placement groups are supported, but keep in mind that using placement groups can cause capacity errors.

Spot instances aren't guaranteed available capacity. If capacity isn't available, you can try another zone or region or try again later.

Instance profiles have a property that is called availability_class that is either "standard", "spot", or both. If "spot" is in the array of values, you can use the profile to create a spot instance.

When you create an instance, you need to set a couple of new fields:

  • availability.class needs to be "spot"
  • availability_policy.preemption can be "stop" or "delete" (the default is "stop")

See the following example of the properties in an API request.

{
   "availability": {
       "class": "spot"
   },
   "availability_policy": {
       "preemption": "delete"
   },
   ...
}

Preemption

Preemption of a Spot instance is when the platform determines it is necessary to evict the spot instance. At the start of preemption, the preemption policy is applied and a best-effort preemption grace period of 30 seconds begins. At the end of this grace period, the spot instance is forcefully shut down.

The preemption policy determines the behavior of the Spot instance when the instance is preempted. The availability_policy.preemption property when added to supported instances has a value of "stop" or "delete".

  • "stop" - the instance goes into the stopped state when the preemption completes. You can start the instance again or delete it.
  • "delete" - the instance is deleted when after preemption.

Changes that are made to the preemption policy during a preemption aren't applied until the next preemption.

You are notified of a preemption in two ways.

  • A graceful shutdown command is issued within the operating system of the Spot instance. This shutdown command can be programmatically responded to within the guest.
  • When a spot instance is selected for preemption, a user-facing log is sent at the beginning of the preemption process. Example: "instance.00002": "Spot instance {{.instanceID}} is selected for preemption". After 30 seconds and if the spot instance is not yet stopped, a forced shutdown is issued within the guest. For more information about logging, see Logging for VPC.

Spot instances that are deleted due to scaling down with an instance group aren't considered preempted so the preemption policy is ignored.

Re-creating a spot instance by using an instance group

When a spot instance is preempted, if it's a member of an instance group, then the instance group attempts to create a spot instance to replace the preempted spot instance. The new spot instance is created and attached to one of the subnets that are specified in the instance group subnet array.

If you want to automatically re-create a spot instance after preemption, you can use an instance group to re-create these spot instances.

  1. Create an instance template that fits your needs with instance availability.class to spot and the availability_policy.preemption to delete.

  2. Create an instance group with the instance template that you created.

    To increase the likelihood of finding capacity for your spot instance (if capacity is constrained in one zone), specify multiple subnets that are spread across zones in the region for high-availability. { :tip}

To keep your preempted instances in a stopped state, then you need to specify stop for the availability_policy.preemption_ configuration. After the spot instance is created by the instance group, you need to submit a PATCH /instance_groups/{instance_group_id}/memberships/{id} and specify falsefor the delete_instance_on_membership_delete property.