Configuring an App Service: Part 2

Overview#

This guide covers three key App Service operational configurations:

1. Scaling — scale up (bigger VM) and scale out (more instances)
2. Backups — platform-managed and custom backup strategies
3. Deployment slots — zero-downtime deployments, staging, and rollbacks

Scaling App Services#

App Service scaling is controlled through the App Service Plan, not the individual app.

Scale Up (Vertical Scaling)#

Change the App Service Plan tier to get a more powerful VM:

• Scales the underlying VM for all apps on the plan
• Choose when: app needs more processing power per instance

Scale Out (Horizontal Scaling)#

Add more instances of the app to handle increased traffic:

Rules-based is the recommended approach and works like Virtual Machine Scale Sets under the hood — adding and removing instances based on metric thresholds.

Example rule:

• Scale out when CPU > 80% for 5 minutes → add 2 instances
• Scale in when CPU < 25% for 10 minutes → remove 1 instance

Exam tip: Scale out is preferred over scale up for handling traffic spikes. Scale up is used for more compute power per instance.

Exam tip: App Service scale sets operate similarly to VM Scale Sets — this is actually what happens behind the scenes.

Backups#

Platform-Managed Backups (Automatic)#

• On by default for all App Services
• Runs every hour automatically
• Stored in an Azure-managed storage account (not accessible to you)
• Can be used to restore the app to a previous state

Custom Backups (Customer-Managed)#

Create your own backup configuration for more control:

• Your own storage account + blob container required
• Set custom backup schedule (e.g. every 6 hours, daily)
• Configure retention period (how long to keep backups)
• VNet integration: if using VNet integration, enable "backup and restore over VNet integration"

Restoring from Backup#

Best practice: Always restore into a deployment slot in production environments, not directly into the production slot.

Deployment Slots#

Deployment slots are separate app instances that run alongside your production app. They allow you to:

• Test new versions in a staging environment
• Perform zero-downtime deployments by swapping slots
• Instantly rollback by swapping back

Available on: Standard tier (5 slots), Premium tier (20 slots)

How Slots Work#

Each slot is effectively a separate App Service instance:

• Has its own URL: https://<app-name>-<slot-name>.azurewebsites.net
• Has its own deployment configuration
• Can have independent app settings (some settings can be "sticky" — slot-specific)

Common Slot Setup#

Deployment Slot Operations#

Swap — swaps the staging and production slot (zero downtime):

staging → production  (new version goes live)
production → staging  (old version kept for rollback)

Traffic splitting — send a percentage of traffic to a non-production slot:

• Useful for canary deployments (e.g. 5% to new version, 95% to production)
• Gradually increase traffic as confidence in new version grows

Sticky settings — app settings or connection strings marked as slot-specific stay with the slot during a swap, so each slot can have its own database connection or config.

Restoring to a Previous Version Using Slots#

1. Take a backup (or rely on automatic backup)
2. Go to Backups → select a previous backup
3. Choose to restore into a deployment slot (not production)
4. Test the restored version in the slot
5. Swap if satisfied, or discard the slot

Key Exam Takeaways#

• Scale up = change plan tier (bigger VM); Scale out = more instances
• Scale out uses rules similar to VM Scale Sets (CPU, memory, queue metrics)
• Platform backups: automatic, hourly, Azure-managed storage
• Custom backups: your storage account, custom schedule, configurable retention
• Restore to deployment slot (not production) to avoid data loss
• Deployment slots require Standard+ tier
• Swap = instant zero-downtime deployment
• Sticky settings = slot-specific config that doesn't get swapped
• Traffic splitting = canary/gradual roll-out

Quick Revision Cheat Sheet#

Scale up = change tier (bigger VM)
Scale out = add instances (like VMSS)
Rules-based scaling: CPU%, memory, schedule

Platform backup: hourly, auto, managed storage (no access)
Custom backup: your storage + blob container + schedule
Restore: always use deployment slot in production (avoid overwriting live)

Deployment slots: Standard (5 slots), Premium (20 slots)
Swap = zero-downtime deploy
Rollback = swap back
Sticky settings = slot-specific (not swapped)
Traffic splitting = canary deployment

Reference Documentation#

• Scale up an App Service app
• Scale out with autoscale rules
• Back up and restore App Service
• Set up staging environments (deployment slots)
• Traffic routing between deployment slots