Azure Functions Flex Consumption: supported VNet attachment with controlled provider registration and retries

Question

Azure Functions Flex Consumption: supported VNet attachment with controlled provider registration and retries

Hiscock, Steve 0

We are preparing to attach an existing non-production Azure Functions Flex Consumption app to an existing subnet delegated to Microsoft.App/environments, then admit only that subnet through an Azure SQL virtual-network rule. We want the standard supported approach, not a custom recovery framework. No live mutation is requested here.

This is distinct from our earlier disconnection/association question: https://learn.microsoft.com/en-us/answers/questions/6017685/azure-functions-flex-consumption-subnet-service-as . A related clarification is in that thread; this separate question focuses on attachment and tooling behaviour.

Our safety objectives are to preserve identity, application settings and CORS; avoid unrelated provider registration; bound execution; and independently verify the result before progressing. Restrictions on redirects and automatic mutation replay are our chosen controls, not claimed Azure requirements. We welcome advice on proportionate controls compatible with standard tooling.

Two questions:

What is the supported minimal attachment operation for Flex? Is Web Apps Update PATCH (2025-03-01) with only properties.virtualNetworkSubnetId sufficient, preserving unrelated configuration? The Functions networking documentation says Flex already routes all traffic through the integrated VNet. Is any separate routing property needed, and what completion/readback checks are recommended?
What standard CLI/SDK approach is recommended when unexpected provider registration must fail rather than be repaired automatically? Static inspection of our installed CLI found that functionapp vnet-integration add can register Microsoft.App with consentToAuthorization=true, including after a provider-state lookup error. Its management SDK also includes ARMAutoResourceProviderRegistrationPolicy, which can register a namespace reported in MissingSubscriptionRegistration and resend the request. The installed az rest path follows redirects. We have not established documented options that satisfy all our chosen restrictions without replacing the SDK pipeline.

Would you recommend documented configuration, a different standard operation, or accepting specific bounded SDK behaviours with appropriate preflight and postchecks? Please distinguish supported contracts from implementation details. We do not want to patch vendor internals, disable authentication, grant broad permissions or infer completion from a timed-out command.

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

https://learn.microsoft.com/en-us/rest/api/appservice/web-apps/update?view=rest-appservice-2025-03-01

https://learn.microsoft.com/en-us/rest/api/sql/virtual-network-rules/create-or-update?view=rest-sql-2023-08-01

Resource identifiers, credentials and logs are intentionally omitted.

0 comments

1 answer

Your answer

Answer 1

Well, i understand that you want to attach an existing Azure Functions Flex Consumption app to a subnet delegated to Microsoft.App/environments, then allow that subnet to reach Azure SQL. You also want a scoped operation, controlled provider registration, and checks before continuing.

I think Azure SQL virtual-network rules require the referenced subnet to have the Microsoft.Sql service endpoint enabled as enforced in current Flex Consumption networking guidance; in fact its integration subnet must not already be used for service endpoints. Based on published requirements, I dont wnow if that the same subnet can safely satisfy both requirements.

For a private, supported setup, i suggest using Azure SQL Private Link instead:

Keep the Function’s VNet integration subnet dedicated to Flex and delegated to Microsoft.App/environments.
Create the Azure SQL private endpoint in a separate subnet.
Configure the privatelink.database.windows.net private DNS zone and link it to the VNet used by the Function.
Verify that the Function resolves the SQL server name to the private endpoint address and can connect to SQL.
Disable public network access on the SQL server if the intended design is private-only.

Flex Consumption routes traffic through its integrated VNet; no separate Route All setting is required for this plan. If you specifically require an Azure SQL virtual-network rule instead of Private Link, ask Microsoft to clarify whether enabling the SQL service endpoint on a Flex integration subnet is supported under the current subnet guidance before proceeding.

For the attachment operation, Microsoft documents az functionapp vnet-integration add for an existing Function App. The Microsoft.App provider must be registered. And if the deployment process must fail closed when registration is missing, have the platform team register it beforehand and verify that its state is Registered; do not grant the deployment identity provider-registration rights.

The documented Web Apps Update REST operation is also a PATCH, and its resource model includes properties.virtualNetworkSubnetId. A request body can set that property alone. So read the Function App configuration before and after the change and confirm the subnet association and the settings you need to preserve, and if your policy requires redirects to be rejected, use an HTTP client configured to stop on redirects. Caveat: az rest follows redirects.

After attachment, verify the subnet association using the Function App readback and the VNet integration listing and then test DNS resolution and an actual SQL connection from the Function App. Another caveat: successful ARM update alone does not prove that DNS, routing, firewall policy, and SQL authentication all work together.

Microsoft references:

I hope this is helpful, so please upvote the answer if the information helped you.

This answer was partially prepared and fully translated into English with assistance from AI (ChatGPT/Mistral AI). I reviewed the technical claims against previeous experience and the updated Microsoft documentation linked above.

Ciao