Consumption Plan Cost Billing FAQ
Important Note
An up to date version of this content is now part of the official documentation:
https://docs.microsoft.com/en-us/azure/azure-functions/functions-consumption-costs
Users generally host Azure Functions in one of three ways, each with their own pricing model:
- On a dedicated App Service plan (basic tier or higher)
- On the consumption plan
- On an elastic premium plan
For a dedicated App Service plan see the link above. For consumption and elastic premium see here.
This FAQ is focused on the consumption plan.
Yes, there is a free grant on a per subscription basis. See the pricing page for the details.
A Function App needs an associated general purpose storage account for normal operation and to get a rich monitoring experience for that Function App you'll want an associated App Insights instance. By default, the Azure Portal will create both of these resources when you create a new Function App, so you should expect to see some cost generated by these resources. Also keep in mind that Azure's networking might be applicable.
The execution "cost" of a single function execution is calculated by combining its memory usage with its execution time. A function that runs for longer costs more, as does a function that consumes more memory. If the amount of memory used by the function stays constant, then it's a simple multiplication - e.g if your function consumed 0.5 GB for 3 seconds, then the cost is 0.5GB * 3s = 1.5 GB-seconds.
Once you take into account that memory usage can change over time, the calculation is best described as the integral of memory usage over time. The system does this calculation by sampling the memory usage of the process (and child processes) at regular intervals. As mentioned on the pricing page, memory usage is rounded up to the nearest 128 MB bucket (so if your process is using 160 MB you are charged for 256 MB). This process of calculating memory usage and rounding up takes concurrency (multiple concurrent function executions in the same process) into account.
Not directly. Indirectly, CPU usage can have an impact on the cost because it might impact the execution time of the function.
To determine this we can take the minimum amount of memory (128 MB) and the minimum execution time (100ms - if a function runs for less than 100ms then the system uses an execution time of 100ms in the calculation, as mentioned on the [pricing page]) and multiply them together i.e. 0.125 GB * 0.1s = 0.0125 GB-sec.
The cost analysis functionality in the Azure Portal can give you a quick overview of the cost of your functions in terms of real-world currency.
The relevant entries are:
- Compute Requests (in 10s) - this is the
Total Executionsmeter listed on the pricing page. In Azure Monitor this metric is calledExecution Count. - Compute Duration (in GB Seconds) - this is the
Execution Timemeter listed on the pricing page. In Azure Monitor, this metric is calledFunction Execution Unitsand is measured in MB milliseconds (discussed further below).
In terms of real world currency, the cost information is available per day, per resource (i.e. per Function App, not per function). You can retrieve per minute, per resource data in terms of Execution Count and Function Execution Units from Azure Metrics.
Per execution cost information is not currently available. There is an open feature request tracking that here.
You can do this with the metrics explorer. Here is an example of viewing Function Execution Units:
This screen shows a total of 9.2 million Function Execution Units consumed in the last hour. As mentioned above, this metric is measured in MB milliseconds. To convert this to GB seconds, divide by 1,024,000. So in this case, my Function App consumed 9,200,000 / 1,024,000 = 8.98 GB seconds in the last hour.
The same metrics shown above are available through the Azure Monitor REST API.
The Azure CLI also has commands for retrieving metrics. You can use the CLI directly from the portal using the Azure Cloud Shell. Here's an example of retrieving per-minute data:
az monitor metrics list --resource /subscriptions/<subid>/resourceGroups/pbconsumptionexample/providers/Microsoft.Web/sites/pbconsumptionexample --metric FunctionExecutionUnits,FunctionExecutionCount --aggregation Total --interval PT1M
This command returns a payload with fragments that look like this:
"name": {
"additionalProperties": {},
"localizedValue": "Function Execution Units",
"value": "FunctionExecutionUnits"
},
"resourceGroup": "pbconsumptionexample",
"timeseries": [
{
"additionalProperties": {},
"data": [
{
"additionalProperties": {},
"average": null,
"count": null,
"maximum": null,
"minimum": null,
"timeStamp": "2018-04-13T23:40:00+00:00",
"total": 153600.0
}
],
"metadatavalues": []
}
],
This particular response shows that from 2018-04-13T23:40 to 2018-04-13T23:41, my app consumed 153,600 MB milliseconds (0.15 GB seconds).
Because Function Execution Units are a combination of execution time and your memory usage, they are not a great metric to use when you're only trying to understand just your memory usage (and potentially optimize your app to use less memory). For this we recommend using the performance counter data collected by App Insights when you enable it for Azure Functions. You can then access this data using the App Insights Analytics portal by running the following query:
performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value, cloud_RoleInstance
| timestamp | name | value |
|---|---|---|
| 2018-04-13T23:30:03.633 | Private Bytes | 44,662,784 |
| 2018-04-13T23:30:40.613 | Private Bytes | 44,699,648 |
Please note that there have been some reports of this performance counter being incorrect in some cases. Further investigation is required and the issue is tracked here.
Ideally, this information would also be available as a metric through Azure Monitor. This feature request is tracked here.
In some cases, yes. Azure Monitor tracks metrics at the resource level (i.e. the Function App), while our App Insights integration can emit per-function metrics. Here is an example analytics query to get the average duration per function:
customMetrics
| where name contains "Duration"
| extend averageDuration = valueSum / valueCount
| summarize averageDurationMilliseconds=avg(averageDuration) by name
| name | averageDurationMilliseconds |
|---|---|
| TimerTriggerCSharp1 Duration | 0.9007444311 |
| TimerTriggerCSharp2 Duration | 808.5745516667 |
This question is typically asked in the context of a C# function that does an async operation and waits for the result, e.g. await Task.Delay(1000) or await client.GetAsync("http://google.com"). The answer is yes - the GB second calculation is based on the start and end time of the function and the memory usage over that period. What actually happens over that time in terms of CPU activity is not factored into the calculation.
One exception to this rule is if you are using durable functions. You are not billed for time spent at awaits in orchestrator functions.
Yes. For example, if your function uses an output binding to write a message to an Azure storage queue, your execution time includes the time taken to write the message to the queue and is included in the calculation of the function cost.
Its a known issue, see here.