AWS Reserved Instances
AWS Reserved Instances
Reserved Instances
How to Plan, Purchase & Get the Most Saving Power from Your RIs
Contents
PART 1
The Basics 03
PART 2
PART 3
Modifying RIs 16
PART 4
RI Portfolio Management 19
Introduction
Reserved Instances (RIs) can save you a lot of money with Amazon Web Services (AWS). Using
RIs, our customers routinely save 30% off the On-Demand price. It’s enough to make any
company sit up and take notice. But there’s a catch. While RIs can yield substantial savings, a
misstep can erase your hard-won ROI, or even cost you dearly.
At first glance, RIs can seem extremely complicated, but you don’t have to be afraid of
them. When used correctly, they can be the one of most powerful cost-saving tools Amazon
provides. Any company looking to lower their cloud costs should take the time to get truly
familiar with RIs.
That’s why this e-book is here. We’ll walk you through RI basics, show you how they work,
help you calculate your RI needs, and show you how to manage your RI portfolio going
forward.
The Basics
Think about an RI as a bulk discount. With On-Demand, you only pay for the resources
you use down to the second. With RIs, you’re purchasing resource hours in bulk, and like
any bulk purchase, that comes with a substantial discount. Like any bulk purchase, it only
makes sense if you’re going to use enough to make the investment worthwhile. In their
system, AWS classifies RIs as a billing discount applied to your On-Demand use. We’ll go
more into how that all rolls out below.
RIs are categorized by the combination of all four attributes, such as an m4.xlarge
Amazon Linux, default tenancy instance in us-east-1b. When you run an instance with the
same attributes as an RI, the discounted rate is applied to your usage.
When you purchase an RI, you have a couple of options for scope. If you select the Region
scope, then your RI can apply to an instance in any AZ within that Region. If you select a
specific AZ, then the RI will only apply to instances in that AZ. But what are the benefits of
each option?
RI Application in Action:
So you’ve purchased an m5.xlarge Amazon Linux Availability Zone us-east-1b RI. Now
what? If you spin up an m5.xlarge instance in us-east-1b, then the RI rate will apply to
that instance. If you spin up a second m5.xlarge at the same time, it can’t use the single
RI you’ve purchased because it’s already in use. So the new instance is billed at the On-
Demand rate. You’d either need to purchase a second RI for the new instance or turn off
the first instance so the newly-freed RI will switch over.
In that same example, if you spin up a t3.xlarge, then it will be billed as On-Demand
since the instance type doesn’t match, even if the RI isn’t currently being used. Basically,
an RI rate can only be used for instances that fit the same attributes and only applies to
one resource at a time.
As a note, the capacity reservation doesn’t go along with the RI when inherited. That will
always stay with the account where it was purchased.
The two RI types are applied the same way, but there are a few key differences:
Terms (avg. savings) 1yr (40%), 3yr (60%) 1yr (31%), 3yr (54%)
At first glance, you might be tempted to go with Convertible RIs just to be on the safe side for
the flexibility. But as you can see, Standard RIs provide much more savings and can be sold on
the RI Marketplace.
In the end, the right kind of RIs will depend on your company and how you’ll use the RIs.
No matter which option you choose, you need to get enough use out of any RI to break
even and then generate savings. We define the break even point as the point at which
you’ve used the reservation for enough hours to make up for the cost of the reservation
by accumulating savings over On-Demand. Everything beyond that point is savings
gravy. The break even point will vary depending on the type of RI you purchase. Three-
year standard terms paid All Upfront will give you more savings and lower break even
point, but require more initial investment.
The yellow line is RI costs, while the blue line is On-Demand costs.
As you can see, RI planning can get very complicated, very quickly. A good RI planning
tool (like we have in Cloudability) can instantly show you where the break even point
will be and analyze your past use to figure out whether the investment in an RI would
be worthwhile.
RI Planning
& Purchasing
In this, an RI could only apply to Instance A while leaving Instance B and C at On-Demand
pricing. Since none of the instances are run long enough to hit the break even point, On-
Demand is the more affordable option.
To help figure this out, we recommend the Waterline RI planning model. In this model, the
use of instances that could fall under the same RI are all grouped together, then plotted
against their hourly use. The result looks something like this:
In this graphic, each letter represents one of eight different instances of the same type.
For the purposes of this example, let’s assume this same ten-hour pattern is repeated for a
whole year. At a glance, this charting method shows you that there are always four instances
running, with five running 90% of the time and six running 80% of the time. That means:
If you selected an 80% waterline, then charting your use like this would instantly show you
that you need to purchase six RIs to hit your savings goals. As a side note, this example
shows the weakness of looking at an individual utilization rate. Only four instances in this
graphic are used 80% of the time (A-D), but only buying four RIs would miss out on two RIs
worth of savings.
It might not seem like that much, but look at it this way: buying six RIs instead of four
increases your RI utilization rate by 50%. If you’re currently saving $600,000 a year by using
RIs, then utilizing those extra RIs will increase your savings to $900,000.
Three years is a big commitment, so it’s not surprising that many people shy away from
purchasing three-year RIs. But three-year RIs offer substantially bigger savings with an
earlier break even point, usually only slightly longer than one year. That gives them, by far,
the biggest savings potential.
If you look at the above chart, you’ll notice that the difference between No Upfront
and All Upfront is about 5%. The impact of that 5% on your finances is going to depend
on several different factors, including which term you plan to use and where you place
your waterline.
In the end, it really comes down to your company’s financial principles and operating
capital. Balance the pros and cons with your capital flow to find the best option.
There’s a temptation to overbuy and make as big of a splash as possible, especially if you’re
trying to prove the savings potential of RIs to the rest of the company. But in the end, it’s
much better to make small, iterative purchases. Buying too many RIs now has the potential
to lock you into the wrong instances. Not to mention that fact that more complicated and
more expensive buys will often have more complicated approval processes. You can always
purchase more RIs later as you become more comfortable with them and have a longer track
record for your cloud usage.
The right cloud cost management tool will be essential at this phase. Not only are you
moving into a new technological arena, but it’s common to be under pressure to justify your
actions and prove the expected ROI. A good tool, like Cloudability, will give you the data you
need to have confidence in your decisions and to make your case when getting approval.
Modifying RIs
If you’ve selected a specific AZ within a region, then you can modify the AZ, such as
moving it from US-West-2a to US-West-2b. When you modify the AZ, the capacity
reservation goes with it. As a note, you can’t modify the RI to move between different
regions. If you bought it in US-West-2, then it has to stay there.
Modifying the AZ is a handy tool to keep your infrastructure together. If new essential
projects that require reserved capacity are all being built in EU-West-1b, then you might
want to shift your RIs (and workloads) for existing essential products from EU-West-1a so
they can share RIs.
All in all, the ability to modify the AZ and scope makes it less risky to choose a specific AZ
and reserve capacity. A tool with the right Dashboards and Views can be incredibly handy
here for giving you the visibility you need to keep on top of your RI distribution.
AWS offers its users a variety of instances to choose from, each specialized for different
compute, memory and storage roles. Instances are grouped into families and versions
according to each role, then differentiated into individual types according to the size of
the instance. As a note, you cannot modify standard RIs between versions because they
have different hardware. So an m4 RI can’t be modified into an m5 RI.
t2 m1 m2 m3 c1 c3 c4 r3 i2
Any reservation running on a Linux OS can be modified to a different size within the
same instance family. Making those changes comes down to ensuring that when you
make a change, your overall instance size footprint remains the same. Your instance
size footprint is calculated by combining the normalization factors of all your RIs being
modified. The larger the instance size, the higher the normalization factor. The smaller the
instance, the lower the number. By adding these normalization factors together you can
calculate your instance size footprint.
Units 0.5 1 2 4 8 16 32 64
To calculate the instance size footprint of two m5.large instances (normalization factor
of 4) and one m5.2xlarge instance (normalization factor of 8), you would add 4 + 4 + 8
to get a size footprint of 16. You can modify those three reservations into any number
of differently-sized instances within the M5 family, so long as their total instance size
footprint remains equal to 16.
(Source: AWS)
Reservations are priced proportionally to each other, so as long as your instance size
footprint remains the same, RI modifications won’t impact your bill. It’s important to
remember that you can only modify the size of reservations that are running on Linux and
only within the same instance family.
There are a few reservation types that may not be resized because they are the only
available size in a family:
• cc2.8xlarge
• cr1.8xlarge
• hs1.8xlarge
• i3.metal
• t1.micro
If you have Regional Linux RIs with Default tenancy, then you don’t have to worry about
modifying your instance size. With ISF, your RIs will automatically apply to all sizes of an
instance family within the region, even across multiple consolidated accounts. ISF uses the
same normalization factor to figure out your usage footprint, then applies RIs accordingly.
Even though five different sizes are used, the nineteen large
RIs will apply to everything below the dotted line.
You can modify any reservation running on a Linux OS instance between EC2-Classic
and EC2-VPC. As we mentioned before, this is only an option if your account was created
before December 4, 2013. Anything after that will be created in VPC, and all of the
modern EC2 classes are only available in VPC. If you have RIs in the Classic network, then
you can modify them to the VPC network for free.
If you have Standard RIs that aren’t being used and that can’t be made more effective
through modification, you can recoup some — though not all — of their fees by selling
them in the Amazon EC2 Reserved Instance Marketplace. There’s no guarantee that
your reservations will be bought if you put them up for sale, but if you have a significant
number of reservations that won’t save you any money no matter what, then trying to
sell them might be your most cost-effective option. As of this writing (Fall 2018), only
Standard RIs can be sold on the RI Marketplace.
While you do save less compared to Standard RIs, the additional flexibility of Convertible
RIs can be more than worth it.
There are a few core rules that limit how your RI can be converted:
Convertible RIs can only be exchanged for RIs of equal or greater list value. The list value is
computed by multiplying the hourly price by the remaining hours, then combining it with the
upfront price. If the list value of the new RI is the same, then you don’t have to pay anything.
If the list value is more, then you have to pay a true up cost, defined by AWS as, “a prorated
upfront cost of the difference between the Convertible Reserved Instances that you had and
the Convertible Reserved Instances that you receive from the exchange.”
If you’re exchanging multiple RIs, then all of the values are combined to create the list value,
and that’s used in calculating the exchange. Only whole RIs can be bought, so if the value
comes up with a partial RI, then the exchange will be rounded up and you’ll pay a true up cost.
As a note, you can never exchange Convertible RIs for cheaper ones and get the difference
back. If the total value of the new RI is less than the original RI, then AWS automatically gives
you enough of the new ones to make sure the value is the same or higher than the original.
Example:
You have an RI with a list price of $55 that you want to exchange for a new instance type that
has a list price of $20. This would give you 2.75 RIs ($55/$20 = 2.75), so the exchange would be
for 3 new RIs. You would then pay a $5 true up cost.
In addition to exchanging individual RIs, you can also exchange multiple Convertible RIs
and merge them into new Convertible RIs. The process works very much that same as other
exchanges in that you can only merge the RIs into new RIs of equal or greater value.
The part where it gets a little tricky is when you merge one-year and three-year RIs. When you
merge RIs with different term lengths, then the new RI will have a term equal to the longest of
the two terms (so a one-year term and a three-year term will yield a three-year term). The new
expiration date will still be the highest of the two original RIs — even if that date was on the
one-year RI.
So if you’re merging a one-year RI that expires in eight months with a three-year RI that expires
in six months, then the new RI will be a three-year RI that expires in eight months. This is
especially important to remember since the new RI’s value will be based on it having a three-
year term, which can have an effect on your true up costs.
By splitting Convertible RIs, you can keep an RI with the current attributes at a lower level while
exchanging the unused RI portion for a new one. Doing this is actually a two-step process.
First, you have to modify the existing RI to split it into smaller reservations. Then one or more of
those pieces is exchanged to form a new RI.
Splitting a four-instance t2.micro RI into a two-instance t2.micro RI and one m4.xlarge RI. (Source: AWS)
The process is similar if you have a single-instance RI. In this case, the splitting uses the same
instance size footprint rules you use when modifying a Standard RI. Once split, you can
exchange one of the pieces for a whole new RI.
A t2 large RI, with a normalization factor of four, splits into two t2.medium RIs, each with a factor of two.
Then one t2.medium is exchanged for an m3.medium. (Source: AWS)
Reserved Instance
Portfolio Management
Monthly RI Purchasing
If your AWS needs remained exactly the same for an entire year, then you could cover
everything you need with a single RI purchase and just sit back to enjoy the savings. But
it’s never that simple — and you don’t want it to be. Changing infrastructures mean that
your company is evolving, innovating and figuring out how to do more with the cloud.
It can be tempting to sort monthly RI purchasing into individual groups or projects and
tackle them one at a time, but this approach defeats the purpose of monthly purchases.
Look at it this way: If you had twelve teams, and you bought RIs for each team every
month, then it would be a full year before the first team got more RIs. And who knows
how many instances were being billed at On-Demand rates during that time?
Whenever possible, your monthly RI purchases should take a cross-section approach. See
what’s happened with each part of your infrastructure every month, then buy a selection
of RIs that slices across your whole company.
Lifecycle Management
Getting the most from your RIs takes more than just smart purchasing. Your RI portfolio
needs continuous management to make sure you’re getting the most use out of the RIs
you already have. If your RIs aren’t being used, then you need to be able to take action.
There are two good metrics for monitoring RIs: your current RI coverage and your current
RI waste. By modifying current RIs and purchasing new ones, you can get your coverage
high and your waste low. You can monitor these values in a cloud cost management tool
like Cloudability.
You can calculate your reservation coverage by comparing your total EC2 usage hours
with your total hours covered by a reservation. In Cloudability, this value is computed and
graphed for you. Cloud environments need to have a certain degree of elasticity, so many
companies strive for an RI Coverage Rate of 80-90%.
Since it’s free to modify RIs, it’s usually the easiest and fastest action to take first. If you have a
cloud cost management tool like Cloudability, you should pull up the RI Planner, then imple-
ment the recommended modifications to fix underutilized RIs or recommended RI purchases.
We recommend performing this action every month along with making new RI purchases.
RI waste is a fairly straightforward concept: if you have RIs that aren’t being used, then they’re
being wasted. Figuring this out on your own can be a time-consuming task that involves
complicated spreadsheets and error-prone manual processes.
A good cloud cost management tool will show you when you have waste. You’ll know you
have a good tool because it will not only show you when RIs are underutilized, it will also tell
you how much potential savings you’re losing and rank them accordingly. That way you’ll be
able to see exactly which RIs are costing you the most — and how you can get the most bang
for your buck by fixing the problem. At Cloudability, this functionality is built into our Reserved
Instance Portfolio feature.
Nothing can save you money on your AWS bill like Reserved Instances. Whether you’re
already spending millions on RIs or just getting set up to make your first purchase, these RI
basics and strategies will help you get the most from them.
Using these strategies and the Cloudability platform, our customers routinely save at
least 30% on their cloud spend. Interestingly enough, most of them end up investing that
money back into their company through more developers, increased cloud resources or
other investments. In effect, using RIs and Cloudability helps them dramatically increase
their budgets without actually getting any more investment.
Try to keep this in mind while getting buy-in for your RI strategies. If someone pushes
back, ask them what they would do with another third of their budget. Because that’s
what you’ll unlock with your RI strategies and by building a culture of cloud cost
optimization.
We’re not going to lie — it takes a bit of work to get solid RI system in place. But once you
do, the rewards are worth it.
cloudability.com/resources