I have been working with Flex Consumption plan-based Azure Function Apps for several months and was super enthusiastic about the value.
The Flex Consumption plan produces stable funding for script-defined automation and costs pennies. It allows integration with your private VNET and could be used within a private network environment.
Is it really that good?
Unfortunately, there is no direct answer, and let me explain why.
Azure Function App uses Storage account
Yep. Every Azure Function App utilizes the Azure Storage account to (ha-ha) function. The code of the Function App is located on the Storage account and should be available to the Azure Function App at every moment.
Which is fine. The price of the Storage accounts is reasonable and depends on the amount of data. And that could not be a lot. So the problem is not the Storage account itself.
Private Endpoints are the problem!
Again, when you run your Azure Function App in private, that literally means all the services must run in private and cannot be accessed from the Internet.
As I explained in the previous articles (Azure Function App (Flex Consumption) in private VNET via IaC), you have to build an internal connection between the Azure Function App and the Azure Storage account.
How? You have to setup (at least) two private endpoints for the blob and file services of the Storage account. It is not difficult, but there are some details that must be addressed. That is precisely the point of the mentioned article.
Every private endpoint is billed for time. It costs 1 cent per hour. Which seems to be close to nothing... But...
1 cent per hour sums to about $7.2 per month. And there are two of them, so ~$15 per month.
Here comes Durable Functions stuff
What Durable Functions? Yep. That is another really great technology that deserves much longer article.
Basically, Durable Functions fix the natural limitations of the Azure Functions.
For example, any HTTP-triggered function must return something within 230 seconds. And what if you need more than 240 seconds to gather the results? Or, the grace period of Azure Function is 60 minutes. What if you need more time to execute your automation?
Durable Functions resolve that. They bring the 'context' term into Azure Functions. That gives the possibility of the longer run, control of the run, statuses of the run, and more good things.
But how is that related to this post?
Directly! Durable Functions libraries use the queue and the table services of the Azure Storage account!
From our ("Azure Function in the Private") standpoint, that means we have to create, support, and pay for two more private endpoints for these services!
Final calculation
So, these four private endpoints will cost you ~$7.2 x 4 = ~$30 per month.
Which is still very reasonable, but not cheap.
And don't forget that you probably need to support at least two environments: DEV and PROD. Which makes it $60.
In case you are not afraid
It is still a very robust solution.
And in this 🦊GitLab repo (azure-function-app), I created an end-to-end automated solution that deploys two infrastructures, builds the PowerShell-based Azure Function App, and deploys it to your private VNET.
And yes, the Durable Functions are supported too! Just do not forget to set CI/CD variable AZURE_IS_DURABLE_FUNCTION to 'true'.
Top comments (0)