Joseph Sibony
reading time:
If you’re trying to understand the difference between On-Demand, Reserved, and Spot Instances, it’s probably because one of two things has happened.
Either you’re kicking off a new project and trying to figure out how you can make sure your team has enough cloud capacity to get the job done.
Or you’ve just been caught off guard by an eye-watering cloud bill and you’re frantically looking for ways to get your costs under control.
Whatever spurred you to start digging into cloud instances, you’re moving in the right direction.
And luckily, the types of instances — and the pros and cons of Spot vs. On-Demand vs. Reserved Instances — are easy to understand.
The key is finding an instance type that offers the right balance of cost, stability, and flexibility for you and your project.
On-Demand Instances are, essentially, instances that you pay for as and when you need them. Think of these as “pay-as-you-go” instances, which you can be charged for either by the hour or by the second. You buy as much cloud computing capacity as you need, whenever you need it, with no long-term commitment. When you don’t need it anymore, you withdraw your workloads and cancel the instances, increasing or decreasing your cloud capacity as your computing needs change.
Call in the On-Demand Instances when you need stability and flexibility. That generally means you’ll never use them whenever you’re running processes with uneven workloads that can’t be interrupted without disrupting your applications.
Try to stick to using On-Demand Instances for short-term projects where you’ll struggle to predict the amount of capacity you’ll need at any given time. If your project is running for longer, or you can predict your computing needs with some level of accuracy, it’s much more cost-effective to use Reserved Instances instead.
Reserved Instances are configured almost exactly like On-Demand Instances. The only difference is that instead of requesting instances as and when you need them, you “reserve” instances for either one year or three years.
That commitment pays off, as Reserved Instances offer pretty significant discounts compared to On-Demand instances.
There are two types of Reserved Instances:
Convertible Reserved Instances obviously give you a lot more flexibility but they’re also slightly more expensive than Standard Reserved Instances.
Reserved Instances are assigned to specific Availability Zones, so if you need control over your app’s performance globally, this may be a drawback.
Reserved Instances are best for projects that have pretty even, predictable compute requirements.
If you’re going to commit to using them (and paying for them) for one to three years, you should be relatively certain that you’re going to be using most of the capacity for the entirety of your reservation period. That way, you can relax knowing that you have all of the capacity you need, and you’re not wasting money on instances that you only end up using once or twice.
Cloud providers need to keep some space capacity available, in case there’s a huge surge in demand from customers — but for much of the time that spare capacity just sits unused.
When you buy a Spot Instance, you’re essentially borrowing excess capacity from your cloud provider for a certain period of time. “Borrowing” is the operative word here. If demand goes up and your cloud provider needs that extra capacity, they’ll take it back — often with less than a minute’s notice before your workloads disappear.
But that doesn’t mean you should avoid Spot Instances altogether — it just means you should use them strategically.
You’ll generally be advised to use Spot Instances for stateless, containerized applications that run short-term tasks. We’re likely to see them being used more and more as the way we use the cloud develops and teams look for more flexible, self-contained cloud builds. They’re perfect for projects like CI builds where you need lots of flexibility at a low cost (you can read more about how to do with GitHub Runner on AWS here).
On the whole, you should avoid running business-critical applications on Spot Instances — nothing that will cause disruption for customers if the application goes down.
However, there are ways around this. If you want to use Spot Instances for a wider range of projects without risking your applications, look for a cloud optimization service that uses Spot Fleets — collections of Spot Instances grouped together that allow you to switch to another Spot Instance if one of them is revoked.
Choosing a type of instance is less about finding one type of instance and sticking to it; most teams find themselves using a combination of all three types, depending on the situation.
The types of cloud instances can seem confusing at first, but they’re really quite simple once you dig a little deeper. Like most of the questions devs face when it comes to optimizing spend and ironing out processes, it’s all about balance — finding the sweet spot between cost, flexibility, and reliability, and choosing the combination that works for you.
Table of Contents
Shorten your builds
Incredibuild empowers your teams to be productive and focus on innovating.
Incredibuild empowers your teams to be productive and focus on innovating.
