Making Sense of AWS Reserved Instances

In our previous blog, we showed how EC2 Cost Optimization starts with choosing the right instances – (Start Smart) and continues with continuous data-driven Instance Optimization (Stay Smart).  With that foundation in place, we will now focus on getting significant discounts in AWS without making any changes to your deployment – by using reservations.

AWS likes it when you plan your resource allocation in advance – it helps them plan out their resources better, and they share the savings with you.

Like any service provider working at scale, AWS follows some basic laws of economics in pricing and offers significant breaks for:

  • Buying in volume – most services have a cheaper price per unit for larger volumes
  • Making commitments – 1- and 3- year commitments are available for most services
  • Prepaying – the more you pay up front, the larger your discount level

Long term commitments, pre-purchasing resources – all that sounds a bit like early binding, doesn’t it? Wasn’t the cloud supposed to help us avoid all that?

Yes.  But, there’s no escaping the basic laws of economics.

AWS was early in recognizing the need for balancing resource allocation for cost vs the need for agility and started offering EC2 Reserved Instances in EC2 in 2009.  Since then, the concept has been extended to included Reserved Capacity in RDS, ElastiCache, Redshift and DynamoDB.

Because the lion’s share of AWS bills are EC2, we will focus on EC2 Reserved Instances in this article – we’ll discuss how Reserved Instances work in detail, and in the next one we’ll share some best practices around Reserved Instances.

It’s a lot to read, but its worth investing time into this topic – Reserved Instances can give you up to a 50% pricing break on EC2, all without making a single change to your deployment.

Lesson #1 – A Reserved Instance is just a Financial Instrument – There is no Instance

A Reserved Instance is just a Financial Instrument

The most important thing to understand about a Reserved Instance (often just referred to as an RI), is:

  1. It is a billing concept
  2. It is not an instance
  3. Often, it isn’t even a reservation

The name is a historical artifact; when introduced in 2009, a RI was just a prepayment for reserving instance capacity in an AZ. But, the name stuck, even though a lot of extra functionality has been added.

Think of an RI as a prepaid voucher that you hand over to the AWS cashier.  At checkout, the cashier looks at all the line items on your bill and applies all vouchers whose Terms & Conditions match items on your bill.  If the T&Cs don’t match, the voucher isn’t used.

In AWS terminology – An RI is applied to an on-demand instance with matching attributes.

The phrase “with matching attributes” is key, because the match must be 100% (there is one exception – called Instance Size Flexiblity. We will get to that, just ignore it for a bit).

If the attributes don’t match, the RI sits there unused.  Unused vouchers (RIs) are a double whammy – you will have paid for the unused reservation and then you will most probably pay on-demand rates for another instance to take its place.  The T&Cs are key – you need to know how the fine print works to extract the most value out of an RI.

Don’t worry, there isn’t a lot of print, and it isn’t very fine either – AWS is quite transparent about how RIs work and how they are used.

AWS provides tools to help you extract the most out of your RIs, in addition to which there is a rich set of third-party tools that can help you understand how to best use RIs a well.

Lesson #2 – There are different types of RIs – Standard, Convertible and Scheduled

In 2009, EC2 launched with only one kind of Reserved Instance now called the Standard RI. In 2016 Scheduled Reserved Instances were launched and in 2017 AWS followed this up with a new variation called a Convertible Reserved Instance.

  • Standard RI – these are the most restrictive, but in return provide the best cost savings.
  • Convertible RI – these add a lot of flexibility, but come with significant reduced savings over Standard RIs.
  • Scheduled RIs are the long-lost cousin of the RI family – they hardly come up during family gatherings. Scheduled RIs come with a lot of caveats – you need to have a specific schedule defined up-front, there is a limited list of instance types that are applicable, and all payments must be up-front.

Note: We will not be discussing Scheduled RIs in this article. Anecdotal evidence shows that few users have the kind of control that would make Scheduled RIs a viable option at scale. In many cases, a Spot Instance may actually be a better choice over a Scheduled RI.

Actual discounts vary by region, instance type and other factors; we used a m5.large instance in us-west-2 as a benchmark to come up with approximate discount figures on discounts.  But, these are indicative of all other instances in all other regions as well.

12-month 36-month
Standard 40% 61%
Convertible 31% 54%

Lesson #3 – A RI has two benefits – capacity reservation (sometimes) and pricing breaks (always)

In EC2, you are not guaranteed to be able to bring up an instance – it is brought up only if there is sufficient capacity in your specified AZ/Region.  It is rare to get an “insufficient capacity” message, but it does happen.

A Reserved Instance has two benefits – the reservation of capacity and the pricing break.  But, even though the name RI implies you’ve always reserved capacity, this isn’t always true.  A Reserved Instance could include a capacity reservation – it depends on the scope of the RI.

When you purchase an RI, you have two choices for scope (Zonal and Regional).  When your purchase is Zonal, you do reserve capacity in that specific AZ.  When you choose a Regional scope, you only get the pricing breaks and not capacity reservation.

This is in line with the AWS pricing philosophy – the more specific your commitment, the greater your benefit.  In case of an AZ, that is about as specific a scope as you can set. In return, AWS gives you the benefit of guaranteed capacity.

This is an important point to keep in mind when you’re planning mission critical workloads.  In general, the odds of an AZ running out of capacity are higher than an entire region running out of capacity.  Imagine your HA instance not coming up because you’ve specified an AZ that has temporarily run out of capacity.   In such cases, you may want to use RIs not just for pricing breaks, but also for reserving capacity.

We will get to RI flexiblity in a bit, for now it is worth noting that you can change RI scope so you’re not locked into your first choice.

Lesson #4 – AWS looks at total EC2 utilization when applying RIs, not at specific instances

The AWS FAQ has this to say about billing “A Reserved Instance billing benefit is applied to a running instance on a per-second basis. A Reserved Instance billing benefit can apply to a maximum of 3600 seconds (one hour) of instance usage per clock-hour. You can run multiple instances concurrently, but can only receive the benefit of the Reserved Instance discount for a total of 3600 seconds per clock-hour; instance usage that exceeds 3600 seconds in a clock-hour is billed at the On-Demand rate.

This is quite a mouthful, what it means is:

  • RI time is measured in seconds – the granularity of billing in AWS
  • Only one instance can use a RI at any given time
  • A RI is just applied to whatever matching instance happens to be at hand – once this instance stops, the RI will be applied to the next matching instance
  • Note that RIs are only applied if an instance that meets its criteria is available, it will not be applied

The below illustration may make this a bit easier to understand. In this case, assume that a single RI has been purchased for a m4.large instance before the below sequence of events:

Time Action Taken Running Instances Billing Result
08:00:00 Start Instance1 (m4.large) Instance1 RI is applied to Instance1 (XXX Check what CUR and Bill say – would be nice to add )
08:00:29 Stop Instance1 RI becomes unused (XXX what is the official term?)
08:00:30 Start Instance2 (m4.large) Instance2 RI is applied to Instance 2
08:01:00 Start Instance3 (m4.large) Instance2, Instance3 RI in use, Instance3 billed at On Demand Rate
08:07:00 Stop Instance2 Instance3 RI switches over from Instance2 to Instance3 (On Demand billing stops)
08:10:00 Stop Instance3 RI becomes unused
8:11AM Start Instance4 (t2.medium) Instance4 Since the attributes don’t match, the RI continues to be unused

Lesson #5 – RIs can be applied to an instance or part thereof

It is Urban Legend that an RI can only be applied to an instance that very specifically matches all its attributes, including instance size.  This was true until March 1, 2017 when AWS launched Instance Size Flexibility (ISF).

Note: ISF only applies to RIs that have Linux/Unix as their OS, with Shared Tenancy and with Regional scope, so the Urban Legend is still partially true – Windows RIs, Dedicated Tenancy or those with Zonal scope are not eligible for ISF.

ISF means an RI can be applied on a pro-rated basis to any member of the instance family you have chosen.

Huh, Pro-rata? The pro-rata calculation is applied based on the “normalization factor” of the instance size.

Intuitively, normalization factor is exactly what you would expect. Each size in a family is ranked on a scale based on size.  The scale is as follows:

Size Normalization Factor
nano 0.25
micro 0.5
small 1
medium 2
large 4
xlarge 8
2xlarge 16
4xlarge 32
8xlarge 64
10xlarge 80
16xlarge 128
32xlarge 256

For example – you purchased a RI for a m4.large, but ended up using m4.2xlarge. Prior to ISF, your RI would be wasted.  Now, your RI will be applied to m4.2xlarge, but only for 25% – because the normalization factor of a large is only 25% of the normalization factor of a 2xlarge.  The other 75% will be billed at On Demand rates.

The pro-rata works in reverse too – an RI for a larger instance type can be applied to a smaller one.  But, the unused portion of the larger RI will go to waste in this case.

Note: The ISF concept is closely tied to the idea of splitting and combining RIs (doesn’t sound familiar? that’s because we haven’t gotten to that one yet), except now AWS does it for you instead of you having to figure out what needs to be done and doing it.

Lesson #6 – Linked accounts can share a pool of Reserved Instances – so, buy them centrally

Many AWS customers use accounts as a security boundary between functional groups, or business units – e.g QA/QC uses an account and the production team uses a different account.

Then, they link all the accounts together to a central account where all the billing is handled. The end result looks like a star topology – the central billing account in the center, all the other accounts around it.

RIs can be shared between linked accounts – this means if you don’t use an RI, somebody else in any linked AWS account can use it.   So, if you procure your RIs centrally, anybody in the organization will be able to make use of it.  Keep in mind that RIs require no action on your part – they are applied to whichever instance matches the attributes, so by centrally acquiring RIs you are in effect creating an RI Pool that can be used by your entire organization.

It should be noted that when another account uses your RI, they only get to the use the pricng break offerd by the RI. Any capacity reservation is not part of the pool.  This needs to be kept in mind when reserving capacity for mission critical instances – if you procure them centrally, then the account that needs the capacity reservation cannot make use of it.

Lesson #7 – An RI has a lot of attributes – you have to get them right up front

This is the Terms and Conditions portion of the prepaid voucher.  An RI is applied to a running instance if and only if all its attributes match, there are no wildcards here (other than Instance Size Flexiblity). So, making sure you have these right is very important.

When you purchase a Reserved Instance, you have to make a number of choices (see screenshot of management console)

RI attributes that you can select are :

  • Platform – Linux vs Windows
  • Tenancy – Default vs Dedicated
  • Offering Class – Standard RI vs Convertible RI
  • Instance Type – t2.micro, m4.xlarge etc.

RI payment terms are:

  • Term – 1- and 3- year terms are available
  • Payment Option – All Up-Front, Partial Up-Front, No Up-Front

Choose them wisely; remember RIs are only applied if all attributes match (other than Instance Size Flexbility – which is a specific exception discussed earlier).

The good news is that you may be able to edit these attributes to optimize your costs.  The band news is that understanding when you can change what can get quite complex.

Lesson #8 – But, you are not locked into these, RIs have become quite flexible over time

RIs are not static, they can be modified by submitting a Modification Request. There is no limit to the number of (serial) modification requests you can request to an RI.

You can change the following attributes via a modification request – i.e. the below apply to any RI type – Standard or Convertible

  • Scope – You can switch from Zonal to Regional (or vice versa) or modify the AZ or Region to which the RI applies. Note that when you switch from Zonal to Regional, you lose the Capacity Reservation feature of the RI (but gain it back when you switch from Regional to Zonal)
  • Instance Size – The instance size can be modified by either splitting the RI, or by combining smaller RIs into a bigger one.  The rule of thumb is that the “footprint” of the RI must stay the same (footprint is calculated based on Normalization Factor, which we discussed earlier)

In addition, Convertible RIs give you the ability to trade-in (exchange) an RI for a brand new one – as long as you respect the footprint of the RI (i.e. you can’t use more compute capacity than you paid for).

The summary of attributes is as below:

Attribute to be changed Standard RI Convertible RI
OS Family No Yes (via an RI exchange)
Tenancy No Yes (via an RI exchangeI)
AZ – within Region Yes Yes
Scope (between Zonal and Regional) Yes Yes
Region Yes Yes
Instance Size (e.g. m4.large to m4.xlarge) – Linux Only Yes Yes
Instance Family (e.g. m4 to c5) No Yes (via an RI exchange to a new RI)
Merge RIs (Note: Linux Only, cannot change family and generation – only size) Yes Yes
Split the RI Yes Yes

Lesson #9: What does it mean to merge or split RIs?

First of all, Split and Merge are not terms used by AWS – for AWS, they are just Modification Requests.  We call them Split and Combine to make it easier to understand what we are going to do with the Modification Request.

AWS allows you to combine 2 Reserved Instances into one larger RI, or break a RI into smaller RIs – as long as you stay within the bounds of the “footprint” of the source RIs.  The Footprint of an RI is just the sum of Normalization Factor of all the instances contained with the RI.

Two important points to note around the merge:

  • You can only merge RIs with the same initial term – i.e. 1-year RIs can only be merged with 1-year RIs and 3-years with 3-years. This has no relation to the amount of time remaining in an RI, the limitation is on the initial term purchased.
  • When you merge 2 RIs with different expiry dates, the combined RI will expire on the furthest of the expiry dates of the individual RIs being merged. For example, you combined 2 RIs with the folliwng characteristics:
    • M4.xlarge, expiring on 31/1/2020
    • M4.xlarge expiring on 31/3/2020

You will end up with 1 RI for a M4.2xlarge, expiring on 28/2/2020.  In addition, you will owe AWS (via a true-up) for the extra 2 months (from 31/1 to 31/3).

Merge and Split sounds good enough, then why bother with Convertible RIs?

When you merge or split RIs, you have the following restrictions:

  • You can only change size, instance family (e.g. m) and type (e.g. 4) must stay the same. You can’t move from an m4 to a m5, for example.
  • You can’t change the effective term of the RI (e.g a 1-year RI can’t become a 3-year RI)
  • You can’t mix 1- and 3- year RIs

i.e. you can change instance families, up the terms, co-terminate RIs etc.

By converting an RI, you basically trade it in for a new RI whose value equals the remainder of the RI, or is greater –If greater, you pay the difference via a “true-up”.

Lesson #10 – There is a “second hand market” for RIs (but only Standard RIs)

When you go to purchase an RI, you are presented with a menu of choices that match the attributes you select. These choices can come from AWS, or from any third party who has an RI they want to sell.

So, if you purchased an RI that you don’t need, you have access to a marketplace to sell it and recoup some of the cost.  You can only sell the unused portion of the RI – for example, if you bought an RI for 36 months and sell it 9 months down the road then you’re selling a 27 month RI.

As a buyer of an RI, this could also mean that you may be able to find an RI that meets your needs at either a discount or a reduced term – or both.  Note the discount can only be on the up-front costs paid by the original RI purchases, you can’t modify the terms of the monthly payments of the RI.

When you buy an RI from the market, you are also buying whatever obligations the original buyer had to AWS – i.e.:

  • A seller can choose a price point for the up-front fees (money already paid to AWS)
  • But, they cannot make any alterations to the remainder of the terms (any future financial commitment made to AWS)

Now that we’ve covered all the complexity around RIs, we will explore some best practices around RIs in our next article.



Manoj Nair joins HyperGrid from HPE where he was GM and VP of Product Management for Converged Infrastructure. His team was responsible for driving the Product Strategy and Roadmap across all elements of the Converged Portfolio & Infrastructure Management. Prior to HPE, Manoj was SVP leading strategy and R&D for the Public Cloud solutions at EMC. This was an incubation team working across the EMC federation of companies. Previously, Manoj was SVP & GM at RSA – responsible for IAM & Authentication product lines. Previously he led R&D and Product Management for RSA Security Management portfolio. Manoj also led R&D for EMC's internal incubation project, EMC Infoscape, as well as the architecture of the EMC PowerPath product family. Manoj has also held development and research positions at Data General, Novell and US NSF funded Research Labs. He is also the holder of over a dozen patents granted by USPTO in Systems Software, File systems, Information Management and Security. Manoj holds a M.S. in Computer Science from Clemson University. Forbes Technology Council, Official Member 2018

Post a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.