top of page

Azure regional pricing models - the devil is in the details.

Talking to Azure customers on a daily basis, it is clear to us that the complexity of pricing models prevents customers from taking real advantage of the options available to them.

I'd like to shed some light on that. Let's start with a couple of examples. I have chosen one of the most commonly used machine families in Azure Dv3 and two of the biggest regions US East & EU West. Here is the pricing for 3yr reservations, saving plans, and spot pricing. Here are the results:

Azure RI pricing

Let’s take a closer look. For clarity, I have created a table based on the Azure pricing above. I normalized the data to the $100US equivalent. In this, case the numbers below represent both dollars ($) and percentages (%)

Savings table:

Azure RI savings

If you are not very familiar with the various pricing plans, I recommend you read the “Pricing models” section below first.

A few quick conclusions:

  1. If you can run on spot instances and have no region limitations - go west! West Europe. To clarify, for the same spot machine for every dollar you will pay in EU West. you will pay $2.73 in US East. Calculated by (100-70)/(100-89)=30/11=2.73.

  2. RIs can give you a double discount in comparison to SPs. In the US East region for each dollar you pay for the same machine when covered by an RI, you will pay $2.03 if covered by a SP.

  3. The matrix is quite big. Every family has different discount values per region. Discounts also change over time.

  4. The base on-demand price itself varies between regions. The same machine will cost you 25% more on demand in EU West than in US East. And still, the spot price, in EU West will be 46% of that same machine in US East. This is also true between regions in the same continent and even physically “close” regions.

On purpose, I did not choose the most extreme examples, nor the ones with the smallest differences between pricing models.

A few clarifications:

  1. Spot prices are way more fluid than the other pricing models and are related to supply and demand.

  2. Not all families are eligible for spot pricing.

  3. Reservations exist for 1, 3, or 5 years. Not all families have all periods.

  4. Reservations exist for products that are not VMs

  5. VM reservation can cover products that run on VMs like AKS.

A few quick recommendations.

  1. Choose your pricing model wisely. I guess you saw that one coming 🙂

  2. Plan your application to take advantage of spot instances. It can have a major impact on cost.

  3. Data gravity is a big issue. If you want to take advantage of different pricing models, you need to figure out your data architecture strategy ahead of time.

  4. Do not take the console recommendations. It uses a very simple calculation that does not factor in risk, as the risk is yours and not the recommenders. It also does not consider additional discounts that you might have from your CSP or other programs.

  5. Assume changes in consumption in both directions even in systems that look like they are headed in one direction. E.g. your system might be “ever-growing” and still a price discount or a technology change will reduce the dollar value of your consumption.

  6. Do not treat RIs as more rigid than saving plans, they are simply a different kind of rigid.

  7. Automation is key.

Pricing models

A quick explanation for those less familiar with Azure pricing models.

  1. On-Demand: Pay for what is running.

  2. Reserved instances: Commit to constant usage and get a discount. The longer the commitment, the bigger the discount. Pay whether you are consuming or not. The commitment is usually per family type.

  3. Saving plans: Similar to reservations with the following changes:

    1. An hourly commitment, let’s say for example $10/hour.

    2. Saving plans will cover multiple resource types and try to get you the max value discount possible.

  4. Spot: Excess capacity sold at attractive prices with the possibility to evict your VM at short notice.

16 views0 comments


bottom of page