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.
What are On-Demand Instances?
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.
Advantages of On-Demand Instances
- Effortless scalability – A stable, pay-as-you-go model like this means you can reap one of the key benefits of running processes like CI and CD in the cloud: scalability. You can easily increase or decrease the instances you’re using at any time, without being tied into a certain spend or number of instances.
- Flexibility – On-Demand Instances are perfect when you can’t predict how much cloud capacity a project will need. Instead of getting tied in to paying for capacity that you never end up using, you can keep re-evaluating your needs and scaling your instances up and down to fit.
- Stability – On-Demand Instances are yours for as long as you need them, and there’s no danger that your cloud provider will revoke your access to their servers.
Disadvantages of On-Demand Instances
- The cost – On-Demand Instances are the most expensive type of cloud instance — it’s the trade-off that comes with having flexibility and the freedom to scale your capacity up and down as you need it.
- Pricing can be confusing – With different rates available for different instance types and server regions, figuring out how much it’ll cost to get the instances you need can be a major headache. The good thing is that if you miscalculate and the costs start racking up, you can easily adjust the instances you’re using to get costs under control.
- Insufficient capacity errors can be a pain (but they’re rare) – If the capacity you need isn’t available when you request it, you’ll get an insufficient capacity error (ICE). If you want to get the types of instances you need, you’ll need to keep trying to manually request instances until they’re available. However, ICEs are very rare; you’ll only really need to worry about them during cloud outages, when customers are trying to protect their capacity by switching to On-Demand Instances.
When should you use On-Demand Instances?
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.
What are Reserved Instances?
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:
- If you use Standard Reserved Instances, you can only use instances from within one instance family, on the same operating system.
- If you use Convertible Reserved Instances, you can use instances from different families and on different operating systems.
Convertible Reserved Instances obviously give you a lot more flexibility but they’re also slightly more expensive than Standard Reserved Instances.
Advantages of Reserved Instances
- Big discounts – If you want a relatively low-risk way to optimize your cloud spending, Reserved Instances are an excellent option. Reserved Instances are discounted by between 40% and 60% (depending on the type of instance and the cloud provider) from On-Demand Instance prices.
- No cloud bill shock – There are no nasty surprises with Reserved Instances. The price of your Reserved Instances won’t change until your one-year or three-year commitment is up, so you’ll never have to worry about prices spiraling as demand rises.
Disadvantages of Reserved Instances
- Less flexibility, more commitment – As long as your contract lasts, you’ll need to pay for the instances you’ve reserved — even if you’re no longer using all of them. If your compute requirements change before your term is over, you might be stuck paying for capacity that you don’t need.
- Fixed prices might mean you miss out on savings – Fixed prices obviously protect you from price spikes, but they also mean that you may end up paying more than market rate for your instances if the price falls. Convertible Reserved Instances can help you avoid this, as they allow you to switch to other, cheaper families of instances if you want to save some money. Some plans, like the AWS Savings Plans, let you commit to a specific spend, rather than a specific service — it’s up to you how many instances and what type of instances you take on to reach that spend.
Reserved Instances are assigned to specific Availability Zones, so if you need control over your app’s performance globally, this may be a drawback.
When to use Reserved Instances
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.
What are Spot Instances?
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.
Advantages of Spot Instances
- Enormous discounts – When you weigh up the prices of On-Demand Instances vs. Spot Instances, there’s really no competition. Because they don’t require any commitment on your cloud provider’s side, Spot Instances can cost up to 90% less than On-Demand Instances. That’s why Spot Instances are often lauded as a tool for overcoming one of the major barriers to cloud adoption, especially for game devs who are under pressure to keep cloud costs down.
- Flexibility – Once you know which type of instances you need, you can request Spot Instances and get up and running pretty quickly. And, when you don’t need them anymore, you can shut them down straight away. You only ever use as much cloud capacity as you really need from moment to moment.
Disadvantages of Spot Instances
- Spot Instances can be unreliable – There’s a trade-off here: No commitment means that you get your Spot Instances for cheap, but it also means that you can’t really rely on individual Spot Instances for any crucial applications. If your cloud provider needs the extra capacity, they’ll only give you a few minutes of notice before they take their Spot Instances back. That means it’s usually unwise to run any business-critical applications that can’t be paused or shifted at short notice on Spot Instances.
- Pricing can be uncertain – The hourly price for Spot Instances varies based on demand, so it’s sometimes tough to predict exactly how much you’ll pay for Spot Instances if you’re using them regularly. The result is that even at these discounted prices, costs can creep up unexpectedly.
When to use Spot Instances
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.
Which type of instance is right for you?
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.