Azure App Service outbound calls to management.azure.com suddenly blocked from two web apps on same outbound IP pool

Question

We have two Azure App Services hosting the same Django backend application: sandbox and prod. Both apps have been successfully calling Azure Resource Manager for months to manage Azure SQL firewall rules. On 2026-03-06, both apps began failing at the same time.

The failing operation is an outbound call from the App Service to Azure Resource Manager at https://management.azure.com/.../providers/Microsoft.Sql/servers.

Both apps now return a 500 from our API because the Azure Python SDK receives an HTML response from Microsoft instead of JSON. The HTML says:

The request is blocked.

This appears to be happening on the first ARM SQL management call:

GET https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.Sql/servers?...

Local execution of the exact same code, using the same credentials and subscription, succeeds from a developer machine. This strongly suggests an issue with the App Service outbound egress path or a Microsoft-side block affecting the shared outbound IP pool / regional App Service infrastructure.

Impact

• Both hosted apps stopped working at the same time.
• Endpoint affected: POST /auth/manage-db-firewall/
• Business impact: users cannot automatically add their client IP to Azure SQL firewall rules.

Evidence

Hosted App Failure

• Token validation succeeds.
• Entra token acquisition succeeds.
• Failure occurs when calling ARM SQL management API.
• Exception from Azure SDK:

azure.core.exceptions.DecodeError: JSON is invalid: Expecting value: line 1 column 1 (char 0)

Content: ... <h2>The request is blocked.</h2> ...

Ref A: 0AB5AD61EF0C4B979A41CCDF10C7631B

Ref B: BY1AA1072319054

Ref C: 2026-03-06T17:45:07Z

Application stack location

• Failure occurs in our Django code while iterating:

sql_client.servers.list()

Local Success

From a local machine, the same code path succeeds:

• login.microsoftonline.com discovery returns 200 application/json
• token acquisition returns 200 application/json
• GET https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.Sql/servers returns 200 application/json
• firewall rules list succeeds
• firewall rule create succeeds
• API returns 201

Environment Details

Both affected App Services have:

• Public network access enabled
• No access restrictions
• No private endpoints
• No VNet integration
• No NAT gateway
• No NSG
• No UDR
• Azure-provided outbound DNS

Both apps show the same outbound IP list, including:

13.91.71.221, 13.87.130.15, 13.87.133.42, 13.64.111.216, 13.64.106.162, 13.64.108.222, 40.78.84.34, 13.93.139.194, 40.85.156.188, 40.78.81.155, ... , 40.112.243.111

This suggests both apps are using the same outbound egress pool / shared infrastructure.

Request for Investigation

Please investigate whether:

1. One or more outbound IPs in this App Service egress pool are being blocked or challenged when calling management.azure.com.
2. There is a Microsoft-side incident or regression affecting ARM access from this App Service region / stamp / scale unit.
3. The Ref A / Ref B / Ref C values above correspond to an edge/WAF/security block on Microsoft’s side.
4. Recycling, rehoming, scaling, or moving plans would change the outbound path and restore service.We have two Azure App Services hosting the same Django backend application: sandbox and prod. Both apps have been successfully calling Azure Resource Manager for months to manage Azure SQL firewall rules. On 2026-03-06, both apps began failing at the same time. The failing operation is an outbound call from the App Service to Azure Resource Manager at https://management.azure.com/.../providers/Microsoft.Sql/servers. Both apps now return a 500 from our API because the Azure Python SDK receives an HTML response from Microsoft instead of JSON. The HTML says: The request is blocked. This appears to be happening on the first ARM SQL management call: GET https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.Sql/servers?... Local execution of the exact same code, using the same credentials and subscription, succeeds from a developer machine. This strongly suggests an issue with the App Service outbound egress path or a Microsoft-side block affecting the shared outbound IP pool / regional App Service infrastructure.

   Impact

   • Both hosted apps stopped working at the same time.
   • Endpoint affected: POST /auth/manage-db-firewall/
   • Business impact: users cannot automatically add their client IP to Azure SQL firewall rules.

   Evidence

   Hosted App Failure
   • Token validation succeeds.
   • Entra token acquisition succeeds.
   • Failure occurs when calling ARM SQL management API.
   • Exception from Azure SDK:
   azure.core.exceptions.DecodeError: JSON is invalid: Expecting value: line 1 column 1 (char 0) Content: ... <h2>The request is blocked.</h2> ... Ref A: 0AB5AD61EF0C4B979A41CCDF10C7631B Ref B: BY1AA1072319054 Ref C: 2026-03-06T17:45:07Z Application stack location
   • Failure occurs in our Django code while iterating:
   sql_client.servers.list() Local Success From a local machine, the same code path succeeds:
   • login.microsoftonline.com discovery returns 200 application/json
   • token acquisition returns 200 application/json
   • GET https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.Sql/servers returns 200 application/json
   • firewall rules list succeeds
   • firewall rule create succeeds
   • API returns 201

   Environment Details

   Both affected App Services have:
   • Public network access enabled
   • No access restrictions
   • No private endpoints
   • No VNet integration
   • No NAT gateway
   • No NSG
   • No UDR
   • Azure-provided outbound DNS
   Both apps show the same outbound IP list, including: 13.91.71.221, 13.87.130.15, 13.87.133.42, 13.64.111.216, 13.64.106.162, 13.64.108.222, 40.78.84.34, 13.93.139.194, 40.85.156.188, 40.78.81.155, ... , 40.112.243.111 This suggests both apps are using the same outbound egress pool / shared infrastructure.

   Request for Investigation

   Please investigate whether:
   1. One or more outbound IPs in this App Service egress pool are being blocked or challenged when calling management.azure.com.
   2. There is a Microsoft-side incident or regression affecting ARM access from this App Service region / stamp / scale unit.
   3. The Ref A / Ref B / Ref C values above correspond to an edge/WAF/security block on Microsoft’s side.
   4. Recycling, rehoming, scaling, or moving plans would change the outbound path and restore service.

Answer 1

Based on the provided information, the behavior is consistent with an outbound connectivity problem from Azure App Service rather than with authentication or the Azure Python SDK itself.

For apps and functions hosted on Azure App Service, intermittent or sudden failures when calling external endpoints (including Azure Resource Manager) are typically caused by hitting outbound connection limits:

1. SNAT port exhaustion to management.azure.com
   • Each App Service instance initially has a preallocated quota of 128 SNAT ports for outbound connections to a given address/port combination.
   • When applications rapidly open new outbound connections to the same destination (for example, repeated calls to https://management.azure.com), the SNAT ports for that destination can be exhausted.
   • Once exhausted, new outbound connections can intermittently fail until SNAT ports are reclaimed (the Azure load balancer waits about four minutes after connection close before reclaiming a port).
   • Symptoms of SNAT exhaustion include intermittent 5xx/Bad Gateway errors, timeouts, and failures to connect to external endpoints, which matches the described impact on the App Service apps.
2. How to confirm whether SNAT is the cause
   Use App Service Diagnostics to inspect SNAT port allocation for the affected apps:
   1. In the Azure portal, open each App Service.
   2. Select Diagnose and solve problems.
   3. Choose Availability and Performance.
   4. Select the SNAT Port Exhaustion tile.
      This view shows SNAT port allocation information for the site. The recommended practice is to keep usage below 128. If more detailed data is required, open a support ticket so support can pull backend metrics.
3. Distinguish SNAT vs. total TCP connections
   • SNAT ports are used only for external flows (such as calls to management.azure.com).
   • Total TCP connections also include local/loopback connections and are tracked separately.
   • The TCP connections limit is per worker instance and is not used directly for SNAT limiting.
     A separate detector for TCP connections is also available under Diagnose and solve problems by searching for “TCP connections.”
4. Mitigation and long‑term fixes
   To avoid or reduce SNAT port exhaustion for outbound calls from App Service:
   • Use connection pooling in the application code
     Ensure HTTP connections to Azure Resource Manager are pooled and reused instead of opening new connections for each request. For HTTP-based calls, follow the guidance to pool HTTP connections (for example, using HttpClientFactory in .NET; the same principle applies in other languages). This reduces the rate at which new SNAT ports are consumed.
   • Use service endpoints or private endpoints where applicable
     For Azure services that support service endpoints or private endpoints, integrate the App Service with a regional virtual network and configure service endpoints or private endpoints. Outbound traffic from the app to those services then bypasses SNAT limits.
   • Use a NAT gateway for external endpoints
     For destinations that must be reached over the public internet (such as management.azure.com), integrate the App Service with a virtual network and attach a NAT gateway to the integration subnet. A NAT gateway provides up to 64K outbound SNAT ports and a dedicated outbound IP address for traffic from that subnet.
   • Combine strategies
     The most robust approach is to combine these mitigations: use connection pooling in the application, service/private endpoints for Azure services that support them, and a NAT gateway for remaining external endpoints.
5. Next steps for this specific scenario
   • Use App Service Diagnostics → SNAT Port Exhaustion to confirm whether SNAT usage is high at the time of failures.
   • If SNAT exhaustion is confirmed, implement connection pooling in the Django application’s HTTP client used by the Azure Python SDK (or ensure the SDK is configured to reuse connections).
   • If code changes are not immediately possible, consider moving the apps to a plan with regional VNet integration and a NAT gateway to increase available SNAT ports and change the outbound path.
   • If diagnostics do not show SNAT pressure yet the issue persists, open an Azure support ticket, referencing the time range and the error details, so support can correlate the Ref A/B/C identifiers with backend logs.

---

References:

• Troubleshoot intermittent outbound connection errors in Azure App Service