Introduction

In today’s digital world, ensuring that your web application remains available and performant—even in the face of failures or sudden traffic spikes—is critical. Azure App Service is a fully managed platform that offers built‑in resiliency features such as auto‑scaling, multi‑instance deployments, deployment slots for zero‑downtime releases, and integrated health monitoring. These architectural capabilities help Azure App Service achieve its Service Level Agreements (SLAs), offering uptime guarantees often around 99.95% or higher when deployed correctly.

In this post, we explore how these resiliency features contribute to meeting the SLA for Azure App Service. We will detail the requirements for deploying a highly available web application, including strategies for scaling out, traffic routing using Azure Traffic Manager or Front Door, and staging deployments with slots. Whether using the Azure Portal or deploying through Infrastructure-as-Code with Bicep, you will learn how to design, deploy, and monitor a resilient App Service setup.

Focus Areas

• Built‑in resiliency features that drive the SLA:
  Azure App Service achieves its high availability through several key features:

  • Auto‑scaling: Automatically adjusts the number of instances based on demand.
  • Multi‑instance deployments: Distributes your application across multiple compute instances to avoid a single point of failure.
  • Deployment slots: Allows for seamless staging and zero‑downtime updates by hosting multiple versions of your application.
  • Integrated health monitoring: Continuously monitors application performance and availability, enabling rapid response to issues.

• Key requirements for a robust, highly available web application:

  • Scaling Out: Deploy your app on multiple instances so that if one instance fails, others can handle the load.
  • Traffic Routing: Use Azure Traffic Manager or Azure Front Door to intelligently route user requests to the healthiest endpoint and provide global load balancing.
  • Staging Deployments: Leverage deployment slots to test new features in production-like environments without affecting live traffic.

Example Implementation

A. High Availability with Azure Portal

1. Create an App Service Plan and Web App:

   • Step 1: Sign in to the Azure Portal and click Create a resource.
   • Step 2: Search for and select App Service.
   • Step 3: In the Basics tab, enter your App name, select a subscription and resource group, and choose a region.
   • Step 4: Under App Service Plan, either create a new plan or select an existing one. For high availability, choose a plan in a supported tier (e.g., Standard or Premium) and ensure you set the instance count to at least two.

2. Configure Auto-scaling and Multi-instance Settings:

   • Step 5: Once your App Service is deployed, navigate to your App Service and then to Scale out (App Service plan).
   • Step 6: Configure an auto‑scale rule based on metrics such as CPU usage or HTTP queue length. This ensures your app can scale out dynamically during high load.

3. Set Up Deployment Slots:

   • Step 7: In your App Service settings, select Deployment slots.
   • Step 8: Click Add Slot, name it (for example, “staging”), and clone the configuration from the production slot. This permits zero‑downtime swaps between staging and production.

4. Integrate Traffic Routing:

   • Step 9: If global or regional traffic management is required, navigate to Create a resource and select Traffic Manager profile or Azure Front Door.
   • Step 10: Configure the traffic distribution rules to route users to the healthiest endpoint based on geographic latency and load.

B. High Availability with Bicep

Below is an example Bicep template that deploys an App Service Plan configured for multi-instance scaling and sets up a web app with a deployment slot.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90

// Parameters for Azure App Service deployment
@description('Name of the App Service Plan')
param appServicePlanName string = 'myAppServicePlan'

@description('Name of the Web App')
param webAppName string = 'myResilientWebApp'

@description('Name of the Deployment Slot')
param slotName string = 'staging'

@description('Name of the App Service Plan SKU Tier')
param skuTier string = 'Standard'

@description('Name of the App Service Plan SKU')
param skuName string = 'S1'

@description('DNS Name for the Traffic Manager Profile')
param trafficManagerDnsName string = 'myTrafficManagerDnsName' // Must be globally unique and will be prepended with .trafficmanager.net

@description('Name of the Traffic Manager Endpoint')
param trafficManagerEndpointName string = webAppName

@description('Resource Location')
param location string = resourceGroup().location

// Deploy an App Service Plan with a Standard tier (supports auto-scaling and multi-instance)
resource appServicePlan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: appServicePlanName
  location: location
  sku: {
    name: skuName
    tier: skuTier
    capacity: 2  // Ensures multiple instances are running
  }
}

// Deploy the main Web App
resource webApp 'Microsoft.Web/sites@2024-04-01' = {
  name: webAppName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      alwaysOn: true  // Keeps the app running continuously
    }
  }
}

// Deploy a Deployment Slot for staging
resource deploymentSlot 'Microsoft.Web/sites/slots@2024-04-01' = {
  parent: webApp
  name: slotName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
  }
}

// Deploy a Traffic Manager for routing your traffic to the Web App based on performance
resource trafficmanager 'Microsoft.Network/trafficmanagerprofiles@2022-04-01' = {
  name: trafficManagerDnsName
  location: 'global'
  properties: {
    profileStatus: 'Enabled'
    trafficRoutingMethod: 'Performance'
    dnsConfig: {
      relativeName: trafficManagerDnsName
      ttl: 30
    }
    endpoints: [
      {
        name: trafficManagerEndpointName
        type: 'Microsoft.Network/trafficmanagerprofiles/azureEndpoints'
        properties: {
          endpointStatus: 'Enabled'
          targetResourceId: webApp.id
          weight: 100
        }
      }
    ]
    monitorConfig: {
      port: 443
      protocol: 'HTTPS'
      path: '/'
      intervalInSeconds: 30
      timeoutInSeconds: 15
      toleratedNumberOfFailures: 3
    }
  }
}

Deployment Instructions:

1. Save the template as appServiceHighAvailability.bicep.

2. Open your terminal and ensure you’re logged in using:

   1

   az login

3. Deploy the template to your resource group:

   1 2 3

   az deployment group create \ --resource-group MyResourceGroup \ --template-file appServiceHighAvailability.bicep

This Bicep template provisions an App Service Plan with a Standard tier, ensuring it runs on at least two instances, deploys a web app with “always on” configuration, and creates a deployment slot for staging updates.

Conclusion

Designing a resilient web application in Azure begins with understanding how Azure App Service’s built‑in capabilities contribute to its SLAs. By deploying your application on a multi-instance App Service Plan, configuring auto‑scaling, creating deployment slots, and, if needed, integrating advanced traffic routing solutions, you can achieve robust availability—often meeting or exceeding the SLA benchmark of 99.95% uptime. Whether you’re using the intuitive controls of the Azure Portal or the automation capabilities of Bicep, these best practices ensure your applications remain consistently reliable and performant.

Learn More

• Azure App Service SLAs:
  Azure App Service SLA
• Overview of Azure App Service:
  Azure App Service Overview
• Auto-Scaling in Azure App Service:
  Scale out in Azure App Service
• Bicep Documentation:
  Bicep Language Overview