Azure Cost Analysis: Impact of “Always On” Feature on Standard Web Hosting Plans with Multiple Sites


2 views

In Azure App Service, the "Always On" setting prevents your web apps from being unloaded due to inactivity. This is particularly important for:

  • Applications with long initialization times
  • Scheduled job runners
  • Low-traffic but critical applications

When hosting 32 websites on a Standard tier with Small instance size:

// Sample ARM template snippet for reference
{
  "name": "[variables('hostingPlanName')]",
  "type": "Microsoft.Web/serverfarms",
  "sku": {
    "name": "S1",
    "tier": "Standard",
    "size": "S1",
    "family": "S",
    "capacity": 1
  }
}

Key cost factors to consider:

Feature Without Always On With Always On
Compute Hours Charged when active Continuous charging
Warm Starts Possible cold starts Consistent performance
Resource Utilization Variable Consistent baseline

For your scenario with 32 websites:

  • Enabling "Always On" for one site affects the entire App Service Plan
  • The Small (S1) instance has:
    • 1.75GB memory
    • 100 ACU
  • Memory pressure becomes critical with many sites
// PowerShell snippet to check site activity
Get-AzWebApp -ResourceGroupName "YourRG" | ForEach-Object {
  $metrics = Get-AzMetric -ResourceId $_.Id -MetricName "Requests" -TimeGrain 00:01:00
  $activity = $metrics.Data | Measure-Object -Property Total -Average
  [PSCustomObject]@{
    SiteName = $_.Name
    AvgRequests = $activity.Average
    Recommendation = if ($activity.Average -lt 5) { "Disable Always On" } else { "Enable Always On" }
  }
}

Best practice approach:

  • Enable "Always On" only for sites with >5 requests/minute average
  • Consider separating highly active sites to separate plans
  • Monitor memory usage with:
// Azure CLI command
az monitor metrics list --resource <plan-id> --metric "MemoryPercentage"

html

The "Always On" feature in Microsoft Azure App Service ensures your application remains loaded even during periods of inactivity. This prevents cold starts and maintains consistent performance, particularly for applications with sporadic traffic. By default, Azure unloads idle apps after 20 minutes to conserve resources.

When hosting 32 websites in a Standard tier with Small instance size, enabling "Always On" affects costs differently than in lower tiers:

  • No direct additional charge: Azure doesn't bill extra for the "Always On" toggle itself
  • Indirect costs: Prevents instance scaling to zero during idle periods
  • Resource utilization: Maintains continuous memory allocation for enabled sites

Consider this ASP.NET Core middleware example that demonstrates cold start impact:

// Startup.cs
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.Use(async (context, next) => {
        var timer = Stopwatch.StartNew();
        await next();
        timer.Stop();
        context.Response.Headers.Add("X-Processing-Time", timer.ElapsedMilliseconds.ToString());
    });
    
    // Additional middleware configuration
}

With "Always On" disabled, initial requests after idle periods may show significantly higher X-Processing-Time values due to JIT compilation and framework initialization.

For your 32-website scenario, implement selective activation:

// ARM template snippet for conditional Always On
{
  "resources": [{
    "type": "Microsoft.Web/sites/config",
    "name": "[concat(parameters('siteName'), '/web')]",
    "apiVersion": "2022-03-01",
    "properties": {
      "alwaysOn": "[if(equals(parameters('sitePriority'), 'high'), true, false)]"
    }
  }]
}

Use Azure CLI to compare usage patterns before/after enabling Always On:

az monitor metrics list --resource <resource-id> \\
--metric "MemoryWorkingSet" "AverageResponseTime" \\
--start-time 2023-06-01T00:00:00Z \\
--end-time 2023-06-30T23:59:59Z \\
--interval PT1H

Combine this with cost analysis in Azure Portal to track actual billing impact.