Everyone wants to save money
We all prefer spending less money, be it as individuals, small startups, or massive corporations. Cloud spend is no different. Companies and their Devops teams often focus entire quarters on lowering their cloud costs, going through the details to find new ways to optimize their bottom line. At the end of the day, this “optimization” is just that – an optimization of costs, but not a sizable reduction. While it is still extremely beneficial for companies that spend a lot, all this work usually doesn’t amount to major changes in the bottom line.
That is, until Spot Instances came around.
The dawn of Spot Instances
Spot Instances are not a new development. Back in 2009, Amazon announced their new offering, with some speculating that this could be the dawn of a new era of cloud pricing. A world where cloud pricing is dynamically impacted like any other market – by supply and demand.
The new pricing model was simple on its surface but complex under the hood. At a high level, Spot Instances are AWS’ way of selling its excess capacity. Basically, AWS always has a ton of servers that aren’t being used. They need these servers to be available for new customers or existing customers looking to ramp up their instances, but at any given time, there are always going to be unused servers. Rather than just leaving them empty, AWS offers these servers at a highly discounted price, generally around 20% of the on-demand cost.
But Spot savings come with risks
It seems like a no-brainer, “get the same server for 80% less”, but it’s not that simple. Once those servers are demanded by other customers, AWS will kick you off with 2 minutes notice. This means that Spot Instances are really only relevant for transient applications. If you’ve got databases or highly available applications running on Spot, you’re going to be in trouble when you get kicked off.
The complexity doesn’t end there. Spots got their name from the financial Spot Market, where prices constantly fluctuate and change. Accordingly, Spot Instance market prices fluctuate and can be quitevolatile, sitting at low prices one minute only to jump above the on-demand price the next. Reported changes to this volatility are expected, but the prices will still be relatively unpredictable.
This combination of risk and complexity makes Spot Instances a no-go for most. The risk mitigates most of the value, as Spot Instances are only relevant for a tiny portion of applications. The added complexity of Spot pricing changes makes the effort of using Spot not worth the potential gains for most IT teams.
Those risks with Spot no longer exist
Spotinst has changed all of that by eliminating that risk. Offering 100% availability on Spot for any application without a single point of failure, companies can easily leverage the 80% cost savings Spot Instances have to offer for almost any application. As long as it doesn’t have a single point of failure, it can run on Spotinst without risk of downtime. What was previously relevant to only a handful of transient tasks is now relevant for almost any workload. Essentially, now companies can save 80% across almost their entire Cloud infrastructure.
The really remarkable thing is how Spot usage has grown alongside our growth.
As you can tell from the graph above, Spot Instance popularity plateaued shortly after its 2009 release, not really gaining much traction. Since Spotinst’s birth, however, the popularity of Spot Instances has quadrupled. It’s not hard to tell why – Spotinst makes Spot Instances both easier and safer to use.
What is your Spot Instance strategy?
We’ve partnered with AWS reps and Solution Architects across the globe to help you leverage our platform. Whether you currently leverage Spot as a part of your infrastructure, need to cut costs, or you’re just looking to grow your workload with a limited budget, every efficient DevOps team should have a Spot strategy and plan in place.