Developing your Spot and Reserved Instances strategy

How to leverage Spot and Reserved Instances

53% of DevOps pros say that their main initiative in 2017 was optimizing existing cloud costs. Unfortunately, most companies focus on the pennies rather than the big bucks when it comes to reducing their cloud costs.

A quick breakdown of these activities shows that most of them are focused on simply optimizing existing workloads. Doing things like:

• Monitoring CPU utilization to ensure their instances are actually being used
• Writing scripts to shutdown workloads or storage volumes in slower hours or weekends
• Selecting the best-priced regions

All of these activities are important. But each also requires what is sometimes a frustratingly large amount of attention, and many of these efforts can be automated through some smart use of Auto-Scaling Groups and Target Tracking.

Then how do you really reduce cloud costs?

Spot Instances and Reserved Instances.
Spot Instances offer up to 90% off On-Demand prices and Reserved Instances up to 75%.

In fact, while most DevOps teams spend much of their time focused on the above activities, all of those efforts pale in comparison to the impact of adopting a strong RI/Spot strategy. Why spend all of your work year working on optimizing to save maybe 20-30% when you can adopt a strong RI/Spot strategy to save anywhere from 60-90%?

Initial decisions: choosing between Spot and Reserved Instances

In short, there is an ideal mix of Reserved and Spot Instances you should be leveraging to optimize your cloud economics. There’s no one-size-fits-all solution but there are a few basic practices to follow:

• Use the Spot Analyzer to find some workloads which are suitable for Spot Instances

Get a clear picture using Spotinst’s Spot Analyzer of which workloads you have that can be run on Spot Instances with confidence. This feature basically analyzes your tags to find out which of your workloads can fit for Spot.

[alert type=”info”]Anything without a single point of failure should be run on Spot Instances [/alert]

That said, walk before you run. Don’t start by trying to migrate all potential fits for Spot to Spot. Start with a particularly small ASG or two or a containerized workload (be it ECS or Kubernetes), run it for a couple of weeks, and then decide which workloads to run next.

[alert type=”info”]Reserve (1-year no upfront) your Database Instances, especially Production DBs [/alert]

Take your baseline DB workloads over the past 6 months and go ahead and take a 1-year RI out on those. Paying partially or fully upfront will help you save even more on those, so if you can get sign-off on that, utilize that advantage to create more wiggle-room in your budget. Start with one workload.

It can be a pain to find and utilize all of your reservations, especially when you have multiple reservations across multiple accounts purchased by multiple team members. Spotinst’s platform will automatically utilize all of these reservations at no charge. So you don’t need to worry about forgetting about them in the future.

Re-evaluating your Spot Instances and Reservations

After a few weeks, you should have a good feel for the sort of savings Reserved and Spot Instances can bring.

As a general rule, anything without a single point of failure should be run on Spot. Meaning that if it’s running behind a load balancer or in multiple AZs and isn’t a MySQL database – it can (and probably should) be run on Spot.

As another general rule, run your databases on Reserved Instances. Use a basic level of capacity from the past 6 months that you don’t expect to go under as reference (if you’re growing fast, then use the past 2-3 months as reference), and book that amount in Reserved.