App Service Plans & Scaling
Azure App Service lets you host web apps without managing servers. Learn how App Service plans work, how to create web apps, and how scaling works — from manual to auto-scale.
What is Azure App Service?
App Service is like a managed web server — you bring the code, Azure handles everything else.
Instead of creating a VM, installing IIS or Nginx, configuring SSL, and setting up monitoring, you just deploy your web app or API to App Service. Azure handles the OS patches, load balancing, scaling, and certificates. You focus on your application code.
The App Service plan is the VM underneath. It defines the region, size, and pricing tier. Multiple apps can share one plan (like multiple websites on one server).
App Service plan tiers
| Tier | Dedicated Compute? | Custom Domains? | SSL? | Auto-Scale? | Staging Slots? | Use Case |
|---|---|---|---|---|---|---|
| Free (F1) | Shared | No | No | No | No | Learning, testing |
| Basic (B1-B3) | Yes | Yes | Yes | No | No | Dev/test, low traffic |
| Standard (S1-S3) | Yes | Yes | Yes | Yes | Yes (5 slots) | Production web apps |
| Premium (P1v3-P3v3) | Yes | Yes | Yes | Yes | Yes (20 slots) | High-traffic, performance |
| Isolated (I1v2-I3v2) | Yes (dedicated) | Yes | Yes | Yes | Yes (20 slots) | Compliance, network isolation |
Exam tip: Know which tier for which feature
The exam loves tier-based questions:
- Custom domains and SSL require Basic or above
- Auto-scale requires Standard or above
- Deployment slots require Standard or above (5 slots on Standard, 20 on Premium/Isolated)
- VNet integration requires Standard or above; full network isolation requires Isolated
- Always On (keeps app loaded) requires Basic or above
Scaling
Two types of scaling:
| Feature | Scale Up (Vertical) | Scale Out (Horizontal) |
|---|---|---|
| What changes | VM size (CPU, RAM) | Number of VM instances |
| Example | S1 to S3 (more powerful) | 1 instance to 5 instances |
| Auto-scale? | No — manual tier change | Yes — metric or schedule based |
| Downtime? | Brief (plan moves to new hardware) | None (instances added behind load balancer) |
| Limit | Largest tier in the plan family | 10 instances (Standard), 30 (Premium v3), 100 (Isolated) |
Auto-scale rules (Standard tier and above):
- Scale based on metrics: CPU %, memory %, HTTP queue length, custom metrics
- Scale based on schedule: more instances during business hours, fewer at night
- Set minimum, maximum, and default instance counts
- Cool-down period: minutes to wait after a scale action before evaluating again
Real-world: TechCorp's App Service strategy
TechCorp Solutions runs three web apps:
- Public website — low traffic, mostly static → Free tier during development, Basic for production
- Customer portal — moderate traffic, needs SSL and custom domain → Standard S1 with auto-scale (2-5 instances)
- Internal API — high traffic, needs staging slots for safe deployments → Standard S2
Alex keeps the website and API on separate plans because the API’s traffic spikes shouldn’t affect the customer portal’s performance. The golden rule: apps that share a plan share its resources.
Knowledge check
CloudFirst Labs needs their web app to automatically handle traffic spikes by adding instances, and they want deployment slots for testing. Which is the minimum App Service plan tier?
Alex has an App Service plan running 2 instances at Standard S2 tier. Traffic doubles during a holiday sale. What type of scaling should he configure?
🎬 Video coming soon