Serverless computing is a growing trend in cloud computing, and it’s a natural next step in the Platform as a Service (PaaS) area. First PaaS allowed applications to be hosted without requiring Virtual Machines to manage, then serverless computing further removes the construct of a server. Azure Functions is the service within the Microsoft Azure cloud that offers serverless hosting and execution of application code. With serverless architecture removing the construct of a server from the equation of application hosting the concept of pricing begins to get a little fuzzy. This articles explains how Azure Functions pricing works.
Azure Functions is available with the 2 following pricing methods:
Consumption Plan
With Consumption Plan hosting, Azure Functions completely abstracts away the server construct. You no longer pay for reserving CPU Cores and RAM of the underlying Virtual Machine (VM). You only pay for the time your code runs, and not for the time it remains idle.
When provisioning Azure Functions in Microsoft Azure, the Hosting Plan option of Consumption Plan will configure the use of the Consumption Plan. Rather than specifying the CPU Cores and RAM of the underlying VM, the Consumption Plan specifies the Memory Allocation to reserve for the Azure Functions service while it is running.
The options for Memory Allocation range from 128 MB on the bottom all the way up to a maximum of 1.5 GB of memory.
You only pay when the Azure Function is run.
When Azure Functions execute the scalability of the application code is handled automatically behind the scenes by the service without the need to configure any Autoscaling or even manually scaling the App Service Instance like would be needed if the same code were hosted in an Azure App Service WebJob.
Further details on the specifics of Azure Functions pricing can be found on the official Azure Functions pricing page.
App Service Plan
With App Service Plan hosting, Azure Functions runs on top of an Azure App Service Plan. With this method the Platform as a Service (PaaS) Virtual Machine (VM) under the covers remains reserved. The CPU Cores and RAM of the VM still need to be specified as they are reserved for the instance size the same as with any other Azure App Service; such as Azure Web Apps or API Apps.
When provisioning Azure Functions in Microsoft Azure, the Hosting Plan option of App Service Plan will configure the use of an App Service Plan for hosting the Azure Functions. The underlying Virtual Machine (VM) will be reserved just like any other Azure App Service Plan service (Web Apps, API Apps, and Mobile Apps).
Azure Functions can run in an App Service Plan of another resource without incurring additional compute costs.
The App Service Plan hosting plan option for Azure Functions exists for the purpose of hosting Azure Functions along-side other App Service resources running in an App Service Plan. While it may not be practical to host Azure Functions in a VM Instance in an App Service Plan if that’s the only resource being hosted, since it would cost much more than if Consumption Plan were used instead.
By using App Service Plan hosting plan, the Azure Functions can run within an App Service VM Instance, thus allowing for even further cost savings by utilizing over provisioned resources of an existing App Service Plan VM Instance. In other words, if the Azure Web App being hosted doesn’t exactly need all the CPU Cores and RAM allocated to it, then hosting Azure Functions here will utilize what’s already being paid for without incurring additional computer costs.
Further details on the specifics of Azure App Service pricing can be found on the official Azure App Service pricing page.
Reblogged this on The Flying Maverick.
I updated the article to reflect “Consumption Plan” naming instead of the older “Dynamic” since it’s been since changed after Azure Functions have gone GA.
Hi Chris, I have a question as we are moving some of our functions to production. We have a scenario where we need a single global point of entry. For our app servers running > S plans we leverage GTMs (nested GTMs) so that it can route directly to the app service / function based on geographic metric.
Naturally we are also wanting to benefit from the consumption model. Are there plans or do you know of a way to leverage GTMs to route between two functions in different regions performing the same task?
I assume you’re calling the Azure Functions with a Webhook or HTTP endpoint. With this you should be able to configure Azure Traffic Manager with the Azure Functions endpoints and then load balance across them just fine.
Yes, we are using standard http (s) endpoint. However when the app service is running under the consumption plan it doesn’t appear in the options under the traffic manager.
Unless of course I am missing something?
Oh I see what you mean. You could get around that by setting up Traffic Manager by configuring an External Endpoint and entering the HTTP URL in. Traffic Manager can be used with HTTP endpoints that are not hosted in Azure.
Hi there. Thanks for the write up, it describes well and succintly the differences among those two choices. We just noticed that for Function Apps running on **Consumption Plans** there are **NO SLA provided**. Do you know why is that? Are Consumption plans still somehow “beta” ? Thanks
Hmm, this is odd. Azure Functions have a 99.95% SLA guarantee, but the docs state that there “No SLA is provided for Functions running under Consumption Plans.” However, that SLA page was last updated November 2016 when Functions were still under Preview. Now that it’s GA (Generally Available) is should definitely have the same 99.95% SLA. I will follow up with the Functions product team and see what I can find out for Functions SLA under Consumption Plans. Thanks for asking!
Thank you for such quick reply!
Exactly. And that info is confirmed in a couple more places too, so definitely not a “typo” issue. At the moment we’re mostly interested in EU regions, Italy especially, where anyway Functions are out of beta too. Waiting for feedback hopefully! Regards
I have found out that it’s not a mistype in the documentation for the SLA on Azure Functions with Consumption Plan Pricing. I’m not sure what the product team is working on in regards to this, but I would assume we’ll have a full SLA eventually; hopefully sooner than later! Somehow I wasn’t actually aware it still didn’t have an SLA so I am eagerly awaiting it myself!!
Ouch, I see. I guess they did not disclose any possible plan/timeline … Thanks a lot for your attention!