Azure App Services
A feature of Azure App Service used to create and deploy scalable, mission-critical web apps.
4,611 questions
@Mark Wright , Thanks for posting this good question. First of all, please accept my Apologies for the delayed response.
--Primarily, to clarify, “Always On” feature itself is not charged. For Basic and higher App Service Plan (tiers), you're paying for the entire VM (and the feature offers) anyways.
In Azure App Service, you get billed for the App Service Plan and not the Web App.
The pricing tier of an App Service Plan (ASP) determines what App Service features you get and how much you pay for the plan.
--Just to highlight further on the “Always On’ feature – The Web Apps are unloaded but not stopped. With this feature/ that is when Always On is turned on, the front-end load balancer sends a GET request to the application root every five minutes. The continuous ping prevents the app from being unloaded.
--With “Always On” disabled - This way, the system can conserve resources. The downside is that the response to the first request after the web app is unloaded is longer, to allow the web app to load and start serving responses. // Only in Basic and above App Service Plans (ASP), you can turn on the Always On setting.
As Zain Rizvi mentioned (here) - " The only possible way - Always On could increase your bill is if you have Auto Scale enabled based on Memory Consumption or something.
Having a whole bunch of sites set to always be on might trigger the Auto Scale mechanism to add another instance (VM) to your Web Hosting Plan, resulting in a higher bill. "
Monitoring and Alerts:
1.From Azure App Service -Activity Log, you can also view “Start Web App” and “Stop Web App” operations.
https://learn.microsoft.com/azure/app-service/monitor-app-service-reference#activity-log
@ajkuma Thank you for your detailed reply.
I do find it quite confusing however. If there is no cost benefit of the app unloading then what possible reason is there that this is a useful feature? It is only because I was under the impression that an unloaded app was not being billed that this feature serves any purpose.
That aside I can see no entry in any of the log areas you mention to indicate that our apps have loaded or unloaded. We have all our apps connected to AppInsights and routing to Log Analytics workspaces. Also all diagnostic logs are being captured to the Log Analytics workspaces so we can see all app activity in there. I cannot find any log that includes an entry for the unloading of any of the apps.
Having said all that - we were only looking for the logs to know when we might be saving cost so as that will not be happening the lack of the logging becomes completely irrelevant.
@Mark Wright , Thanks for the follow-up. Apologies for any confusion.
-The Always On helps in keeping the App Service in an active (loaded) state by continuously pinging it every 5 minutes. What it means is - The continuous pings in turn help in keeping the application’s worker process active and hence it does not terminate.
-For an App Service which does not have AlwaysOn and no active requests for ~20 minutes, the App Service’s worker process would shut down.
So, in this case -- On a new request * *another worker process* would be spawned up causing a cold start.** - You can avoid that cold start by Always ON.
There are no direct logs which clearly mention this state. You may check the worker process’s PID | list process which could be good indication - if there were no requests for sometime nor there were no events like stop/start/restart/crash etc.
As mentioned above, you are paying for the App Service Plan tier on which the App Service is running. Always On is a feature for higher tiers ( there is no cost for this feature itself).
To benefit the community find the right answers, please do mark the post which was helpful by clicking on ‘Accept Answer’ & ‘Up-Vote’.