Overview
In the Azure cloud ecosystem, resource efficiency is a key design principle. However, some default behaviors designed to conserve resources can introduce significant operational and security risks if not managed correctly. One such setting is the “Always On” configuration within Azure App Service. By default, an App Service instance may enter an idle state and unload its application process after a period of inactivity to free up resources.
This behavior, while logical for development or test environments, is problematic for production workloads. When an idle application receives a new request, it must perform a “cold start”—reloading the application process and its dependencies, which introduces significant latency. For any business-critical application, this delay is unacceptable. Enabling the “Always On” feature prevents the application from becoming idle, ensuring it remains loaded in memory and ready to respond instantly. This simple configuration is a cornerstone of maintaining a reliable and secure application posture in Azure.
Why It Matters for FinOps
From a FinOps perspective, the “Always On” setting directly impacts business value and operational efficiency. The cost of not enabling this feature often outweighs the marginal savings from allowing an application to idle. The primary business impact comes from degraded performance and reliability. The latency caused by cold starts can lead to a poor user experience, customer churn, and potential loss of revenue.
Furthermore, these performance issues can lead to breaches of Service-Level Agreements (SLAs), resulting in financial penalties and reputational damage. Operationally, troubleshooting intermittent application slowness caused by cold starts creates significant drag on engineering teams, increasing the Mean Time to Resolution (MTTR) and pulling resources away from value-generating work. Inconsistent application behavior also undermines the ability to establish reliable unit economics, as performance metrics become skewed and unpredictable.
What Counts as “Idle” in This Article
In the context of this article, an “idle” Azure App Service is one whose worker process has been unloaded by the platform due to a lack of incoming HTTP requests. This typically occurs after a default 20-minute timeout. When this happens, the application is effectively asleep.
The primary signals that an application has been idle are a sudden, sharp increase in response time for the first request after a period of inactivity (the “cold start”) and the unexplained failure of background tasks. For FinOps and engineering teams, these signals indicate a misconfiguration that creates both performance waste and operational risk. The goal is to eliminate this state entirely for any application that requires consistent availability.
Common Scenarios
Scenario 1: Low-Traffic Production Applications
Internal business applications, such as HR portals or administrative dashboards, often experience sporadic traffic. While they are critical when needed, they can go for long periods without requests. Without “Always On,” nearly every user interaction will trigger a slow cold start, frustrating users and making the application feel unreliable.
Scenario 2: Applications with Critical Background Jobs
Many applications rely on Azure WebJobs to perform essential background tasks like processing data queues, sending notifications, or running security scripts. These jobs run within the same process as the web app. If the application idles, the process is terminated, and the WebJobs stop running, leading to data processing gaps, failed security checks, and operational blind spots.
Scenario 3: API Endpoints and Microservices
In a microservices architecture, APIs serve as the connective tissue between different services. An API backend that serves a mobile app or another critical service must be instantly responsive. A delay of several seconds caused by a cold start in one API can cascade through the system, causing timeouts and failures in dependent applications.
Risks and Trade-offs
The primary risk of disabling “Always On” is unreliable performance and the failure of critical background processes. This directly impacts availability, a core pillar of application security and reliability. Gaps in background processing can lead to data inconsistency and security vulnerabilities, such as the failure to ship logs to a SIEM or purge sensitive data from a cache.
This unreliability can also lead to compliance risks. Frameworks like SOC 2 and PCI-DSS require consistent system availability and reliable logging. If an application idles and stops sending security telemetry, it may fall out of compliance. The main trade-off is cost; “Always On” is a feature of Basic, Standard, and Premium App Service plans and ensures the instance is always active. While disabling it in a non-critical development environment might be a valid cost-saving measure, the risk of doing so in production or staging environments is almost never worth the minimal savings.
Recommended Guardrails
Effective FinOps requires establishing governance to prevent costly misconfigurations. Implementing automated guardrails is the best way to enforce the “Always On” setting for critical workloads.
The primary tool for this is Azure Policy. Create a custom policy to audit or deny the deployment of any App Service on a Basic, Standard, or Premium plan that does not have “Always On” enabled. This proactive approach prevents the issue from occurring in the first place. Complement this with a robust tagging strategy that clearly identifies application owners and environments (e.g., prod, staging). This allows for targeted alerting and helps FinOps teams manage budgets by associating costs with the correct business units.
Provider Notes
Azure
The “Always On” feature is a configuration within an Azure App Service Plan. It is available for applications hosted in the Basic, Standard, and Premium pricing tiers. When enabled, the Azure load balancer ensures the application’s worker process is never unloaded due to inactivity.
This setting is particularly crucial for applications that use Azure WebJobs for background processing, as these jobs depend on the host application being active to execute reliably. You can configure the Always On setting through the Azure Portal, ARM templates, Bicep, or other Infrastructure as Code tools.
Binadox Operational Playbook
Binadox Insight: The “Always On” setting is not just a performance tweak; it is a fundamental control for operational stability and security. Treating it as optional in production environments introduces hidden costs through operational drag, poor user experience, and increased security risks, ultimately degrading your unit economics.
Binadox Checklist:
- Audit all Azure App Services running on Basic, Standard, and Premium plans.
- Verify that “Always On” is enabled for all production and pre-production workloads.
- Identify any applications using continuous or scheduled WebJobs and confirm “Always On” is active.
- Implement an Azure Policy to audit for any new or existing App Services that violate this configuration.
- Review cost allocation for App Service Plans to ensure the business value justifies the tier selection.
- Document the “Always On” requirement as part of your organization’s cloud deployment standards.
Binadox KPIs to Track:
- Reduction in P95 and P99 application response latency.
- Successful execution rate of critical background WebJobs.
- Number of Azure Policy violations for the “Always On” setting over time.
- Reduction in support tickets related to “intermittent application slowness.”
Binadox Common Pitfalls:
- Forgetting to enable “Always On” in staging, leading to inaccurate performance tests that don’t reflect production behavior.
- Assuming the setting is enabled by default for all service tiers.
- Disabling “Always On” in a production environment as a cost-saving measure without understanding the severe impact on reliability.
- Failing to use Infrastructure as Code to manage the setting, leading to configuration drift.
Conclusion
Enabling the “Always On” setting in Azure App Service is a simple but powerful action that enhances application availability, security, and performance. For FinOps practitioners and cloud engineers, it represents a low-effort, high-impact optimization that prevents operational waste and protects business value.
By understanding its importance and implementing automated guardrails to enforce it, your organization can build more resilient, reliable, and cost-effective applications on Azure. Make this configuration a non-negotiable standard for all your critical workloads.
7-day free trial