Understanding 'Always On' vs. Health Check in Azure App Service
The 'Always On' feature in Azure App Service helps keep your app warm by ensuring it remains running and responsive, even during periods of inactivity with no incoming traffic. As this feature pings to root URI after every 5 minutes. On Other hand Health-check feature helps pinging configured path every minute to monitor the application availability on each instance. What is 'Always On' in Azure App Service? The Always On feature ensures that the host process of your web app stays running continuously. This results in better responsiveness after idle periods since the app doesn’t need to cold boot when a request arrives. How to enable Always On: Navigate to the Azure Portal and open your Web App. Go to Configuration > General Settings. Toggle Always On to On. What is Health Check in Azure App Service? Health check increases your application's availability by rerouting requests away from instance where application is marked unhealthy and replacing instances if they remain unhealthy. How to enable Health-Check: Navigate to the Azure Portal and open your Web App. Under Monitoring, select Health check. Select Enable and provide a valid URL path for your application, such as /health or /api/health. Select Save. So, is it still necessary to enable the 'Always On' feature when Health Check is already pinging your application every minute? -> Yes, please find below explanation for the same. Test App scenario: Health Check enabled (pointing to /health_check path) and Always On disabled. Started the app and sent some user requests. Observations from the Test: After the application starts up, health check pings begin following the end user's request. Please find below table representing Health-check pings following user's request to root URI. Time Bucket URL Status Request Count 2025-03-20 07:00:00.0000000 / 200 6 2025-03-20 07:00:00.0000000 /health_check 200 30 2025-03-20 07:30:00.0000000 /health_check 200 30 Subsequent Health-check pings will continue, even in the absence of user requests. However, after restarting the app and in the absence of any user requests, we observed that Health Check requests were not initiated. This indicates that Health Check does not start automatically unless application is actively running and serving requests. Conclusion: Always On ensures that the app is proactively kept warm by sending root URI pings, even post-restart. The health-check feature is useful for monitoring application availability when the application is active. However, after a restart, if the application isn't active due to a lack of requests, Health-check pings won't initiate. Therefore, it is highly recommended to enable Always On, particularly for applications that need continuous availability and to avoid application process unload events. Recommendation: Enable Always On alongside Health Check to ensure optimal performance and reliability.Introducing the 'Session Affinity Proxy' setting in App Service Configuration.
From our own metadata and experience at Microsoft, we know that a considerable number of our customers use App Service behind one of our reverse proxy solutions, such as Azure Application Gateway or Azure Front Door. In simple terms, this means that when our customers have an App Service, it often runs as part of the backend pool of an Azure Application Gateway or is configured as the origin in an Azure Front Door profile, which is great because this setup is beneficial for several reasons. Firstly, it enhances security by obfuscation. With a reverse proxy in the data path, clients only contact the reverse proxy instances and are unaware of the second connection between the reverse proxy instances and the real backend. This unrevealed internal architecture reduces the attack surface for malicious actors. Secondly, the reverse proxy can act as the TLS termination point, offloading the TLS handshake, encryption, and decryption from the App Service. This reduces the TLS computational load on the App Service and simplifies the management of TLS certificates, through Key Vault. Thirdly, the reverse proxy can load balance and distribute incoming client requests across multiple backend servers or origins, improving performance and ensuring no single server is overwhelmed, making scalability attainable. Finally, if Azure Front Door is used as the reverse proxy solution, it can also act as a cache, reducing the load on backend servers by serving content directly from the reverse proxy POPs (Point of Presence) servers, which improves response times for users, as the content is served directly from a location closer to the user, which is faster than contacting the origin. As we can see, using a reverse proxy like Azure Application Gateway or Front Door before an App Service, seems very convenient, but there is a drawback: maintaining session affinity and authentication can be challenging if custom domains are not being used in the App Service configuration. This is because in a reverse proxy scenario, instead of one connection we have two: one between the client and the reverse proxy, and another one between the reverse proxy and the backend / origin and maintaining the original information across those different connections is a challenge. What is the problem that we are trying to resolve with the new "Session Affinity Proxy" setting? When employing a reverse proxy to front App Services, clients typically utilize a custom domain that directs to the proxy´s IP address, while communication between the proxy and the backend App Services occurs via the default App Services domain name. Although this configuration is generally effective, it may present challenges when employing advanced configurations such as Session Affinity or Authentication within App Services (explained further in this article). To address these issues and ensure that an App Services deployment is reverse-proxy aware -utilizing the same domain name requested by the client to the proxy- a new configuration was recently introduced, beggining with Session Affinity cookies. First, let´s clarify what "Cookie-Based Affinity" Means. A "Cookie Based Affinity," also known as a "sticky session" or "session persistence," is a technique used to ensure that a client's requests are always sent to the same server. This is particularly important in scalable environments where web servers instances are added dynamically and hosted applications store user data in session variables or in a local cache, commonly referred to as a stateful application. Therefore, maintaining the "Session Affinity" is crucial for stateful applications that can use cookies to store important session information. If we send the request to a server without the stored sessions variables, the application logic can break, session state can get lost, authentication can fail, or back-end URLs can inadvertently be exposed to end users. Why maintaining "Session Persistence" challenging in scenarios with an App Service behind a reverse proxy without custom domains? Let´s use below diagram as an example for further explanation. In this diagram, we need to consider that Session Affinity (ARR) in App Services is enabled When the clients send the request to Application Gateway or Front Door (1), they send it with a host value in the request header equal to "constoso.com", that is different from the hostname configured in the backend "contoso.azurewebsites.net" (2). The HTTP Response from the backend (3) includes affinity cookies with a default domain name of "contoso.azurewebsites.net" (ARR enabled in the configuration of App Service) that differs from the original one "contoso.com". Due to security reasons, clients do not accept a cookie with the default domain name "contoso.azurewebsites.net" in the response (4) because its domain differs from the original, and therefore the "sticky session" is not maintained and the stateful application is broken. The new "Session Affinity Proxy" setting to the rescue For solving the problem that we have described above, we are introducing the "Session Affinity Proxy" setting in the App Service configuration. This is the portal view of the new setting: And you can also enable it via az cli: az resource update –name <app-name> --resource-type "Microsoft.Web/sites" -g <resource-group-name> --set properties.clientAffinityProxyEnabled=true This new property is available for the following services Web App Functions /Logic Apps (Standard) The new App Services property "clientAffinityProxyEnabled" that you set when you choose from the Portal "Session affinity proxy: On", in the configuration of a Web App, Function, or Logic App (or when you activate it via CLI) is a boolean setting that provides an out-of-the-box experience by setting cookie domain name based on incoming requests as seen by Application Gateway/Front Door. The following illustration demonstrates how this new solution works: As you can see when we enable the setting, we are sending the original domain (as seeing by the client) from the reverse proxy to the backend. As we know the original value, we are capable when we sent the HTTP Response from the backend to includes affinity cookies that contain the original hostname (contoso.com) rather than the configured one (contoso.azurewebsites.net) and therefore these cookies are not going to be rejected by the clients as they contain the expected hostname. This is a straightforward configuration that resolves the problem of "Cookie Based Affinity" and allows to work without custom domains configured on the App Service. Before this setting was introduced, our recommended solution was to use always custom domains as per this documentation, but with the new configuration setting "Session Affinity Proxy: On", we have a solution that just work with one click and reduces the complexity of configuration for our customers. This simplifies the process significantly and provides a seamless experience for users, eliminating the need for additional setup while ensuring consistent session affinity.
