6.6 App Service Backups, Deployment Slots, and Scaling
Key Takeaways
- App Service backups protect app content and supported configuration to a storage account on a schedule or on demand.
- Deployment slots allow staged deployment, validation, warm-up, and swap with reduced downtime.
- Slot settings stay with a slot during swap and should be used for environment-specific values.
- App Service scaling includes vertical scale up and horizontal scale out, with autoscale available in supported tiers.
- Exam traps include swapping production secrets into staging, expecting backups on unsupported tiers, and confusing scale up with scale out.
Backups
App Service backup creates restorable copies of app content and supported configuration, stored in an Azure Storage account. Backups can be scheduled or created on demand. They are useful before risky deployments, configuration changes, or application migrations. They are not a substitute for database-native backup strategy unless the database is included and supported by the backup configuration.
Portal path: App Service > Backups. You configure a storage account and container, schedule, retention, and optional database inclusion if applicable. Plan tier matters. If a question uses a very low App Service tier and asks why backup is unavailable, the answer is likely tier support, not a missing DNS record.
Operational backup checklist:
- Confirm the App Service plan tier supports backups.
- Create or select a storage account and container for backup files.
- Configure schedule and retention.
- Decide whether databases are included or handled separately.
- Run an on-demand backup before major changes.
- Test restore expectations in a non-production app when possible.
A restore can target the same app or another app depending on the operation and scenario. Be careful with production restores. Restoring over an active app can overwrite current content and configuration. In exam cases, if the requirement is to validate a backup before affecting production, restore to a separate app or slot where supported rather than replacing production immediately.
Deployment slots
Deployment slots are live apps with their own hostnames under the same App Service app. A common setup is production plus staging. You deploy the new version to staging, validate it, warm it up, then swap staging into production. The swap exchanges content and many configuration values, while settings marked as slot settings remain with their slot.
Deployment slot workflow:
| Step | Action | Why it matters |
|---|---|---|
| 1 | Create a staging slot | Provides a non-production endpoint with production-like hosting. |
| 2 | Mark environment-specific settings as slot settings | Keeps production database strings and secrets with production. |
| 3 | Deploy new code or container image to staging | Avoids direct overwrite of production. |
| 4 | Validate staging hostname, logs, health, and dependencies | Catches runtime and configuration problems before swap. |
| 5 | Warm up staging | Reduces cold start or first-request issues. |
| 6 | Swap staging with production | Moves validated release into production with reduced downtime. |
| 7 | Monitor production and keep previous version in old slot | Enables fast rollback by swapping back. |
Portal path: App Service > Deployment slots. Configuration path: App Service > Configuration, then mark app settings or connection strings as deployment slot settings where appropriate.
CLI example:
az webapp deployment slot create \
--resource-group rg-web \
--name exam-web-prod \
--slot staging
az webapp config appsettings set \
--resource-group rg-web \
--name exam-web-prod \
--slot staging \
--settings ENVIRONMENT=staging
az webapp deployment slot swap \
--resource-group rg-web \
--name exam-web-prod \
--slot staging \
--target-slot production
The biggest slot trap is configuration movement. A setting that is not marked as a slot setting may swap. If staging uses a staging database and production uses a production database, mark the connection string as a slot setting. Otherwise, a swap can connect production traffic to a staging dependency or leave the staging slot pointing to production resources after rollback.
Scaling App Service
App Service supports scale up and scale out. Scale up changes the pricing tier or worker size of the App Service plan. It adds more CPU, memory, and feature capability per worker. Scale out changes the number of worker instances. Autoscale can increase or decrease instance count based on metrics or schedules in supported tiers.
| Scaling need | Action | Example clue |
|---|---|---|
| Need deployment slots or a feature unavailable in current tier | Scale up | Current tier lacks the required feature. |
| Each worker is too small for memory-heavy app | Scale up | Memory pressure on every instance. |
| Traffic exceeds single worker capacity | Scale out | High request volume and CPU across workers. |
| Predictable weekday peak | Autoscale schedule | Business hours traffic pattern. |
| Sudden CPU spikes | Metric-based autoscale | CPU exceeds threshold for a period. |
Portal path: App Service plan > Scale up (App Service plan) and App Service plan > Scale out (App Service plan). Remember that scaling the plan affects apps in that plan. If only one app should receive more capacity or isolation, moving it to a separate plan may be cleaner than scaling every app together.
Autoscale rules need thresholds, duration, cooldown, and instance limits. A bad rule can flap, scale too slowly, or exceed budget. In scenario questions, choose autoscale when the requirement is dynamic capacity based on metrics or schedule. Choose manual scale out when the requirement is a fixed number of instances.
Troubleshooting deployments and capacity
When a slot swap fails or the new version fails after swap, inspect staging logs, startup behavior, health checks, app settings, connection strings, and external dependencies. For custom containers, check image pull, exposed port, and startup timeout. For code apps, check runtime stack, package deployment, and application logs.
When an app is slow, check whether the plan is saturated. If multiple apps share a plan, the noisy neighbor might be another app. Metrics at both app and plan levels matter. Scaling the app settings does not add CPU. Changing a custom domain does not add workers. Increasing ACR tier does not add App Service instances.
Exam traps
Do not assume deployment slots are available in every tier. Do not forget slot settings. Do not treat backups as automatic unless configured. Do not rely on App Service backup as the only protection for a production database when the database has its own backup and restore features.
Do not confuse scale up with scale out. Scale up changes tier or size. Scale out changes instance count. Do not forget that the App Service plan is the scale boundary; apps in the same plan are affected by plan-level scale changes. Do not swap untested code directly into production if the question offers a staged workflow with validation and rollback.
A production and staging slot use different database connection strings. What should the administrator configure before swapping?
An App Service app needs more instances during high CPU periods and fewer instances overnight. Which capability best fits?
Which statement about App Service backup is correct?