Bug in Azure Flex Consumption Plan

Question

Bug in Azure Flex Consumption Plan

Dimitrios Bardis 5

1. Problem Summary

My Azure Function App (Flex Consumption) is VNet‑integrated and configured to call Azure Document Intelligence through a Private Endpoint. DNS resolution inside the Function App resolves the endpoint to the correct private IP, and a curl test from the Function App container returns HTTP 200. However, the actual outbound call made by the function runtime is sent from a public outbound IP, not from the VNet‑integrated subnet. As a result, Document Intelligence rejects the request with:

Code

403: Traffic is not from an approved private endpoint

This indicates that Flex Consumption is starting function workers that are not VNet‑integrated, even though the Function App is configured for VNet integration. I need confirmation whether this is expected behavior

2. Technical Details

Environment:

Azure Functions Flex Consumption plan

Python Function App

VNet integration enabled

Private Endpoint for Document Intelligence

Private DNS zone linked to the same VNet

Public network access disabled on the Cognitive Service

Terraform‑based deployment

Observed behavior:

DNS resolution inside the Function App container is correct:

The hostname

Code

ragdocintsvc.cognitiveservices.azure.com

resolves to the private endpoint IP:

Code

10.50.0.69

curl test from the Function App container succeeds:

Code

HTTP 200 Service Operational

This confirms:

Private DNS zone is correct

Private Endpoint is correct

VNet integration works on this instance

However, the actual outbound call made by the function runtime uses a public outbound IP:

Code

Outbound IP: 74.241.138.252

This proves that the worker executing the function is not VNet‑integrated, even though the Function App is configured for VNet integration.

Document Intelligence rejects the call:

Code

403: Traffic is not from an approved private endpoint

This is expected when the request reaches the public endpoint instead of the private one.

Conclusion:

Flex Consumption appears to be scaling out to workers that are not attached to the VNet, causing inconsistent outbound routing. This makes Private Endpoint access unreliable on Flex Consumption.

Request:

Please confirm whether Flex Consumption guarantees VNet integration for all scale‑out workers. If not, please link to a documentation where it is stated that it does not guarantee that. Is it so that Flex is used for non-private solutions? If Flex is supposed to be used also for private networking then this is a bug.

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-04-24T11:11:11.6533333+00:00
Hi @Dimitrios Bardis ,

Thanks for reaching out to Microsoft Q&A.

This is actually expected with the Flex Consumption plan today, VNet integration is available but it doesn’t guarantee that every scaled-out worker instance will live in your VNet or use your private subnets for all outbound calls.

Flex Consumption uses a multi-tenant, on-demand pool of Linux containers.

When you enable “Regional VNet Integration” you get the ability to reach private endpoints and other VNet-only resources from some of those containers.

Because Document Intelligence’s private endpoint only allows traffic whose source is from the private NIC, your calls from a public SNAT are refused with 403.

If you need a 100 % guarantee that every function instance will live in your VNet and use a private outbound path, you’ll have to move to a plan that offers full VNet injection (for example, the Premium plan or an App Service Environment), or implement a NAT Gateway on your integration subnet so that even “public” SNAT egress IPs are ones under your control.

References:

Flex Consumption plan overview (calls out private networking support but doesn’t promise VNet injection for all scale-out instances)

Scaling in Azure Functions (explains how Consumption/Flex instances come and go dynamically)
Dimitrios Bardis 5 Reputation points

2026-04-24T14:50:07.9433333+00:00

thanks! I tried like you said (used the Premium Plan) and it still failed. I reported this with very detailed technical information on https://learn.microsoft.com/en-us/answers/questions/5871069/azure-limitation-on-private-networking-for-functio . This needs to be reported to azure support but i have no support plan that allows me to do that . So i posted instead. Hope someone from azure will realize the importance and investigates that because this is a proven big in azure in this specific setup.
Siddhesh Desai 7,890 Reputation points Microsoft External Staff Moderator

2026-04-27T09:43:19.32+00:00

Hi @Dimitrios Bardis

Can you please raise this bug by clicking on New Issue here: https://github.com/azure/azure-functions/issues

The dedicated team will respond to your issue on github. :)
Thiago Almeida 96 Reputation points Microsoft Employee

2026-08-07T16:31:42.1533333+00:00

@Dimitrios Bardis sorry you're running into this issue. That is not the intended behavior for Flex Consumption with VNet integration enabled. This could be a problem on the intelligence service's side and its DNS resolution. Unfortunately, we can't dive deeper without knowing the function app name, region, and rough timelines from when you say the issue - if possible and not confidential, could you share those details here? Even better if you can still reproduce it now so we have fresh logs.

1 answer

Your answer

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-04-24T11:11:11.6533333+00:00

Hi @Dimitrios Bardis ,

Thanks for reaching out to Microsoft Q&A.

This is actually expected with the Flex Consumption plan today, VNet integration is available but it doesn’t guarantee that every scaled-out worker instance will live in your VNet or use your private subnets for all outbound calls.

Flex Consumption uses a multi-tenant, on-demand pool of Linux containers.

When you enable “Regional VNet Integration” you get the ability to reach private endpoints and other VNet-only resources from some of those containers.

Because Document Intelligence’s private endpoint only allows traffic whose source is from the private NIC, your calls from a public SNAT are refused with 403.

If you need a 100 % guarantee that every function instance will live in your VNet and use a private outbound path, you’ll have to move to a plan that offers full VNet injection (for example, the Premium plan or an App Service Environment), or implement a NAT Gateway on your integration subnet so that even “public” SNAT egress IPs are ones under your control.

References:

Flex Consumption plan overview (calls out private networking support but doesn’t promise VNet injection for all scale-out instances)

Scaling in Azure Functions (explains how Consumption/Flex instances come and go dynamically)
Dimitrios Bardis 5 Reputation points

2026-04-24T14:50:07.9433333+00:00

thanks! I tried like you said (used the Premium Plan) and it still failed. I reported this with very detailed technical information on https://learn.microsoft.com/en-us/answers/questions/5871069/azure-limitation-on-private-networking-for-functio . This needs to be reported to azure support but i have no support plan that allows me to do that . So i posted instead. Hope someone from azure will realize the importance and investigates that because this is a proven big in azure in this specific setup.
Siddhesh Desai 7,890 Reputation points Microsoft External Staff Moderator

2026-04-27T09:43:19.32+00:00

Hi @Dimitrios Bardis

Can you please raise this bug by clicking on New Issue here: https://github.com/azure/azure-functions/issues

The dedicated team will respond to your issue on github. :)
Thiago Almeida 96 Reputation points Microsoft Employee

2026-08-07T16:31:42.1533333+00:00

@Dimitrios Bardis sorry you're running into this issue. That is not the intended behavior for Flex Consumption with VNet integration enabled. This could be a problem on the intelligence service's side and its DNS resolution. Unfortunately, we can't dive deeper without knowing the function app name, region, and rough timelines from when you say the issue - if possible and not confidential, could you share those details here? Even better if you can still reproduce it now so we have fresh logs.

Answer 1

Flex Consumption plan function apps support outbound virtual network integration and are designed to route outbound traffic through the integrated subnet when configured, including for private endpoint scenarios.

From the documented behavior:

Flex Consumption explicitly supports Virtual network integration (outbound) and Private endpoints (inbound) as part of its networking feature set.
For Flex Consumption, outbound traffic is routed through shared gateways dedicated to the subnet used for VNet integration. Up to 27 shared gateways (27 IPs) are used per subnet, regardless of how many apps are integrated.
The subnet must be dedicated, delegated to Microsoft.App/environments, and at least /27 in size (with /27 recommended for a single app and /26 for multiple apps). Using a smaller subnet or multiple apps on a /27 reduces available outbound network capacity but does not change the expectation that outbound traffic is routed via the VNet integration.

There is no statement in the referenced documentation that Flex Consumption workers are allowed to bypass VNet integration and send outbound traffic directly from public IPs when VNet integration is configured. The documented model for Flex Consumption is that outbound traffic from function app instances is routed through the shared gateways in the integrated subnet.

The behavior described (some executions using a public outbound IP and being rejected by a private‑endpoint‑only Cognitive Service) is therefore not documented as expected behavior and is not described as a limitation of Flex Consumption in the provided material. Flex Consumption is documented as supporting private networking via VNet integration, not as a “non‑private only” plan.

Given the documentation:

Flex Consumption is intended to be usable with private networking (VNet integration and private endpoints).
There is no documented requirement to move to Premium solely to “guarantee” that some workers are VNet‑integrated while others are not; instead, Flex Consumption’s outbound model is that traffic is routed via the integrated subnet’s shared gateways.

If this behavior persists with a correctly configured, dedicated, and properly sized subnet, it aligns with a service issue rather than a documented, by‑design limitation.

For further troubleshooting and escalation:

Verify the subnet used for VNet integration meets Flex Consumption requirements:
- Dedicated subnet.
- Delegation: Microsoft.App/environments.
- Size: at least /27, /26 recommended for multiple apps.
Use the Network troubleshooter for the Function App (Diagnostic and solve problems → Network troubleshooter) to validate:
- VNet integration status.
- Private IP assignment to instances.
- DNS configuration and connectivity to dependencies.
If configuration is valid and the issue continues, this should be treated as a service‑side bug and escalated via Azure Support.

References: