How Much Does Azure Analysis Services Actually Cost?

It might seem strange to write a blog post on how much Azure Analysis Services costs when there is a page on the Microsoft site that very clearly lists all of the SKUs and how much they cost per hour or per month in any currency and Azure region you choose:

The prices you see here are somewhat misleading though. They’re not wrong, but they do not challenge the assumption that you will  use Azure Analysis Services in the same way as an on-premises instance and therefore they allow you to make further, incorrect assumptions about cost. A lot of my customers look at the monthly cost and assume that’s what they will actually be paying monthly – and more often than not come to the conclusion that Azure Analysis Services is too expensive for them. In fact the situation is a lot more complex and Azure Analysis Services (especially at the enterprise level) might end up being cheaper than you think. Let me explain why.

The workload of any Analysis Services instance, whether on-premises or in Azure, varies a lot. For example:

  • It will be busy during office hours while users are running queries but much quieter at night when most users have gone home
  • Similarly, it will be busy during the week when most users are working and much quieter on weekends and public holidays
  • It will be busy at certain times, such as month-ends or Black Friday, when more reports need to be run
  • It will be much busier (often with both CPU and memory usage at their peak) when processing is taking place

When you are planning an on-premises deployment of Analysis Services you need to specify your hardware and licensing so as to be able to handle these periods of high usage, even if for most of the time usage is a lot lower. This means that enterprise-level deployments of Analysis Services can be expensive because you need servers with a large number of cores and a lot of RAM and you may also need to use network load-balancing to scale out over several servers.

On the other hand Azure Analysis Services is able to scale up and scale out on demand, and you only pay for what you use. Scaling up means moving to a higher performance level (ie a SKU) within a service tier, or even moving up a service tier. Scaling out means adding replicas of your existing Azure AS instance and database.

Broadly speaking you need to scale up in two scenarios:

  • To handle the need for more memory and more QPUs while you are processing
  • To handle increased data volumes, either as a result of new tables being added to the model or because the size of existing tables has increased over time

You need to scale out when:

  • You need to process during times when other users are running queries, to ensure that query performance is not affected
  • You need to handle an increased number of concurrent users running queries

Bill Anton has an excellent blog post covering this question in a lot more detail here:

One other thing to point out is that if you pause an instance of Azure Analysis Services you pay absolutely nothing.

What does this mean for the cost of Azure Analysis Services? Basically, if you’re taking advantage of these features you won’t pay one of the monthly prices quoted on the pricing page linked to at the top of this post. Instead you may do things like:

  • Scale up for one hour every day when you need to process your SSAS database, just to get the extra memory and QPUs needed, then scale down when processing has finished
  • Scale out only on certain days, or certain times of day, to handle increased numbers of users
  • Pause your instance when you are sure that no-one needs to run queries

How do you then calculate the likely cost? For my Azure Analysis Services precon at SQLBits a few months ago I built an Excel workbook that shows how to go about this. First, there is a table with the hourly costs for S-level instances in GBP:


Then there is a table with one cell for every hour of every day of the week, with the performance level required for that hour. In this example most of the time an S1 instance is required except for at midnight every night where processing is taking place and an S2 is needed. For four hours on Sunday morning the instance is paused.


Next there is a similar table showing the number of scale-out replicas needed for each hour of each day. In this case scale-out is needed for four hours of the day, Monday to Friday, to handle a larger number of concurrent users:


Next, the data from these three tables is brought together to calculate the cost per hour for each day of the week:


Finally, for a given month the actual cost per day can be calculated (which of course varies by the number of weekdays, weekends and maybe also public holidays), resulting in the true monthly cost:


In this example the monthly cost for January 2018 is £1287.56, which is only slightly more than the £1104.48 you would pay to have an S1 instance for a whole month. You can download a copy of the workbook here.

In summary, my point here is that pricing an implementation of Azure Analysis Services is complex because of its flexibility. I am not saying that Azure Analysis Services is cheap, or cheaper than using Analysis Services on a VM in Azure or on premises – that’s a subject for a completely separate discussion. Hopefully, though, this post gives you a better idea of how much you might pay if you do use Azure Analysis Services for a project.

UPDATE 10th June 2017: the number of query replicas for scale-out has been limited by Azure region, so choosing the right Azure region is very important if you do need to scale out. The documentation is here:

24 responses

  1. A great article Chris.
    On those occasions I was researching whether the cost of having a specific DW for PowerBi on Azure would be worth it, but I got to the first point you commented on.
    On the Microsoft website, the price is high.
    With this I install SQL locally.
    Tip for an upcoming article, talking about DW on Azure. That is, it would only work on data loads.

  2. Great article Chris. One thing you aren’t taking into account, however, is running Analysis Services as IaaS (with or without a Reserved Instance). IaaS can bring you the primary benefits you speak to of elastic scale and paying for what you use. The regular SQL license + IaaS costs can be significantly less expensive than the Azure Analysis Services PaaS offering. I think you’d find if you run the numbers, you’ll see that IaaS + SQL license gives a much more cost effective offering. For example….SQL license is free for non-Prod IaaS via Developer Edition, but only discounted in a Dev/Test subscription for PaaS.

  3. Hi Chris

    I think where Azure Analysis Services pricing falls down is in the size of tabular model you can host. Lets say I have a 201 GB Tabular model, I’m assuming that this pushes me on to the S9 tier at £15.48 per hour, or over £10,000 per month. That’s before any scale out. Ideally Microsoft would separate Compute and Storage (memory) pricing, but I’m guessing Tabular, or the servers this is running on doesn’t support that model.

    Cheers – Adam

    • I guess the problem is that, because of the way the engine stores data, the more data you have the more compute you need to be able to query it quickly so the two have to go hand-in-hand

  4. Hi Chris, how does the cost behave, when I’m turning off the instance at nigh or during the weekends? How fast can I recover from that planned downtime?

    • If you pause the service you pay nothing. Startup time may vary but in my experience it’s rarely more than a few minutes and usually pretty fast.

      • But when you pause or turn down, do you not need to load the model again in memory (trigger a full refresh) or is the model temporarily cached on disk and just put back in memory

      • But at the moment the server is resumed after a pause, does the model then need to be fully processed again or are existing model cached on disk and then put back into memory on resuming?

      • Interesting. I think I’m just trying to understand from Microsoft perspective what this means (to understand on a technical level better how it works).

        If you say that no processing is needed, then this means that the memory stays occupied, but you are no longer paying for it. Which from a Ms perspective can’t be sustainable. Therefore it must be that the memory is at leased cached to disc upon pauzing and then restored right?

        Also if you have 100gb of models stored in an AS instance, and you reduce the AS instance to 50gb memory what will happen? Will this throw errors or push some of your models out of memory? Apologies if this is a bit Out of topic versus your original post, but this helps me to understand better the impact of scaling in and out

  5. Pingback: Power BI BlackJack, World Cup 2018 and Power BI updates... (June 11, 2018) | Guy in a Cube

  6. What about transfer costs, does it cost to load up or query a TM? If so, what are the rates? How do we figure out just how much data is going in/coming out?

  7. Hi Chris,

    I am not able to reach the calculation template (Excel). Could I please get a copy from you, Chris?


  8. Pingback: Kalkulator Analysis Services – Opowieści o SQLu, BI, życiu i innych używkach

  9. A great article Chris. I downloaded a copy of the workbook and researching whether the cost of having a specific DW on Azure would be worth it and what will be final cost to the company.

Leave a Reply to Amr Guenena Cancel reply

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

%d bloggers like this: