Any Reservations about AWS Reservations?

August 21 2012 | by Vittaly Tavor Cloud Cost Management, reserved instances

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- Filament.io 0 Flares ×

Much has been written about AWS Reserved Instances, yet there still is a lot of misunderstanding surrounding the topic. A year ago many people did not even appreciate the value of reservations. On the other hand, today even as IT professionals move towards reservations, they often underestimate the complexity involved.

Underscoring these opposing attitudes, are three typical misconceptions I’ve often heard from our customers:

  1. I have a 6-month project, so I can’t commit to Amazon Reserved Instances for a year.
  2. I use reservations but I can calculate the best option with a simple Excel spreadsheet.
  3. I can decide on reservations using one of the existing cloud calculators.

In our previous post the first misconception was shown to be incorrect. In this post we will show how the latter two are as well.

Reserved Instances – A Brief Review

“Reserved Instances” is an Amazon pricing model. It has nothing to do with the actual launched instances – just with the way Amazon calculates the cost.

With Reserved Instances you make a one-time fee and then you get a discount on the hourly charges of the instance(s).
Reserved Instances are bound to a specific region, instance type, availability zone, platform, VPC and tenancy.

Additionally the reservation can be for a term of 1 or 3 years and you may select from 3 Offering Types or flavors of of Reserved Instances:

  • Light Utilization
  • Medium Utilization
  • Heavy Utilization

Light and Medium offering types are similar. They differ in the one-time fee and the hourly rate. For Light reservations the one-time fee is lower, the hourly fee is higher and the annual saving is lower.

Heavy reservations are a bit different – it’s actually a subscription service and not a pay-as-you-go model. Unlike Light and Medium, with Heavy reservations you are charged the hourly rates regardless of whether the instance is running or not.

Select AWS customers (those with a significant annual spend) may be presented with an additional offering type choice: “Fixed Price”. With “Fixed Price” reservations, the one-time fee actually covers the annual cost. There’s no additional hourly fee. Fixed Price reservation may save 5-7% over the Heavy reservation, but you need to pay the entire amount up-front.

Is Reserved Instance Pricing Always the Same?

Actually the price behavior for different combinations of Reserved Instance region/availability zone/instance type/platform is radically different. Not only the price itself, but also the decision whether the reservation is worthwhile or which offering type to select depends heavily on the aforementioned parameters.

So When Should Reservations Be Used?

In simple cases, where a fixed number of instances are running constantly, the decision is obvious. However, in most of the real-world deployments – where usage and utilization can fluctuate wildly – the selection of an optimal reservation strategy requires calculations based on data not readily available from Amazon.

Another major difficulty is that looking at specific instances (as existing tools do) is not very helpful. Rather, the number of concurrent instances and percentage of runtime for each combination of platform/availability zone/instance type/VPC/tenancy must be analyzed for a comprehensive assessment and recommendation.

Comparing Break-Even Point for Different Reserved Instances

The graph below shows the behavior of 3 offering types compared to on-demand for an m1.large Linux instance is us-east-1 region over a term of 1 year.

1 ResRI-Comparison

The blue line is the on-demand cost over time with the other lines representing different reservation offering types. In this specific case, the graph shows that for an instance running up to ~19% of the time, on-demand is the most economical.

From ~19% up to ~69% the most economical offering is Light reservation, then there’s a very short interval where medium is best, and from ~80% and on, heavy is best.

However, although not the most economical, if you do make a heavy reservation, it reaches break-even (compared to on-demand) after running less than 50% of the time. So if you have an instance statistically running more than 50% of time, then any reservation type is better than on-demand!

In our previous post we examined how the lock-in period for each instance is really much shorter than the actual term. In this post we will look at this graph from a different angle.

How to Properly Calculate Optimal Pricing Plans

Calculating optimal reservation blends, based on the individual instances is completely incorrect. For example, you may have multiple instances running just short periods of time, which on their own are most economical as On-Demand. However, when considering their cumulative runtime, which is the correct way to look at it, reservations are fully justified.

Additionally, you can’t make calculations based on AWS usage reports (or AWS billing reports) as these reports are missing availability zone information. For exactly the same reason the cost calculators that do not monitor your actual deployment are inadequate.

The only real way to calculate the best-fit policy is to split the running instances into groups of platform/instance type/availability zone/VPC/tenancy, and then for each group, analyze the number of concurrent instances over time.

Our algorithm calculates the runtime percentage of instance groups, and then distributes the reservations from heavy to light, as appropriate, based on the offering type break-even point.

Let’s examine a group of m1.large Unix instances in availability zone us-east-1b without VPC and with a default tenancy. The ROI points for the m1.large Linux instances in us-east-1 region above are shown as follows:
2 m1largeGroup

Assume that the instances are launching and terminating all the time and no single instance was running for longer than a few days. However, the following distribution of instances belonging to that group was observed during the last month:

  • 100% of time there was at least 1 running instance
  • 94% of time there were at least 2 running instances
  • 72% of time there were at least 3 running instances
  • 50% of time there were at least 4 running instances
  • 23% of time there were at least 5 running instances
  • 15% of time there were at least 6 running instances
  • 11% of time there were at least 8 running instances

Other cloud monitoring solutions will be unable to make any meaningful recommendation, as they are looking at single instances. Our algorithm however, will recommend as follows:

  1. As statistically there were 2 instances over 82.4% of time (the Heavy reservation ROI point) we recommend 2 Heavy reservations.
  2. Statistically there were 3 instances over 69.2% (the ROI point of Medium reservation). As 2 of these were also above the Heavy reservation ROI point, and were accounted for by our heavy reservation recommendation, we’d recommend making 1 Medium reservation.
  3. Statistically, 5 instances were running more than 19.2% of time (the Light reservation ROI point). Of these, 3 were already accounted for by the previous recommendations. Therefore we recommend only 2 Light reservations.
  4. The times in which there are more than 5 concurrent instances are less frequent than 19.2%, so there’s no economic benefit in making additional reservations for these times and instead recommend using on-demand for these.

So the final recommendation will be:

  • 2 Heavy reservations
  • 1 Medium reservation
  • 2 Light reservations

As mentioned before, this type of calculation is done for every user’s unique combination of platform/instance type/availability zone/VPC/tenancy.

Here’s an example of a recommended deployment from one of our clients:
3 RecommendedDeployment

As well as the details of a specific recommendation:
4 DetailsofRecommendation

Coming Soon

Our next blog posts will cover how to plan for optimal pricing in situations where there are internal commitment policies and other constraints, as well as explore real customer use cases and applications.

To discover how you can begin optimizing your cloud consumption – take a free test spin now!

Connect with us
Sign up for our newsletter
  • альтернативный текст
  • альтернативный текст
  • альтернативный текст
  • альтернативный текст

Login

SSO Login

Forgot Password?

No account yet? Register.

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- Filament.io 0 Flares ×