Azure-Functions
Azure-Functions copied to clipboard
Azure
VNET Integration for Azure function using Consumption plan
My azure function is running on a Consumption plan and it needs to access a resource running on a VM on a Azure VNET. The resource cannot be exposed via http.
Is there a solution other then switching to App Service Plan?
Are there any plans for VNET for consumption plan? Serverless meaning = not handling the servers. It seems the true "serverless" Azure Functions (consumption) has little to no features such as the basic Virtual Network (simple basic isolation). Going to App Service Plan means it loses the "serverless" idea.
Agreed, this makes consumption plan useless if you're in the process of migrating your application from IaaS to PaaS. Will this functionality be added at any point?
@btardif / @ColbyTresness - Do we have any plans for adding support of VNET in consumption plan?
There are some technical blockers that make this really challenging, but it something we're aware of as an ask and are tracking. No concrete plans, however.
As discussed with @jeffhollan we have had this same request from other high profile customers.
More info: They want to utilize Azure Functions for replacing an antiquated, hard to update applications while making way into other possible applications that can utilize Azure. They have a lot of resources inside a VNET and need to be able to reach the different endpoints hosted there. They prefer and their workload is conducive to the consumption plan. So they ask for VNET support on Consumption Plan for Azure Functions.
This would unblock other workloads for them besides this initial project.
as someone that's fully on AWS yet starting to look around at leveraging other tools like azure's functions, it seems that this missing capability is barring me from being able to work securely with my existing infrastructure.
We are working on adding this functionality to a serverless SKU. I'll have more info in the coming months :)
+1 This is a key feature, and blocker for a few things I am building as the consumption plan is the only way to make a lot of small initiative financially viable. 👀
Hello all, VNET integration is now available in the Premium plan. The Premium plan scales dynamically, and has a fixed cost of about 15% the initial cost of an ASE.
@alexkarcher-msft that's great. is doing the same for the consumption plan on the roadmap at all?
Not at the moment. The more modern VMs that the Premium plan runs on are what enable us to connect to a VNET while scaling dynamically.
In premium plan and app service plan also the integration is not working.
@denniceritchie can you potentially open another issue with details on what you are seeing in Premium / App Service Plan that isn't working? I'm not aware of any issues that would prevent it it from working in the premium plan.
Does anyone have any updates regarding this issue? When we can expect some kind of solution in the preview, or we can completely dismiss expectations about this feature.
Spending 153$ per month for a Premium plan is a really huge amount of money for someone, let's say who has 3-5 functions.
Or I am doing wrong calculations.
Ok, I know that I have an option to deploy my functions with Azure Container Instances and connect it with the VNET, but in that case, I have to worry about the time of running and other things, which is not quite a good solution.
Kind regards
@Ratomir I know that's not a "perfect" solution but you can use App Service Plan with S1 machines, that will allow you to use VNETs. This cost around $60/mo
Hi, I'm creating a startup making use of +10 function apps (consumption plan) for my microservice infrastructure and not being able to add them to same VNET's as their related services like StorageAccounts, keyvaults etc. really sucks.
Paying 152$ for each function app is not possible, and dumping all functions into the same function app isn't a proper solution. A lot of my function apps are simple API's taking less than 1 second to execute and making use of different related services secured by vnet's.
So I miss being able to add VNET's to function apps running on consumption plan
Hi, I'm creating a startup making use of +10 function apps (consumption plan) for my microservice infrastructure and not being able to add them to same VNET's as their related services like StorageAccounts, keyvaults etc. really sucks.
Paying 152$ for each function app is not possible, and dumping all functions into the same function app isn't a proper solution. A lot of my function apps are simple API's taking less than 1 second to execute and making use of different related services secured by vnet's.
So I miss being able to add VNET's to function apps running on consumption plan
Also agree that VNET integration in consumption would be great, but to clarify: you pay Premium for the app plan instance, and you can have up to 100 function apps in the same Premium Functions app plan. So you can still pay for one instance of the Premium plan and have your 10 function apps in the same plan.
Hi, I'm creating a startup making use of +10 function apps (consumption plan) for my microservice infrastructure and not being able to add them to same VNET's as their related services like StorageAccounts, keyvaults etc. really sucks. Paying 152$ for each function app is not possible, and dumping all functions into the same function app isn't a proper solution. A lot of my function apps are simple API's taking less than 1 second to execute and making use of different related services secured by vnet's. So I miss being able to add VNET's to function apps running on consumption plan
Also agree that VNET integration in consumption would be great, but to clarify: you pay Premium for the app plan instance, and you can have up to 100 function apps in the same Premium Functions app plan. So you can still pay for one instance of the Premium plan and have your 10 function apps in the same plan.
Oh Thanks so much @nzthiago , I didn't notice it is the App Plan you buy as Premium.
you can have up to 100 function apps in the same Premium Functions app plan :) :) :)
The blocker is getting Consumption Plan onto modern VMs, right? This has been outstanding for years, I think? Please push it up the agenda
Network-level access control is an essential, not a "premium" optional extra.
For example: there was this vuln in Cosmos DB where keys were leaked. https://www.theregister.com/2021/08/27/chaos_db_azure_cosmos_flaw/
Our only option is to synchronize data updates from our VM database cluster to an Azure Table in order to read the data we need into our Consumption Function apps. All our data is in a VM cluster under VNet. This is a major blocker and we do not need most of the features with Premium.
The hardware hosting Consumption Plan is old and doesn't support the 'SWIFT' networking tech (which allows packets to be teleported to/from a customer VNET)
I suspect: the cheap/free pricing of Consumption Plan is enabled solely by this hardware being otherwise redundant - fit only for retirement. Like, who wants instances that are slow and can't do secure networking properly?
I suspect: they have modelled what it would cost to run their Consumption model on modern hardware and it isn't profitable enough so it will never happen.
I suspect: this is why they pedalled back from per-invocation consumption pricing, when they designed the Premium Plan.
My 2c
I think you have a solid insight into the reasoning behind it. Had I known this limitation months ago, our implementation may have been very different.
On Wed, Jan 5, 2022, 4:39 PM Iain Shepherd @.***> wrote:
The hardware hosting Consumption Plan is old and doesn't support the 'SWIFT' networking tech (which allows packets to be teleported to/from a customer VNET)
I suspect: the cheap/free pricing of Consumption Plan is enabled solely by this hardware being otherwise redundant - fit only for retirement. Like, who wants instances that are slow and can't do secure networking properly?
I suspect: they have modelled what it would cost to run their Consumption model on modern hardware and it isn't profitable enough so it will never happen.
I suspect: this is why they pedalled back from per-invocation consumption pricing, when they designed the Premium Plan.
My 2c
— Reply to this email directly, view it on GitHub https://github.com/Azure/Azure-Functions/issues/646#issuecomment-1006133914, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVFQ4FT3YIYD6YVFATPWQTUUTCBXANCNFSM4EK22GQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
Any news on this?
I am strongly considering moving to AWS because of VNET not being available in the consumption plan for Functions. This is an absolute must-have in terms of security and frankly, I am disappointed that Microsoft has not addressed this, since Azure is promoted to be highly secure.
For visibility it's probably a good idea to add votes to the new Azure Feedback page as well.
- https://feedback.azure.com/d365community/idea/d647e855-f224-ec11-b6e6-000d3a4f0da0
There's only 1 compute as a service "TRUE" serverless offering on Azure and its the function apps consumption plan, this issue is 4 years old now and there's still been no progress on making any kind of network security model available on consumption plan at all.
It's forcing your customers into a difficult decision as its either. A: Pay more, over provision and swap onto a non-server-less based pricing tier B: Open your 'X' up to the public internet, for which X will normally be a database.
Bigger companies may go for 'A' but for for SME's I have no doubt there will be a large number of them going for B which introduces significant security risks.
AWS has this VPC (ENI) GCP has this. VPC access Alibaba cloud has this. VPC (ENI) Azure does not have this (consumption plan)
Security should not be seen as a 'product' that can be itemized and sold on Azure it should be a baseline because without it like that customers will be making decisions that sacrifice security for cost which introduces significant risk.
(price in NZD) https://azure.microsoft.com/en-us/pricing/details/api-management/ [VNET support] = 4500$/month minimum https://azure.microsoft.com/en-us/pricing/details/functions/ [VNET Support] = 200$/month minimum instead 0.30c per million requests https://azure.microsoft.com/en-us/pricing/details/app-service/windows/ [VNET Support] = 110$/month minimum but 18$/month without
Seems like this replicates for the most common azure services.
