Azure
Unable to deploy flex consumption function app due to networking issue
When deploying a flex consumption function app with custom networking, I receive the following error:
{\"code\":\"OnlyOneServiceAssociationLinkAllowedPerSubnet\",\"message\":\"Subnet
│ /subscriptions/REDACTED/resourceGroups/REDACTED/providers/Microsoft.Network/virtualNetworks/REDACTED/subnets/REDACTED
│ already has service association link
│ /subscriptions/REDACTED/resourceGroups/REDACTED/providers/Microsoft.Network/virtualNetworks/REDACTED/subnets/REDACTED/serviceAssociationLinks/AppServiceLink
│ and hence service association link
│ /subscriptions/REDACTED/resourceGroups/REDACTED/providers/Microsoft.Network/virtualNetworks/REDACTED/subnets/REDACTED/serviceAssociationLinks/legionservicelink
│ cannot be
│ added.\",\"details\":[]}
This has been mentioned on Stackoverflow by @nzthiago as being a known issue (see https://stackoverflow.com/questions/79371050/removing-azure-functions-using-flex-consumption-sku-from-a-subnet-leaves-it-in-a#comment140062778_79371442 ) however there's no clarity about timelines for a fix or a way of knowing when it is done. So I have created this ticket
Unfortunately without having the function app name or support ticket number it's difficult for us to investigate. Were you able to disable/turn off the VNet integration before deleting the app and re-creating (if this is how you got to reproduce this error)?
Thank you for sharing - it looks like the subnet that is being used to VNet integrate the app into already has a service association. If there is another service associated with that subnet that aren't Flex Consumption apps, you would need to unlink it first. If this function app is the only thing being associated with it, then the support team will need to investigate and "free up" a potential lingering association that was previously created by a previous deploy, so great to hear a support ticket exists.
Thanks for this - this would almost certainly be because we were migrating an existing function app to flex consumption. That in turn implies that we need to raise a service ticket for every function app we want to migrate, which is a fair few. So we'd probably still like to talk about root cause fixes, if that makes sense?
Flex Consumption apps can share the same subnet. You just can't have other non-Flex apps or services in that same subnet. So you could consider creating a new, empty subnet for Flex Consumption and have multiple Flex Consumption apps VNet integrated into it. If that doesn't work, you would have to first "disconnect" the VNet integration from the old app or apps that are assigned to that subnet before VNet integrating the Flex Consumption app to it.
But also - yes please follow the support ticket path too to see if the team can share any other thoughts on this as they should be able to take a closer look (I don't have access to much detail on support tickets).
We were able to fix this by using new VNETs for flex consumption, instead of reusing our Elastic Premium ones. Not ideal, and still a bug from our perspective. (we can't delete the old vnets yet, we get the error
)
But perhaps we can close this issue :)
In considerations for Flex Consumption we document that the subnet delegation required when running in a Flex Consumption plan is Microsoft.App/environments. This differs from the Elastic Premium and Dedicated (App Service) plans, which have a different delegation requirement. And that the subnet used for Flex Consumption can't already be in use for other purposes (like private or service endpoints, or delegated to any other hosting plan or service). This is not a bug per se, just a limitation/requirement of the platform.
But there is one possible bug in that you can't delete the subnet or unlink it - hopefully the support ticket was able to identify if this was the case and the product team can address it.