App Service Plan
An App Service Plan defines the compute resources — VM size, region, and pricing tier — that power one or more Azure App Service web apps, function apps, or API apps. Multiple apps can share a single plan and its underlying instances, and scaling (manual or automatic) is configured at the plan level, meaning every app on that plan scales together.
App Service Plan
An App Service Plan defines the compute tier and instance count backing your web apps — multiple apps can share the same plan to save cost.
Why It Matters in Production
Zerodha runs its internal admin dashboards on a shared Standard-tier App Service Plan, while the customer-facing trading API sits on a dedicated Premium plan for guaranteed capacity.
az appservice plan create --name zerodha-internal-plan
--resource-group zerodha-prod-rg --sku S1 --number-of-workers 2
RememberScaling an App Service Plan scales every app hosted on it — isolate performance-critical apps onto their own plan.
Frequently Asked Questions
Why does it matter that multiple apps can share one App Service Plan?
Sharing a plan means multiple low-traffic apps can run on the same underlying VM instances, avoiding the cost of provisioning separate compute for each one — useful for hosting several small internal tools cheaply. The tradeoff is resource contention: apps on a shared plan compete for the same CPU and memory, so one app spiking under load can degrade performance for every other app on that plan.
What's a common mistake when sizing an App Service Plan?
Putting a production app on the same plan as a low-priority dev or staging app to save cost, then having a load test or traffic spike on the production app starve the dev app of resources — or worse, vice versa. Production workloads should generally get their own dedicated plan so scaling decisions and resource limits are isolated to that app alone, not shared with unrelated workloads.