Azure Functions Flex Consumption: subnet service-association link ownership and supported VNet disconnection

Question

Azure Functions Flex Consumption: subnet service-association link ownership and supported VNet disconnection

Hiscock, Steve 0

I am seeking clarification of the supported Azure API contract before disconnecting VNet integration for a non-production Azure Functions Flex Consumption app. No backend cleanup or deletion of platform-managed resources is requested.

Observed shape (resource identifiers omitted)

The integrated subnet is delegated to Microsoft.App/environments.
It has one serviceAssociationLink with provisioningState=Succeeded and linkedResourceType=Microsoft.App/environments.
Its properties.link is slash-prefixed and subscription/resource-group scoped, with eight nonempty path segments, but no providers segment. It does not match the standard ARM resource-ID shape expected by our read-only tooling.
We have not rewritten this link into a guessed ARM URL or deleted the association.

Questions

Is this link shape expected for Flex Consumption? Is it an opaque platform reference rather than a directly retrievable ARM resource ID?
What supported read-only operation establishes the relationship between this association, the hosting environment/plan and the exact Function app, and identifies other consumers before disconnection?
Does the documented Web Apps Delete Swift Virtual Network operation support Flex Consumption disconnection? Specifically: DELETE /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/networkConfig/virtualNetwork?api-version=2024-11-01. If not, which documented operation should be used?
For the supported operation, what response and completion checks establish successful disconnection, and is there a supported way to check outstanding platform operations beforehand? We do not want to infer completion solely from resource absence or a Succeeded provisioning state.

Documentation consulted

The service-association-link reference describes properties.link as a link to the external resource, but I could not find a guarantee that it is a standard callable ARM ID or guidance covering this Flex-specific shape. Official documentation or product-team clarification would be appreciated.

0 comments

1 answer

Your answer

Answer 1

Hi @Hiscock, Steve

Really careful approach, and you're right not to rewrite that link or touch the association. Here's where each point stands.

The link shape isn't documented for Flex Consumption. The association is created and owned by the platform side of Microsoft.App/environments, so treat properties.link as an opaque platform reference, not a callable ARM ID. Nothing in the docs guarantees it resolves through ARM, and your tooling shouldn't depend on it.
Establish the relationship from the app side, not the subnet side. The site resource is the supported source of truth:
- az functionapp vnet-integration list -g <rg> -n <app> for the specific app.
  - To find every consumer of that subnet before you disconnect, query Resource Graph:

   resources
   | where type =~ "microsoft.web/sites"
   | where properties.virtualNetworkSubnetId =~ "<subnet-resource-id>"
   | project name, resourceGroup, kind, properties.serverFarmId

The Flex Consumption docs only document the portal and az functionapp vnet-integration remove for disconnection. The Delete Swift Virtual Network REST operation isn't referenced in the Flex docs, so I wouldn't treat it as a supported contract for this plan. If you need the exact REST call for your tooling, run the CLI command with --debug and it prints the requests it actually sends.
There's no documented API for outstanding platform operations. The practical checks are:
- Before: review the Activity log on the app for anything still in progress.
  - After: the vnet-integration list returns empty, and virtualNetworkSubnetId on the site is null.
    - The service association link on the subnet is removed asynchronously by the platform and can lag. If it's still there after a reasonable wait, don't delete it yourself. A lingering link is a known issue with Flex subnets and gets cleared through a support ticket.

If this helped, please click Accept Answer so others planning the same disconnection can find it.

References: https://learn.microsoft.com/en-us/azure/azure-functions/flex-consumption-how-to https://learn.microsoft.com/en-us/azure/azure-functions/functions-networking-options