(If you would prefer to listen to this article, click this link to hear it using Amazon Polly. It will also be available in iTunes: search for LabR Learning Resources.)
AWS Elastic Compute Cloud or EC2, comes in different instance families and instance sizes to meet your specific workload requirements. But there are also different billing or service delivery types including on-demand, reserved instance and spot instance.
On-demand instances are likely the most commonly used, as you can create and terminate them whenever you need them. Of the three billing types, on-demand instances are the most expensive. Reserved instances are a billing construct, where you pay a lower amount than the on-demand price by committing to the instance family and size for a one or three year period. the reserved instance price is also decreased by paying some amount up front for the duration of your agreement.
This article focuses on spot instances including what they are, why use them, and the benefits. We are also going to briefly look at several spot instance management approaches.
What are Spot Instances?
Spot instances allow you to take advantage of the spare capacity in the AWS cloud. It is to AWS’s advantage to have as much of their infrastructure working and generating revenue. Spot instances are offered at steep discounts when compared with on-demand instances, allowing you to lower your operating costs.
Why should an organization use Spot Instances?
The biggest reason for using spot instances is cost. AWS claims you can see costs up to 90% less than an on-demand instance. When you request a spot instance, the cost is determined by the spot instance system at the time you request it. The price is based upon trends for specific instance families and size, and can change every 5 minutes. Costs can be different for the same instance type between regions.
For example, here is the spot price for January 14, 2019 in the North Virginia region.
And here is the spot prices for the Ohio region.
In this view, the frequency of interruption is also shown, indicating how often the spot instance is recovered, interrupting the workload. As of January 14, 2019, the average interruption frequency was less than 5%.
What are good workloads for Spot Instances?
Because a spot instance can be terminated — that is “recovered” by AWS with only a two minute warning, workloads must be fault-tolerant and able to adapt to the changes in the spot environment. One approach would be use spot instances when they are available, and on-demand when spot instances are not.
The AWS Spot Instances Overview specifically identifies good workload candidates as “fault-tolerant and flexible applications including big-data, containerized workloads, high performance computing, stateless web servers, rendering, CI/CD, test and development workloads”.
When your application is going to lose their spot instance, you can now choose how to handle the loss of that instance. You can hibernate the workload, allowing to recover when a new spot instance is created for it, or terminate the workload. In the former, the workload can continue where it left off, while the latter requires the workload to start over.
How can I manage my Spot Instances?
This article is about spot instances, but we should briefly mention the major spot instance management tools. AWS provides Spot Fleet, and there are third party spot instances management solutions available including Spotinst and XOsphere.
AWS provides the Spot Fleet service to manage your spot instances. Spot Fleet is great for applications that don’t have high availability requirements (think batch processing, machine learning, video transcoding, etc.). The focus on non-high availability applications exists because Spot Fleet will never launch an on-demand instance to replace a reclaimed spot instance.
If you follow AWS best practices, the best you will achieve with SpotFleet is roughly 95% availability. In some cases, this may be sufficient, but for many applications, this availability is not sufficient.
Spotinst, is an Israeli company which uses a price prediction algorithm to manage your spot instances. However, for Spotinst to operate, you must delegate an IAM role to grant control over your account. For some organizations, this will be a challenge to accept.
Spotinst is cloud specific — there is a different option for the ElasticGroup product, depending upon your cloud provider.
With Spotinst you are required to make changes like swapping out providers in your infrastructure-as-code scripts (moving from an AWS provider to a Spotinst provider). using the AWS API also requires changes to implement the Spotinst APIs or the Spotinst CLI. All these changes add up, especially when looking at hundreds or thousands of applications and result in a very long deployment process.
Finally, Spotinst requires you use their console to manage configuration changes, meaning you are working in both the AWS and Spotinst consoles throughout the day.
Xosphere is completely agnostic to how you manage your environment and requires no changes to your applications, code, infrastructure-as-code (CloudFormation, Terraform, etc.), configuration management (Puppet, Chef, etc.), CI/CD, deployment process or tooling, etc. However you manage your environment today, is how you manage it after implementing Xosphere.
Because there are no changes to your infrastructure and application management, implementation is simple. Xosphere is implemented using AWS tags, and augmenting AWS services like Autoscaling Groups, simplifying the effort to incorporate Xosphere and spot instances into your workloads.
Additionally, the Xosphere product will create on-demand instances should spot not be available, allowing your application to remain operational. This means Xosphere is a good option for bringing spot instances into a highly available application.
Spot instances make use of spare capacity in the AWS cloud, and allows you to run your workloads at considerable savings over on-demand instances. The application must be fault-tolerant and flexible to handle an interruption in compute availability, meaning not every workload is a candidate for spot instances.
There are AWS and third party spot instance management tools to assist you in the deployment and management of your spot instances, although each organization will need to carefully determine which management tool is most appropriate for their specific case.
When you have reached the conclusion that spot instances are right for some of your organization’s workloads, the Spot Instances Getting Started Guide explains what you need to do to create your spot instances.
 Amazon EC2 Spot
Copyright 2019, Chris Hare