AWS EC2 instance pricing always goes down – or does it? Explaining EC2 pricing, and debunking cloud pricing myths.

EC2 instance pricing A beginner’s guide (part 2)

AWS’ pioneering Elastic Compute Cloud, or EC2, has very complex pricing.  This EC2 instance pricing guide is intended to help cloud buyer’s make sense of the major topics.

In Part 1 of our Beginner’s Guide to EC2 pricing, we covered:

  • Interruptibility – On-demand “OD” vs Spot Instances
  • Instance Family – m3 vs r3 vs c3
  • Instance Size – m3.medium vs m3.large vs m3.xlarge

In Part 2, we cover:

  • Price Plans – On-demand vs Committed (i.e. Reserved Instances , or “RIs”)
  • Finance Choices – Nothing Upfront, Partial Upfront or All Upfront
  • Optionality – options to burst CPU (t2 family), options to switch instance family for an RI (convertible RIs)

Price Plans: On Demand vs Committed

Committed = Cheaper, but less flexible, so higher risk.

On-Demand = Flexible, low risk, but expensive.

Imagine if you had invested tens of billions of dollars in datacenter buildings, and further billions fitting those data centers out with the latest compute, storage and networking hardware, all of which would be obsolete within a few short years.  Selling all that cloud capacity by the hour at a high price is great, so long as it persists, but would you not sleep more easily at night, if you had sold enough in advance, at fixed price, to be able to cover the running costs?  That is why AWS and other cloud providers like Microsoft Azure and Google Compute Platform offer discounts for committed future spend, and for committed future usage.  Those discounts can be as much as 75% in certain cases, but rules of thumb are dangerous, as the discounts on offer change over time, and are different depending upon both the nature of what is being committed to, and how specifically it is defined. Furthermore, the pricing is different depending on the term of the commitment (longer is cheaper) and in some cases the rate of increase of committed future spend.  As a final word of warning, cloud marketeers tend to cherry-pick the highest reference pricing, and the lowest committed pricing, if necessary for the most obscure cloud resource imaginable, so that they can quote the biggest headline “saving”…much as I have done with the eye-catching 75% above…30% is the more commonly achieved discount to have in mind, at time of writing.

Committed Use discounts are offered under various names.  The most self-explanatory, is the “Committed Usage Discount” from Google Compute Platform.  Amazon Web Services, the industry pioneer, also pioneered the committed use discount, but called it the Reserved Instance, despite the fact that it is not really an instance, but rather a discount voucher allowing an on-demand instance to be charged at a fixed, low price.  Microsoft recently launched Reserved Virtual Machine Instances, abbreviated to RIs, presumably to ensure that anyone typing “RI” into a search engine will find Microsoft Azure committed use pricing to compare against Amazon’s Reserved Instances.  At their 2014 launch, Google’s “sustained usage discounts” were compared by many with AWS’ Reserved Instances, but this was a dubious comparison, as no commitment was required, so a fairer comparison was as a variant for on-demand pricing.

Analysis of the discount offered for any given term, volume and specificity of commitment is a large enough subject to fill multiple blog posts.  However, below is a graph showing the pricing for c1.medium in US-East-1, over time, for on-demand, 1 year Partial Upfront RIs and 3 year Partial Upfront RIs.

Source: Pricing Insights app, by Strategic Blue. Click image to request access

Finance Choices

Prepaid = Seems cheaper, but only if your cost of finance is low enough

Some cloud providers keep things simple, and equate commitment with prepayment.  However, Amazon Web Services allows users to choose the level of prepayment associated with a given commitment, offering 1) All Upfront, 2) Partial Upfront and 3) Nothing Upfront.  As you’d expect, the more you prepay, the deeper the discount.  However, as a rule of thumb (which is broken in various cases), the majority of the discount is offered for just paying Partial Upfront, and more than doubling the upfront payment to access the All Upfront discount is rarely worthwhile for anyone with a non-zero cost of finance.  The reason for this is likely that Amazon itself has a very low cost of finance, i.e. it can borrow money at very low interest rates, so the reason for offering a deeper discount for Partial Upfront Reserved Instances than for an otherwise identical Nothing Upfront Reserved Instance, is that the partial prepayment is sufficient to satisfy AWS that the commitment to future usage is real.

Optionality

Invest in Options and monetise them to manage risk cost-effectively

For those of you who may, quite reasonably, be somewhat bamboozled by the complexity of cloud pricing, take comfort that it used to be more complicated (in some ways).  The original AWS EC2 Reserved Instance was not what is came to be called a “Heavy Utilisation” Reserved Instance, but was rather a “Medium Utilisation” Reserved Instance.  Together with the “Light Utilisation” Reserved Instance that was introduced at the same time as the Heavy Utilisation RI, the Medium Utilisation RI was not a firm commitment to use (and hence pay for) future usage at a fixed price.  Instead, it was a strip of options, one option for each hour of the 12 month or 36 month term.  The buyer of a Light or Medium Utilisation Reserved Instance would pay a “one-time fee”, effectively as an “option premium”, for the right, but not the obligation, to buy an on-demand instance of matching instance type, operating system and availability zone, at the pre-agreed fixed hourly price (or “option strike price”), during each hour of the term.  If the option was not exercised (because no matching instance was turned on), then the owner of the Light or Medium Reserved Instance did not pay the hourly fee.  In contrast, for Heavy Utilisation Reserved Instances, the hourly fee is paid whether or not there is matching instance usage, i.e. it is what is known as a “forward contract”.

Amazon stopped selling Light and Medium Utilisation Reserved Instances on 2nd February 2015, and in hindsight, our observations in this blog post were a clear predictor of it.  In essence, AWS were offering Light Utilisation Reserved Instances for sale with an hourly price (i.e. the strike price) set above the prevailing on-demand price.  Yes, that’s right, you could pay an upfront premium for the right, but not the obligation, to pay more than the prevailing price.  In those days of price backwardation, i.e. where prices were always expected to fall, selling “out of the money options” seemed like an offering no-one was likely to take up…and this was clearly the point.

Graphic from a 2014 post highlighting 137 strangely priced Light Utilisation Reserved Instances.

Today, the “options” available to buy from Amazon have a different type of optionality.  Whereas in the past, and still for anything other than a regular Linux instance, it is necessary for usage to match a Reserved Instance by the exact combination of instance type, operating system, availability zone and tenancy, some of this specificity has now been relaxed.  Exact details of this is changing regularly at the moment, but the first flexibility offered is for “Regional RIs“…these no longer require usage to be in a matching availability zone, provided the usage is in the right region.  i.e. the user now has the option to use any Availability Zone in the specified Region, and the usage will match off against the commitment.

Next came “Size Flexibility“.  In the past, not only did the operating system, tenancy and location (either availability zone, or just the region, for Regional RIs) of usage have to match that of the Reserved Instance, but the size of the instance and the instance family also had to match.  Now, for regular Linux instances, Reserved Instances are “size flexible” within the specified instance family, so whilst you must match the instance family (i.e. the m1, m2, m3, m4, r3, r4, i2 etc), you do NOT have to match the size (i.e. the small, medium, large, xlarge, 2xlarge etc).  AWS will automatically prorate the benefit based on the relative size of what is used, compared to what has been committed by buying the Reserved Instance.

At around the same time, a new class of Reserved Instances was launched – the Convertible Reserved Instance.  These allowed the owner of a Convertible Reserved Instance to modify the instance family, paying any extra funds required based on the prevailing pricing.  This was an extension of the prior ability for a user to request to modify Linux instances, such that the ability was both broader, and an actual contractual right.  The issue is in the small print, and the pricing, in this case, however.  Convertible Reserved Instances are offered at much less of a discount than non-convertible Reserved Instances, and cannot be marketed for sale in the Reserved Instance Marketplace.  Finally, in contrast to Size Flexibility and Regional RIs, Convertible RIs require the user to really be paying close attention to their utilization, as manual intervention is required in order to “monetize” the additional flexibility that is being paid for through the reduced discount, and request the necessary modification as soon as usage patterns change.

Alas, investing in cloud options is not as easy as it once was.  Before, there was a strong incentive to buy a certain number of heavy utilization Reserved Instances and then “top up” with some medium or even light utilization Reserved Instances as “options” that you could choose not to exercise if plans changed.  Today, the sophisticated cloud buyer must pursue a more sophisticated strategy, but that is beyond the scope of this “Beginner’s” Guide to EC2 Pricing.

In this Part 2 of our Beginner’s Guide to EC2 pricing, we’ve covered:

  • Price Plans – On-demand vs Committed (i.e. Reserved Instances , or “RIs”)
  • Finance Choices – Nothing Upfront, Partial Upfront or All Upfront
  • Optionality – options to burst CPU (t2 family), options to switch instance family for an RI (convertible RIs)

In Part 1, we also covered:

  • Interruptibility – On-demand “OD” vs Spot Instances
  • Instance Family – m3 vs r3 vs c3
  • Instance Size – m3.medium vs m3.large vs m3.xlarge

If you’d like access to our historical AWS pricing, using the app we have built to generate the charts in this blog post, please get in touch.