What is EC2 Spot?
Explaining Spot Instances: saving 80-90% on cloud compute costs
Spot Instances are one of the three ways AWS sells its compute capacity – the other two being On-Demand Instances and Reserved Instances. In terms of the servers themselves, there is no difference between the three.
The difference is in the business model. Where On-Demand Instances are pay-as-you-go and Reserved allow you to rent a server on a 1-year or 3-year basis, Spot Instances allow you to save up to 90% on your compute costs by using AWS’ otherwise unused servers. AWS wants to monetize these otherwise unused servers, doing so by selling them at an outrageous discount.
What you should know about EC2 Spot Instances:
1. Spot Instances are cheap!
With server costs going at anywhere from 80-90% off On-Demand prices, and 30-60% off Reserved Instances, Spot Instances offer the largest savings across the board.
2. Spot Instances can get terminated within 2 minutes
The caveat of Spot Instances is that AWS can terminate these instances with little to no warning (max of 2 minutes). If your workloads require any availability, consistency, or data integrity, managing these workloads on Spot requires extra configuration and management.
And without any SLA, if something happens, it is your business to deal with.
Understanding EC2 Spot Anatomy
EC2 Spot Instances are AWS’ excess compute capacity (Idle On-Demand Severs); across AWS’ regions, availability zones, instance types, and sizes.
Spot Instances are pretty volatile in specific markets. That is to say, Spot Instances are pretty volatile if you’re looking for a specific instance type in a specific availability zone. This is simply because certain instance types in specific AZ’s are sometimes fully utilized.
For most companies, this means Spot Instance usage is limited to some dev environments and data processing workloads.
However, by leveraging multiple instance types or availability zones, Spot Instances are far less volatile as there is a far greater chance that you’ll find an unused server for one of the fitting instance types in one of the fitting AZ’s. By widening your range of instance types and setting a fallback to On-Demand Instances whenever no Spot Instances are available, you can ensure that you always have a fitting server without sacrificing performance needs. If you can predict the terminations further in advance, this gives you time to trigger a smart migration (all behind a load balancer), guaranteeing that your applications will always stay live despite running primarily on Spot Instances.
Some extraordinary DevOps teams have worked hard to write scripts that manage this system of running mission-critical workloads on Spot by themselves. Others, not wanting to spend the time or take the risk, have leveraged a Spot Management platform like Spotinst to do it for them.