Cram sheet — Create and configure Azure App Service
AZ-104 › Unit 3 › Create and configure Azure App Service
Cram sheet — Create and configure Azure App Service
Create and configure Azure App Service
- AZ104-U3.T4
- 8
- 28
- 7
Eight objectives, and almost every trap lives in one place: the plan and the app are separate objects, and the plan owns the capacity. Read every stem for which of the two it is really about.
Scale up and scale out are different controls
- Scale up changes the pricing tier — more CPU, memory, disk, or features such as custom domains, certificates, staging slots and autoscaling.
- Scale out changes the number of VM instances. Basic, Standard and Premium plans scale out to as many as 3, 10 and 30 instances respectively.
- ⚠ In the Free and Shared tiers an app gets CPU minutes on a shared VM and cannot scale out at all. If a stem requires more instances, those two tiers are eliminated before you read further.
The plan owns the capacity
- All apps in an App Service plan scale together, because they share the same VM instances. Scaling the plan — manually or by autoscale rule — affects every app in it.
- Only apps in the same plan share VM instances. Isolating one noisy app means moving it to its own plan, not tuning it in place.
- Free and Shared run apps on the same VM as other customers' apps. IsolatedV2 runs on dedicated VMs in dedicated virtual networks.
Deployment slots
- Slots require Standard, Premium or Isolated. That is the tier gate, and it is asked directly.
- All instances of the source slot are warmed up before the swap, so there is no downtime and no dropped requests. A swap is a switch of routing rules, not a copy.
- ⚠ After a swap, the staging slot holds the previous production app. So the rollback for a bad release is to swap again immediately — that is the documented way back to the last known good site, and it is a favourite question.
- Auto swap exists for when pre-swap validation is not needed.
Certificates, domains, backup, networking
- The free App Service managed certificate is fully managed and automatically renewed, with its bindings updated for you. A private certificate you upload must be a password-protected PFX.
- DNS mapping: a root domain needs an A record — the documentation says explicitly not to use CNAME for the root. A subdomain uses CNAME, which is less susceptible to the app's IP changing.
- Backup is supported in Basic, Standard, Premium and Isolated. ⚠ In Basic you can back up and restore the production slot only. Automatic backups are capped at 30 GB; custom backups at 10 GB, of which 4 GB may be a linked database.
- ⚠ Virtual network integration is outbound only. It gives your app access to resources in the network; it does not grant inbound private access to your app. Inbound private access is a private endpoint, which is a different feature.
Traps
Check yourself
Where these figures come from
Every figure above was read from the raw documentation below on the day this sheet was written. The sha1 is git hash-object over the bytes as fetched, so a doc that changes underneath this sheet can be detected rather than assumed.
| Document | sha1 |
|---|---|
| Scale up an app in Azure App Service | cd41383af9d9 |
| Azure App Service plan overview | 031c5af27b95 |
| Set up staging environments in Azure App Service | 2d0b4578ba9a |
| Add and manage TLS/SSL certificates in Azure App Service | 4c2b49f93cc7 |
| Map an existing custom DNS name to Azure App Service | 6da140febfe3 |
| Back up and restore your app in Azure App Service | 87d4207ec7f2 |
| Integrate your app with an Azure virtual network | f9288fe93879 |