This is the 3rd blog of a series on Azure App Service Limits illustrations:
1) Azure App Service Limit (1) - Remote Storage (Windows) - Microsoft Community Hub
2) Azure App Service Limit (2) - Temp File Usage (Windows) - Microsoft Community Hub
4) Azure App Service Limit (4) - CPU (Windows) - Microsoft Community Hub
5) Azure App Service Limit (5) - Memory (Windows) - Microsoft Community Hub
As we know, interactions with websites can be categorized as inbound and outbound, and the same principle applies to Azure App Service. This blog will discuss the connection limit within Azure App Service and address the most commonly asked questions related to TCP connections, SNAT and TLS versions.
Inbound Connections
With basic pricing tier, there is a limit of 350 concurrent WebSockets per instance. With standard pricing tier and above, there are no theoretical limits on WebSockets, but other factors that can limit the number of WebSockets, for example, maximum simultaneous requests allowed per CPU (a.k.a. maxConcurrentRequestsPerCpu): 7,500 per small VM, 15,000 per medium VM (7,500 x 2 cores), and 75,000 per large VM (18,750 x 4 cores). For more details, see Azure Web App sandbox · projectkudu/kudu Wiki · GitHub.
Additionally, the platform might throttle requests to protect against DDoS attacks when the request rate is unusually high, this protects at layer 3 and layer 4 network layers. For web application protection at layer 7, it is recommended to add protection at the application layer using a WAF(web application firewall) offering.
If you suspect that the app's requests are dropping due to the DDoS protection, you can mitigate this issue through the following operations:
- If the app service is deployed in the App Service Environment (ASE), you can scale up the Front End instance count to reduce the inbound connection rate per instance.
- In a multi-tenant environment which is outside of App Service Environment (ASE), such as in the Standard, Premium, Premium2, and Premium3 pricing tiers, we don't have control over the Frontend instance count. In this case, an alternative approach is to create a traffic manager and deploy multiple Azure App Services across different scale units. By using the traffic manager, we can split the incoming requests to different App Services, effectively distributing the load.
Outbound connections
The Azure App Service has two types of limitations for outbound connections: Outbound TCP connections and Source Network Address Translation (SNAT). If you encounter intermittent connection issues from the app service to external resources, it is recommended to investigate both of these limitations as potential causes.
1. Outbound TCP connections:
(1) What is the threshold for outbound TCP connections?
The threshold on outbound TCP connections varies based on the specific pricing tier:
| Limit Name | Description | Small(A1) | Medium(A2) | Large(A3) | Isolated (ASE) |
| Connections | Number of connections across entire VM | 1920 | 3968 | 8064 | 16,000 |
(2) Where can I check the outbound TCP connection usage?
Please navigate to the Azure App Service Diagnose and solve problems and search with word "TCP" and select TCP Connections.
(3) What does the loopback mean in the outbound TCP connection?
The loopback connection in this context primarily refers to the connection between the IIS (Internet Information Services) process and the application process, such as a .NET Core application running out of process. Specifically, the loopback connection is established between IIS and the 'dotnet.exe' process. It's important to note that loopback connections are counted as part of the overall outbound connections.
When the number of loopback connections is high, it often indicates that the application process is struggling to handle incoming requests within the expected timeframe, leading to a buildup of connections. In such cases, it is advised to investigate whether the application is experiencing slow or unresponsive behavior before immediately assuming that the outbound connection limit has been reached.
By focusing on identifying and addressing any performance issues within the application, we can typically resolve the accumulation of loopback connections effectively.
2. SNAT (Source Network Address Translation)
(1) What is SNAT?
When the Azure App Service connects to the outside through the public network, the platform needs to translate the worker instance's local private IP address to the load balancer's public IP address. And Azure uses Source Network Address Translation (SNAT) for outbound connections.
(2) What is the threshold of the SNAT?
The guaranteed threshold for SNAT in Azure App Service is 128 per instance. In some cases, the threshold may be higher if the platform has more available ports in that specific scale unit. However, it is crucial to ensure that the total sum of all apps running on the same machine does not exceed 128 connections to prevent any potential failures in the future
(3) Where can I check the SNAT usage?
Two diagrams are provided below. If there are any pending or failed connections, it indicates that the threshold was hit.
(4) How to avoid the SNAT exhausted issue?
Since each connection to the same destination IP and port utilizes a Source Network Address Translation (SNAT) port, we can initially attempt to mitigate this issue at the application level. For example, implementing connection pooling and reusing connections can help reduce the utilization of SNAT ports at the source. If it is not feasible to reduce the SNAT usage within the threshold at the application level, we can consider one of the following two options:
a. Using a private network, such as integrating the App Service with a Virtual Network (VNET), allows for outbound connections from the App Service to go through the VNET, instead of the public network, so the SNAT will not involved.
b. Scale out the worker instance number, since SNAT is a machine level resource, adding more machine can increase the SNAT count of the service plan.
(5) What is the difference between SNAT and outbound TCP connections?
a. The SNAT is applicable when the site is connecting to external resources through the public network. It is responsible for translating the source IP address and port for outbound traffic. On the other hand, the outbound TCP connection count includes all connections, regardless of whether they are using public or private networks. This count encompasses both outbound connections to external resources and loopback connections within the same machine.
b. A SNAT port can be shared by different flows, if the flows are different in either protocol, IP address or port. The TCP Connections metric counts every TCP connection.
c. The threshold for outbound TCP connections differs based on the price tier of the App Service. Higher price tiers typically have a higher threshold for outbound TCP connections. However, once set, the threshold value remains fixed within that specific price tier. On the other hand, the Source Network Address Translation (SNAT) threshold is the same across all types of machines (Small, Medium, Large instances) within a multi-tenant environment. While the scale unit may allocate more SNAT ports if they are available, it is recommended to always set the value below the threshold of 128 to prevent any potential connection issues that may arise later.
(6) If I can set up an alert for those result exhaustion?
No, currently those metrics are only available in the Azure App Service logs and are not integrated into Azure Monitor Metrics. As a result, we cannot use that data for setting up alerts. Hopefully, in the future, we will have the capability to utilize these metrics for it.
TLS Version
(1) What is the TLS version supported for Azure App service?
The Azure app service is support inbound TLS version 1.0, 1.1 and 1.2. TLS 1.3 is not yet available yet. We are working on making this available.
(2) How to update the TLS version for Azure App Service?
For the inbound TLS version, we can update at the platform.
If the App Service is deployed in the multi-tenant environment (not ASE), we can update the TLS version at the Configuration => General Settings as below:
If the App Service is deployed in the ASE, we need to update at 2 places:
a. App level: It is the same as multi-tenant environment, we can update at the configuration tab of the Azure App service on the portal;
b. ASE level: We can disable TLS 1.0 and TLS 1.1 and change TLS cipher suite order.
For outbound connections in Azure App Services, the TLS version is not explicitly defined on the platform side. Instead, it is determined by the application code and the TLS version supported by the operating system (OS). The default TLS version for Windows Azure App Service, which is based on Windows 10, is TLS 1.2. Additionally, TLS 1.0 and TLS 1.1 are supported.
Such as for the .Net application, if it is using .NET Framework 4.7 and later versions, it configured to use TLS 1.2 by default, and allow connections using TLS 1.1 or TLS 1.0. Therefore, in the case of .NET Framework 4.7 running on Windows Azure App Service, TLS 1.2 is the default TLS version.
(3) Why my app started rejected by the dependency service due to the lower TLS version without doing any changes?
The App service may have been connected with that lower TLS version, but the dependency service has upgraded the required TLS version, which caused the connection rejected. Such as, the depreciation of TLS versions in two common dependency services: TLS version for Key Vault and TLS version change for Azure AD.
We do not recommend hardcoding the TLS version in the application code level. However, if it is unavoidable and you need to specify a protocol version, we strongly recommend using TLS 1.2
If your application is written in .NET Framework and you are unsure about the presence of TLS version settings in the application code, you can refer to this guidance(Solving the TLS 1.0 Problem white pape) on how to identify and remove TLS 1.0. You can also refer to Transport Layer Security (TLS) best practices with the .NET Framework.
Reference: