Close

Let's get on each others' calendars.

The Key to Reserved Instances

And How to Mitigate Their Risks

When Reserved Instances can save you up to 72% for the same resources you’d get from on-demand pricing, it might seem like a no-brainer to go for them every time.

Sadly, like every other element of AWS pricing, things aren’t so simple.

The only way to judge whether Reserved Instances are the best choice for you is to fully understand what they are, how they work, the pros and cons of them, and how to mitigate the risks of using them.

That’s why we here at Aimably are here to help! Today’s post will cover:

  • Do you go contract or pay-as-you-go?
  • What are Reserved Instances?
  • How do Reserved Instances differ from on-demand?
  • When are Reserved Instances a good idea?
  • When is on-demand payment or a Savings Plan better?
  • How to mitigate the risk of Reserved Instances
  • How can you predict how much you’ll need to reserve?

It’s time to get started.

Do you go contract or pay-as-you-go?

Pricing models can make a massive difference in how much you end up paying for the same thing.

Think of mobile phone plans, specifically pay-as-you-go vs contract. With pay-as-you-go you pay the full rate for your texts, minutes, and internet usage as and when you use them. There’s no bargaining and no overcharging, as you physically aren’t allowed to use resources that you can’t afford.

Photo of an iPhone home screen
Source

With a phone contract you will usually get a massive discount compared to pay-as-you-go. This is because you’re committing to only using a particular amount of texts, minutes, and non-wifi internet in a given time period (usually a month). You’ll pay the same for that month’s usage no matter whether you actually use your maximum resources, but that commitment gets you a big enough discount to usually be worth it.

On the other hand, there are some potential pitfalls.

For example, poor planning and not knowing your requirements beforehand could mean you pay for a contract that’s far more expensive than what you actually need in terms of usage.

The exact same is true of Reserved Instances (RIs) when it comes to cloud computing resources.

What are Reserved Instances?

Reserved Instances (RIs) are the phone contracts to traditional on-demand payments for cloud resources.

By purchasing a RI you reserve the resources and capacity of a virtual server, normally at a discounted price compared to paying for those same resources via on-demand. The amount you owe will be the same no matter how much of the Reserved Instance you actually use, so some prediction is required to get the most out of your money.

There are, however, ways to mitigate the risk of over-buying RIs and spending (reserving) more than you use. More on that later.

Close up photo of hundreds of servers on server racks.
Source by Victorgrigas, image used under license CC BY-SA 3.0

As we’ve delved into multiple times in the past, traditional AWS pricing structures are unintelligible behemoths for anyone who doesn’t already understand them inside and out. This makes it easy for companies who don’t have AWS finance experience to fall into unpredictable cash flows with wildly fluctuating or unanticipated costs.

Not to mention that your gross margins could be greatly improved with the addition of RI contracts, as they do have some potential resale value and could be allocated as assets instead of expenses.

Reserved Instances (and later AWS Savings Plans) helped to make cloud payment structures more understandable, predictable, and (usually) cheaper for clients. We won’t go into much detail about AWS Savings Plans here, but think of them as Reserved Instances where you commit to spending a certain amount instead of using a certain amount.

How do Reserved Instances differ from on-demand?

Reserved Instances differ from traditional on-demand AWS payments by being less flexible, but more predictable and generally much cheaper (in raw usage terms). While it’s not always this dramatic, Amazon offers up to a 72% discount with their EC2 RIs.

This means that you commit to a certain level of usage for a specific type (eg, M4, A1), region, tenancy (eg, shared), and platform of virtual server, and thus pay the same whether you actually use it or not.

It’s hard to overstate how useful this predictability is in Reserved Instances compared to on-demand pricing.

With on-demand pricing your costs are often impossible to predict and are immediately due, unlike any other business transaction. This means that, unless you’re keeping extremely close watch over your usage and are almost plugged into your own systems and resource requirements, on-demand pricing leaves your company vulnerable to crippling payments that your accounting team has had no time to prepare for.

Reserved Instances solve these issues by bringing in a more traditional business model agreement - you buy a specific type of virtual server for a specific amount of time. If you don’t use it, you still pay for it, and if you use too much you’ll get charged extra.

It might seem like a simple idea, but when the alternative is as bloated and complex as it is that’s exactly what’s needed to clear the field and make things understandable and predictable once again.

When are Reserved Instances a good idea?

Close up photo of a person working on a laptop at a desk. On the screen is an illustrated graph. On the desk is a clipboard and a pen.
Source, image in the public domain

There are a number of reasons to consider using Reserved Instances:

  • You’re consistently using the same type of virtual server
  • You can accurately predict your average virtual server usage
  • You want to reduce the total cost of virtual server ownership
  • You have the resources available to monitor usage and adjust your RI purchases/reselling accordingly
  • You want to have more predictable costs
  • You want to shift some AWS costs onto the balance sheet

First up, when you’re consistently using the same type of virtual server there’s practically no reason not to have a Reserved Instance for that type of server. The discount versus on-demand pricing can be huge, with one of the only drawbacks being that you can’t change the server type of a RI once it’s been purchased.

Similarly, if you can accurately predict your average virtual server usage then you should be able to purchase a Reserved Instance that closely fits your needs. You get the discount for it being a RI without the danger of incurring extra costs from having to buy extra or overspending due to purchasing too much.

The longer you’ve relied on a particular EC2 category, the better candidate it is for you to purchase RIs of. For example, any Auto Scaling group with around 3-6 months of consistent average historical usage should be a safe bet to select for Reserved Instances.

Speaking of discounts, Reserved Instances are a great way to reduce the total cost of virtual server ownership through precisely that. The commitment to purchase a certain type of virtual server (as previously mentioned) can lead up to a 72% discount compared to the exact same purchase through on-demand pricing.

Another instance where RIs can be useful is when you’re able to monitor your current usage effectively enough to adjust your RIs as you go.

By monitoring your own usage you can avoid running out of resources by purchasing more RIs when needed. You can also resell any unused RIs if you end up over-purchasing, which is exactly how you would go about shifting your AWS costs onto your balance sheet.

A person uses a calculator on a desk while sitting in front of a laptop. Also on the desk is a plant, a mouse, a glass of water and some folders.
Source

Reserved Instances retain their value because they’re reserved for a certain amount of time. This means that they have resale value, and so some of your AWS spend can be moved off of your profit and loss statement and onto the balance sheet due to the chance to resell on an RI marketplace. Again, more on that later.

Finally, RIs can be incredibly useful for making your company’s AWS costs more predictable.

Since AWS pricing is hard to decipher and keep constant, the ability to purchase virtual servers in reserved blocks suddenly means that you know exactly what you’re spending instead of being hit by surprise on-demand costs.

When is on-demand payment or a Savings Plan better?

While Reserved Instances are an invaluable tool for AWS financial management, there are still situations where a Savings Plan or even on-demand payment can be better. Namely when:

  • You need flexibility in your virtual server type
  • You can’t calculate what RIs you need
  • You can’t afford to sell back unneeded RIs
  • You only need the resources for a one-off project
  • You can’t afford to lock yourself into a payment contract
  • You don’t have a lot of cash available right now

As a quick precursor to these situations, it’s worth noting that generally a Savings Plan will be better than going for on-demand payments due to the savings they offer.

The first and major disadvantage of Reserved Instances is that you have to commit to a specific server type, so if you’re going to need to switch the type of server you use you’re better off going for a Savings Plan. This should be fairly self-evident if you’re able to predict what type of server you’re going to need in the near future, or if your server requirements have remained (and are likely to remain) consistent for a while.

A data center room with about three quarters of the racks filled with servers.
Source by Helpameout, image used under license CC BY-SA 3.0

There’s also little point in purchasing RIs if you aren’t able to calculate what virtual servers you’re going to need in advance. While you might be able to recoup some costs of unnecessary RIs, in this instance it would be much safer to simply commit to a minimum Savings Plan instead.

Remember that you can’t migrate resource types between RIs, making it even more important that you can predict what resources you’re going to need in advance. If you overuse one type of server, but another type goes completely unused, you can’t balance the load between the two to avoid spending more money.

Speaking of selling unneeded Reserved Instances, it’s not always practical to sell them. If you don’t have the time or resources to both work out what you don’t need and to actually arrange their sale, you won’t be capitalizing on the value they have. It would have been better to not have made the reservation in the first place.

One of the few situations where on-demand payment might work out to be cheaper than RIs or a Savings Plan is when you only need virtual resources for a one-off project. Any discount that you might get isn’t worth the cost of locking yourself into a long-term contract, so the hyper-flexible nature of on-demand is perfect here.

The same can be said if you can’t afford to lock yourself into a long-term payment contract. If you’re not sure whether you’ll be able to afford AWS costs in 3 years from now (or whatever the length of the contract is) don’t let yourself get drawn in by the discounts.

A close up photo of neat stacks of cents organized by denomination on a pile of papers and surrounded by pens.
Source, image in the public domain

The final situation where on-demand can be the way to go is when you don’t have much cash available at the time you’re looking into purchasing virtual servers.

Even with heavy discounts, RIs and Savings Plans often require immense upfront costs versus the lower initial cost of an on-demand arrangement. If you do choose a plan without upfront payment, the discounts are significantly reduced. In the same way that buying a phone is cheaper than paying for it on your contract over time, AWS contracts are best  if you can afford the higher initial price.

How to mitigate the risk of Reserved Instances

We’ve mentioned throughout this article that there are ways to mitigate the risk posed by Reserved Instances, so let’s dive into those now. These are:

  • Use the RI marketplace to manually sell unused RIs
  • Use a third-party broker to manage (and sell) your RIs for you
  • Move to Savings Plans instead for increased flexibility

The primary way to mitigate one of the biggest risks of RIs (buying too much of a particular server type) is to register as a seller on the RI marketplace and sell your unused RIs on to other users.

You won’t be able to completely recoup your costs and there will be some manual effort involved. It’s a marketplace - you need to list the RI at a price that others are willing to pay (fuelled by demand for that server type) and manage the listing yourself, so you do need to have the bandwidth to manage the transaction and the funding to take the hit if you can’t sell it before it expires.

Hiring a third-party broker circumvents the need to manage your RI listings and increases your chances of actually selling them, but it will further eat into the costs you recoup. This is mainly worth pursuing if you have a lot of RIs that need selling or if you don’t have the manpower to spare to sell them yourself.

Finally, Savings Plans have greater flexibility than Reserved Instances but in return can’t be sold on. That means that, unlike RIs, Savings Plans cannot be recorded as assets. You can still get hefty discounts compared to on-demand pricing, but here your limits are directly based on how much you’re willing to spend rather than how much you think you’ll need to use.

How can you predict how much you’ll need to reserve?

Image of two men collaborating in front of a desktop computer which shows a world map overlaid with charts. In the background two other people are high fiving. In the foreground you can see the Aimably logo overlaid and the text reading: "Together, you can be confident your AWS spending is under control."

The best way to be able to predict how much of a certain server type you’ll need to reserve is historical data. That is, to look at how much you’ve used in the past and work out a consistent, accurate average figure to work from.

At the most basic level you can use AWS’ Cost and Usage Reports to keep track of your virtual server requirements and, over time, learn what you’ll need going forwards should operations remain consistent. Unfortunately, AWS CURs can be incredibly difficult to understand and harder still to get any insight from them.

This is where tools such as Aimably’s suite come into play.

Aimably Pulse can be used to keep track of your AWS spending and make sure that everyone knows exactly what to expect. This removes any nasty surprises which might happen as a result of on-demand pricing (especially when paired with Aimably Warn to prevent sudden overspending), leaving you safe to monitor your operations while you figure out what RIs you might need.

Speaking of which, Aimably Insight can help you do precisely that! By analyzing your AWS CURs we can provide you with exactly what you need to know about your usage and spending, letting you get on with buying the RIs that fit your needs and saving a stack of money in the long run.

What are you waiting for? Sign up for Aimably here!

AWS Deep Dive