Microsoft Azure — App Services (Web Apps)

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers app services (web apps) with production-ready configurations, best practices, and hands-on examples.

Azure App Services: The Production-Ready Web Host

Azure App Service is a fully managed platform for building, deploying, and scaling web apps. It supports multiple languages ( .NET, Java, Node.js, Python, PHP) and provides built-in auto-scaling, load balancing, and security. For production workloads, App Service offers high availability with SLA guarantees (99.95% for multi-instance deployments). The service handles OS patching, infrastructure maintenance, and traffic management, letting you focus on code. However, it's not a silver bullet: you must understand its limitations, such as the 240-second request timeout for unresponsive apps and the lack of true SSH access in the Free/Shared tiers. For production, always use at least the Basic tier with a minimum of two instances to meet the SLA.

az webapp create \
  --resource-group myResourceGroup \
  --plan myAppServicePlan \
  --name myUniqueAppName \
  --runtime "NODE|18-lts" \
  --sku B1

Deployment Slots: Zero-Downtime Deployments Done Right

Deployment slots are separate environments within your App Service that allow you to stage changes before swapping them into production. The standard pattern: deploy to a staging slot, run smoke tests, then swap. The swap operation is instant because it switches the routing rules between slots. Slot-sticky settings (connection strings, environment variables) follow the slot, not the app content. This is critical for production: you can keep your staging slot pointing to a test database while your production slot points to the real one. After swap, the previous production slot becomes the new staging slot, allowing quick rollback if needed. Always enable auto-swap for CI/CD pipelines to reduce manual errors.

az webapp deployment slot create \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --slot staging \
  --configuration-source myUniqueAppName

az webapp deployment source config-zip \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --slot staging \
  --src ./app.zip

az webapp deployment slot swap \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --slot staging \
  --target-slot production

Auto-Scaling: Rules That Actually Work

Auto-scaling in App Service adjusts the number of instances based on metrics like CPU, memory, or request count. For production, define scaling rules with care: use a scale-out condition that triggers at 70% CPU for 10 minutes, and a scale-in condition at 30% CPU for 30 minutes. The longer cool-down for scale-in prevents thrashing. Always set instance limits: a minimum of 2 (for SLA) and a maximum that matches your budget and backend capacity. Remember that scaling out adds instances, not resources per instance. If your app is CPU-bound, scaling out helps; if it's I/O-bound, consider scaling up (larger instance size) instead. Test your scaling rules under load before going live.

{
  "autoscale": {
    "enabled": true,
    "profiles": [
      {
        "name": "Default",
        "capacity": {
          "minimum": "2",
          "maximum": "10",
          "default": "2"
        },
        "rules": [
          {
            "metricTrigger": {
              "metricName": "CpuPercentage",
              "metricResourceUri": "/subscriptions/.../sites/myUniqueAppName",
              "timeGrain": "PT1M",
              "statistic": "Average",
              "timeWindow": "PT10M",
              "timeAggregation": "Average",
              "operator": "GreaterThan",
              "threshold": 70
            },
            "scaleAction": {
              "direction": "Increase",
              "type": "ChangeCount",
              "value": "1",
              "cooldown": "PT5M"
            }
          },
          {
            "metricTrigger": {
              "metricName": "CpuPercentage",
              "metricResourceUri": "/subscriptions/.../sites/myUniqueAppName",
              "timeGrain": "PT1M",
              "statistic": "Average",
              "timeWindow": "PT30M",
              "timeAggregation": "Average",
              "operator": "LessThan",
              "threshold": 30
            },
            "scaleAction": {
              "direction": "Decrease",
              "type": "ChangeCount",
              "value": "1",
              "cooldown": "PT10M"
            }
          }
        ]
      }
    ]
  }
}

Application Settings and Connection Strings: Secure Configuration Management

App Service allows you to define application settings and connection strings as key-value pairs in the portal or via CLI. These are injected as environment variables at runtime. For production, never hardcode secrets in your code. Use slot-sticky settings for environment-specific values (e.g., database connection strings). For sensitive data, use Azure Key Vault references instead of plain text. The format is @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/). This integrates with managed identities, so no credentials are stored in App Service. Always enable 'slot setting' for Key Vault references to ensure they stay with the correct slot.

az webapp config appsettings set \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --slot staging \
  --settings "DB_CONNECTION=@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/db-connection/)" \
  --slot-settings

Custom Domains and SSL: HTTPS Without the Headache

App Service supports custom domains with SSL/TLS certificates. You can upload your own certificate or use a free App Service Managed Certificate (for non-wildcard domains). For production, always enforce HTTPS and disable FTP. Use the 'HTTPS Only' setting and set the minimum TLS version to 1.2. For custom domains, you need to verify ownership by adding a TXT or CNAME record in your DNS. After verification, bind the domain to your app. For SSL, if using a managed certificate, it auto-renews. If using your own, you must upload before expiry. Use Azure Front Door or Application Gateway for advanced TLS termination and WAF capabilities.

az webapp config hostname add \
  --resource-group myResourceGroup \
  --webapp-name myUniqueAppName \
  --hostname www.mycompany.com

az webapp config ssl upload \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --certificate-file ./mycert.pfx \
  --certificate-password "mypassword"

az webapp config ssl bind \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --certificate-thumbprint <thumbprint> \
  --ssl-type SNI

Monitoring and Diagnostics: Logging That Saves Your Weekend

App Service provides built-in diagnostics: application logging (filesystem or blob), web server logging, and detailed error pages. For production, enable application logging to Azure Blob Storage with a retention policy. Use the 'Log stream' feature for real-time debugging. Set up alerts on metrics like HTTP 5xx errors, response time, and CPU. Integrate with Application Insights for distributed tracing and performance monitoring. Always configure failed request tracing to capture stack traces for 4xx and 5xx errors. Without proper logging, debugging production issues is guesswork.

az webapp log config \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --application-logging filesystem \
  --level verbose \
  --web-server-logging filesystem \
  --detailed-error-messages true \
  --failed-request-tracing true

az monitor metrics alert create \
  --resource-group myResourceGroup \
  --name "High HTTP 5xx" \
  --condition "count Http5xx > 10" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action-groups /subscriptions/.../actionGroups/myActionGroup

Backup and Restore: Your Safety Net

App Service can automatically back up your app's content and configuration to an Azure Storage account. Backups include the web app files, databases (if configured), and app settings. For production, schedule daily backups with a retention of at least 7 days. Backups are incremental after the first full backup. To restore, you can create a new app or overwrite the existing one. Always test your restore process. Backups do not include your custom domain bindings or SSL certificates, so you'll need to reconfigure those after restore. Also, backups are not available in Free or Shared tiers.

az webapp config backup update \
  --resource-group myResourceGroup \
  --webapp-name myUniqueAppName \
  --container-url https://mystorage.blob.core.windows.net/backups \
  --frequency 1d \
  --retention 7 \
  --enabled true

Security Hardening: Beyond the Basics

Production App Services need more than just HTTPS. Implement IP restrictions to whitelist only necessary IP ranges. Use Access Restrictions (in Networking) to block all traffic except from your VNet or specific IPs. Enable Azure AD authentication for your app to offload identity management. Use Managed Identity to access Azure resources (Key Vault, SQL Database) without storing credentials. Disable FTP and SCM basic auth; use Azure AD for SCM site access. Set the 'ARR Affinity' cookie to off if your app is stateless (it can cause uneven load distribution). Finally, enable 'Always On' to prevent idle timeout, but be aware it keeps the app loaded.

az webapp config access-restriction add \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --rule-name "Allow Corp IP" \
  --action Allow \
  --ip-address 203.0.113.0/24 \
  --priority 100

az webapp config set \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --ftps-state Disabled \
  --always-on true

az webapp auth update \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --enabled true \
  --action LoginWithAzureActiveDirectory \
  --aad-allowed-token-audiences https://myUniqueAppName.azurewebsites.net

Scaling Up: When to Choose Premium Tier

The Premium tier (P1v3, P2v3, P3v3) offers dedicated instances with faster CPUs, more memory, and SSD storage. It also supports private endpoints, VNet integration, and up to 30 instances. Choose Premium when your app requires high throughput, low latency, or compliance with network isolation. Premium V3 instances use the latest hardware and provide up to 60% better performance per dollar compared to Standard. For production apps with consistent high load, Premium is often more cost-effective than scaling out many Standard instances. However, Premium costs more per instance, so evaluate your workload patterns.

az appservice plan update \
  --resource-group myResourceGroup \
  --name myAppServicePlan \
  --sku P1v3

CI/CD Integration: Automate Everything

Azure App Service integrates with GitHub Actions, Azure DevOps, Bitbucket, and local Git. For production, use a CI/CD pipeline that builds, tests, and deploys to a staging slot, then swaps to production. Use Azure DevOps Pipelines or GitHub Actions with environment approvals for gated deployments. Always run integration tests against the staging slot before swap. Use Infrastructure as Code (ARM templates or Bicep) to define the App Service and its configuration. Never manually configure production; it leads to configuration drift. Store your ARM templates in source control.

trigger:
- main

variables:
  azureSubscription: 'my-service-connection'
  appName: 'myUniqueAppName'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - script: npm install && npm run build
    - task: ArchiveFiles@2
      inputs:
        rootFolderOrFile: '$(System.DefaultWorkingDirectory)'
        includeRootFolder: false
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
    - publish: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
      artifact: drop

- stage: DeployToStaging
  dependsOn: Build
  jobs:
  - deployment: Deploy
    environment: 'staging'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: '$(azureSubscription)'
              appName: '$(appName)'
              slotName: 'staging'
              package: '$(Pipeline.Workspace)/drop/$(Build.BuildId).zip'

- stage: SwapToProduction
  dependsOn: DeployToStaging
  jobs:
  - deployment: Swap
    environment: 'production'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureAppServiceManage@0
            inputs:
              azureSubscription: '$(azureSubscription)'
              appName: '$(appName)'
              action: 'Swap Slots'
              sourceSlot: 'staging'
              targetSlot: 'production'

Troubleshooting Common Production Issues

Common production issues include: 500 errors due to missing app settings, slow response times from insufficient instances, and app crashes from memory leaks. Use the 'Diagnose and Solve Problems' blade in the portal. Check the 'Application Logs' stream for exceptions. For high CPU, use the 'Profiler' in Application Insights to find hot paths. For memory leaks, enable 'Memory Dump' collection. If your app is unresponsive, check the 'Health Check' feature (in Premium tier) to remove unhealthy instances. Always have a rollback plan: keep the last known good deployment in a slot.

az webapp log tail \
  --resource-group myResourceGroup \
  --name myUniqueAppName \
  --slot staging

Cost Management: Avoiding Surprise Bills

App Service costs are based on the App Service Plan tier and number of instances. To control costs: right-size your plan (monitor CPU/memory usage), use reserved instances for 1- or 3-year terms (up to 40% savings), and set auto-scaling limits. Delete unused slots and apps. Use the Azure Cost Management + Billing to set budgets and alerts. For dev/test, use Dev/Test pricing (if you have Visual Studio subscription). Remember that Premium tier costs more but may reduce instance count. Always estimate costs before deploying.

az pricing show \
  --sku P1v3 \
  --location eastus \
  --product-name "App Service"