This is probably the single most important question to anyone who is considering following this series of guides. If it’s not cost effective, what’s the point?
Before we start, please know that I am no Azure cost “expert.” I can point you in the right direction and provide examples, but you need to consult with Microsoft and your internal Azure teams for all billing questions and estimates. While some of the information was provided to me by Microsoft Support, I would not take even that as truth. Consult them directly! As always, see the disclaimer.
In this section we will cover…
- The Chicken and the Egg – the issue with predicting cost
- Cost Sources
- So, how do you predict the cost?
- A Cost Example
- An Ingestion Cost Example
- A Function Cost Example
- Application Insights Cost Prediction
- Event Hub Cost Prediction
The Chicken and the Egg:
Unfortunately, cost is the most annoying question to me. I dread this topic so much I considered writing this blog last. That’s not because it’s a bad question, but because it’s an all-around headache to answer. It’s a serious case of “chicken or the egg.” Except it’s more like “Chicken or the egg, or the thought of the egg, or the thought of the Chicken.”
The cost all depends on what you want to collect, the size of that data, how often you want to collect it, and how many devices you want to collect it from. You have to know those answers before you can make a price prediction, and that means you have to invest time in understanding this solution first.
Additionally, Azure pricing is a headache of a topic. Sometimes it costs money to move data, sometimes it doesn’t. That cost often changes depending on where the data is going (Both in terms of the region or service). Some things allow a certain amount of X for free, and then charge at varying rates beyond that. Some things also change in rate depending on how often/frequently you call to them, or how much at once. Sometimes it makes more sense for a pay-as-you-go plan, other times you’re a 10 million employee company who can use a 1,000 GB a month plan to save 10% compared to pay-as-you-go. Like I said, it’s a headache. For that reason, the following are just examples and again, consult Microsoft directly.
What I can say briefly is that this solution itself has proved to be very cheap in my experience. As some folks at Microsoft I was showing this to have put it, this solution may as well be free.
But obviously, dear reader, you don’t want to (and shouldn’t) trust someone on the internet with a blog simply saying, “it’s cheap.”
So, how do you predict the cost? Before we can answer that, we need to first cover what the actual cost sources themselves are.
Cost Sources:
This is, believe it or not, not an exhaustive list of everything that may potentially have a charge. These are just the major sources.
- Log Analytics Ingestion
You will pay a fee for every GB ingested into the system. For instance, in the East US region, that price is currently $2.30 per GB. Your cost can be found here under the Analytics Logs section. - Log Analytics Storage
As previously mentioned, you get 30 days of free storage. If you want to store data longer, you can, but it will cost you. Information for this is also here. - Event Hubs
If you plan to stream to an Event Hub such that you can export data to external sources, that does have a cost. It’s fairly cheap though, a whopping $0.10 per GB in East US. See the “Log Data Export” header here. - Function App
The Function App Pricing is a pain. We will discuss it in detail below but, for quick reference, the pricing information is here. - Application Insights
Application Insights is the logging that runs on top of the Function App. This is technically on the same Log Analytics pricing page but it is not really a predictable value. More on this later. And, importantly, you can shut it off to save money as you really only need it when troubleshooting. Details on how to do so will be in the Function App part of the series. - Storage Account
There is a storage account associated with the Function App but as it mainly stores the whopping KBs of configuration settings and scripts. In a prod environment capable of racking up a few hundred dollars in Log Analytics Ingestion cost per month, this cost doesn’t even exceed a dollar per month. - Proactive Remediations
This does have a licensing cost but it’s likely you already have this license if you are interested in this level of data.
So, how do you predict the cost?
There are two methods you can follow.
The first method is to achieve a serious understanding of this solution, determine what you want to collect, determine how often you want to collect it, generate some sample data, do some math, talk to your Azure specialist, talk to your Microsoft account reps about what plans you are on and make sense given the data rates, use the above calculators, and you will receive “a number.” If you successfully achieved everything above, it will probably be pretty accurate or at least ballpark it for you. That said, you are likely to find no way to estimate things like Application Insights that are just a mystery, and finding all the above answers is a nightmare.
The second method is to achieve a serious understanding of this, set it up, and deploy it to 1% for a week or two. Then, just scale up the cost to 10% linearly. If acceptable, deploy to 10% for a few weeks, and scale up the cost again. At that point you can discuss with Microsoft reps which cost plans make the most sense using the real numbers you now have.
To make that option even easier, the workbooks I build come with cost prediction and tracking tools to automate the scaling to just a few clicks and numbers.
Again though, some things (function app executions for example) have a cost which only charges you above a certain level of calls per month. So, linear math will not be 100% accurate.
Option two might not sound appealing to you at first but, let me put it this way. Option one is a series of estimates stacked on top of each other. Option two is just scaling up a real number you have generating through running the thing on a limited audience. Pick your poison.
A Cost Example:
Since I am sure some are still curious, I will now do my best to walk through a full cost example.
One of the first items to be released will be a Windows 365 (Cloud PC) specific workbook and set of data collection scripts. This article is not a demo of that collector/workbook and how cool it is, so the following explanation may be difficult to understand just how much you can do with this data. Try and keep your focus on the cost aspect more than the useability at first glance.
An Ingestion Cost Example:
Here is what one script collects.
- Computer Name
- Managed Device Name
- Managed Device ID
- Script Version
- Network Adapters
– Network Interface Description
– Network Profile Name
– IPV4 Address
– Interface Alias
– IPv4 Gateway
– Mac Address - And the following information for Microsoft Teams and the WebRTC service (two apps)
– App Name
– Version
– Install Date
– Publisher
– Uninstall String
– Uninstall Path
This in total (with one network adapter) makes a 5 KB file when ran on my machine.
Using pay-as-you-go, Log Analytics is going to charge me $2.30 USD per GB to ingest into the US East region. That information can be found here or more so here.
I only care to pull this data from devices every 4 hours. Those devices are all Cloud PCs with 24-hour up time. That means each device will upload 5 KB of data 6 times a day. That’s 30 KB a day, or 903 KB a month. If we have 10,000 Cloud PC’s, that’s 9,300,000 KB a month.
That’s 9.3 GB of data a month, or about $21 USD, to collect that information from 10,000 devices. That’s $00.0021 per day, per device. Hence, this is seen as basically free. But, as we discussed, Log Analytics ingestion is not the only cost.
A Function Cost Example:
Now, in order to upload this data, we need to use our Function. Function App’s have a cost and I hate this topic. I hate this topic because I had a ticket that went for months with Microsoft Azure Support trying to determine how to make price predictions for this. The answers they gave us on how to collect these various metrics for the prediction was to look at an existing and deployed Function App, which defeats the purpose of a prediction making calculator in my opinion.
The pricing information can be found here, and the calculator can be found here. I will plug into my calculator the East US region and a Consumption plan.
Below I will give a rough overview of how you find these values, but this is not meant to be an exhaustive guide on doing this yourself.
Finding Memory Size:
Per Microsoft Azure Support, this is the best way to figure out your Memory Size in Bytes. Unfortunately, this method again requires a production Function App to already be deployed and in use, along with enabling Application Insights.
I used this with a 7-day time range to get a 7-day average. This is from a function app supporting roughly 7000 devices with 4.5 million calls a month. This returned a byte count of
1,072,889,981.489.
performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value
| summarize avg(value)
Now, the calculator isn’t labeled annoyingly but if you look into this, Function Apps work on MB of memory. Translate that from Bytes to MegaBytes and you get 1072. I went down a notch to 1024 as this seemed to produce more accurate estimates when comparing to the real price of my Function.
Note: For those who are curious and familiar with Function Apps already, this value is not at all the 7-day average the Memory Working Set on the Function App overview shows. That says only 244 MB. What is that then and how is it useful? I have no idea.
Execution Time:
The way Microsoft support explained to get execution time is to again go into Application Insights, Overview, change the time range to a better range (EX: 7 days), and look at the average value on the Server Response Time graph.
I will be using an execution time of 780 milliseconds from the same function.
Executions Per Month:
Executions per month is fairly straightforward. Falling back on my example before, 10,000 devices uploading data 6 times a day. That’s about 1,860,000 executions a month.
Microsoft Support also gave me this method. Go into Application Insights overview, adjust to a suitable time range like 30 or 7 days, and look at the server requests graph and see the total under it. You can then do the math to range that out to a month.
Plugging it all into the calculator:
And together that makes a monthly estimate of $19.91 USD a month. It’s worth noting you get the first 1,000,000 executions per month for free*, so the charge only came from the following 860,000.
*There is also a serious rate concern here due to Proactive Remediations. If you tell 10,000 devices to run something hourly, odds are they will all run it in the first 10 minutes or so of the hour causing a massive utilization spike. This can have a serious impact on cost. You can read more about this topic here but beyond that will need to consult Microsoft. I use their (MSendpointMGR’s) workaround, and that’s the extent of my knowledge on that concern.
A real-life check:
I have a real Function App that supports around 7000 devices making around 4.5 million requests per month using that same execution time and memory size. According to the calculator it should cost around $50 USD per month. So far that seems pretty accurate as Azure reports roughly 45$ in the past 30 days.
Additional Function App Cost Information:
Microsoft Support did confirm that the JSON file movement to and from the Function App is not billed. So no, you don’t get double charged on each JSON because it has to pass through the Function App before then hitting Log Analytics.
Again, Function Apps do have storage accounts. I have yet to see one of these cost more than $10 a month, if even $5.
Application Insights Cost Prediction:
I have no idea. This is a mini Log Analytics Workspace charging you to ingest analytical data about the inner workings and running’s of the Function App. This can easily cost 4-5x the cost of the Function App it’s supporting. For instance, the $45 function app I mentioned earlier has racked up a $205 Application Insights Charge in the past 30 days. The less than one cent Function App I have has racked up a 4 cent Application Insights charge.
The math behind this is nothing short of a mystery to me, but it’s a GREAT example of why paying to ingest everything under the sun is a silly waste of money – and that’s exactly why this solution I am writing about exists.
However, Application Insights is an invaluable tool and you should set it up, but you should probably turn it off when you don’t actually need that data. See this: Saving a Buck by Temporarily Disabling Application Insights – Getting the Most Out of Azure (azuretothemax.net)
Event Hub Cost Prediction:
I am leaving the old information from the original series below but, to make faster work of this, see the header “Log Data Export” here. East US is $0.10 per GB. I seemed to previously indicate there was a cost per GB as well as total event count, but the pricing information makes no mention of the count of events having an impact.
Original info:
I’ll need more time to gather data on this however, so far this seems extremely cheap. Cost information can be found here.
Looking at my Log Analytics workspace that has cost roughly $24 in the past 7 days, or roughly $102 a month, or roughly 44GB a month. The corresponding Event Hub where all events (All 44GB) are forwarded to has only cost $2.25 in the past 7 days, or roughly $10 a month.
I looked at both 7-day and 30-day ranges just to be safe, and they matched up. So, these seem rather cheap.
But, I noticed part of this cost is event count and not just size. My 44GB is actually made up of a relatively small event count, so that could explain why this option is so cheap for us.
I said it once and I will say it again, consult Microsoft.
Conclusion:
I hope that this information gives you more confidence that this is not a relatively expensive solution and that it can make sense from a cost perspective alone.
However, once again, I am no Azure cost “expert.” I hope this got you pointed in the right direction but, you need to consult with Microsoft and your internal Azure teams for all billing questions and estimates. While some of the information was provided to me by Microsoft Support, I would not take even that as turth. Consult them directly! As always, see the disclaimer.
The Next Steps:
See the index page for all new updates!
Log Analytics Index – Getting the Most Out of Azure (azuretothemax.net)
Disclaimer
The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.
You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time.
It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.
The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/
Azure to the Max 