AWS EC2 spot instances can be rather overlooked in preference to reserved instances. While it’s true that reserved instances are often the core of AWS EC2 cost optimization, spot instances can offer even bigger discounts. This means that it typically makes sense at least to look at the possibilities they offer.
AWS EC2 reserved instances versus spot instances
As a quick refresher, AWS EC2 reserved instances, as their name suggests, are bundles of instances which are sold at a discounted price compared to on-demand usage. The size of the discount depends on various factors including the length of the commitment, whether or not you pay upfront and the degree of flexibility to make changes. At present, the maximum saving is 75%.
AWS EC2 spot instances by contrast are what AWS uses to monetize spare capacity. As such their availability is unpredictable and they can be canceled with two minutes of notice. Basically interruptions happen when demand goes up and AWS can get more money from another user for the instance capacity. On the plus side, however, spot instances can offer savings of up to 90% as compared to on-demand usage.
For the sake of completeness, your spot instance usage is entirely separate from your reserved instance usage. In other words, you’re billed for one or the other, not both at the same time. If you’re using reserved instances and spot instances for the same instance type, your reserved instance will apply unless the conditions for your spot instance are met and then you will switch over. If your spot instance is interrupted, you will switch back to your reserved instance.
Submitting a spot instance request
The process for submitting a spot-instance request is fairly similar to the process for submitting a reserved-instance request. There are, however, a few differences, which reflect the different nature of the service. In particular, you have to specify the maximum price you are willing to pay per instance-hour and whether the request is one-time or persistent. If the latter you also need to specify the period for which the request is valid.
Pro tip, AWS provides a 30-day history of spot prices. This can give you a very good idea of what kinds of discounts you can realistically achieve.
The spot-request lifecycle
Once you have placed your spot request, it will be fulfilled when capacity becomes available at or below the maximum price you have specified. It will continue to be available until either the price is raised so that it goes above your budget or AWS runs out of capacity.
At that point, one-time spot instances will be canceled, but persistent spot instances will be resubmitted and will be reactivated as and when (and if) the necessary criteria are met again.
The significance of region
As with just about everything AWS, there are regional differences in the availability and hence pricing and stability of spot instances. In some regions there is often quite a bit of spare capacity and therefore spot instances are often made available at very low prices and can run for extended periods without interruption. In other regions, spot instances tend to be fewer, further between and more liable to interruption.
AWS provides statistics on interruptions for each spot instance type, instance size, region and operating system. These can be a handy reference when managing your spot usage.
Spot instances and stability
Obviously, you are probably never going to use spot instances for a mission-critical application, which has to be kept running at all times. You can, however, use them for applications that benefit from a high degree of stability. You just need to create your architecture so that it can withstand failure. In principle, you should be doing this as much as you can in any case and in any environment. In practice, there may well be room for improvement here, especially if you’ve just performed a “lift and shift” migration to the public cloud.
Understanding the concept of creating failure-proof architecture
Rather appropriately, the basic concepts behind the creation of failure-proof architecture are actually quite similar to the concepts behind the creation (and adoption) of the public cloud. Basically you deconstruct and hence, effectively, decentralize. In other words, you have to get out of the mindset of creating one robust instance per service and into the mindset of creating multiple smaller instances per service. That way you don’t need to worry about keeping a service running constantly, because a single failure will be a blip rather than a catastrophe.
Defined-duration spot instances
There is a bit of a twist on the concept of spot instances and it is that AWS offers the option of using spot instances for a fixed duration of up to 6 hours at a fixed (and discounted) price and with a guarantee of service, in other words, with no risk of interruption. These can be great for when you have workloads which allow for flexible scheduling, but are of a predictable duration.