Azure App Service Plans Explained: Free, Basic, Standard, Premium
The tier you pick decides what your app can do — not just how fast it runs. Most confusion around App Service pricing comes from treating the ladder as a speed dial when it is really a feature ladder, where whole capabilities switch on at each rung.
Use Free (F1) for a sandbox, Basic for dedicated Always On hosting, and Standard when you need autoscale or staging slots. Premium v3 adds capacity and higher limits; private outbound networking is already supported on Basic and Standard. This comparison covers selected F1, B1, S1 and P1v3 sizes, rather than every current SKU. Premium v4 also exists; check regional availability and current prices before choosing.
Quick map: what each tier is for
Here is the whole ladder in one breath, so you can stop reading if you already know which rung you need:
- Free (F1) and Shared (D1) — shared compute for demos, learning, and throwaway apps. F1 has no custom domain; Shared D1 supports custom hostnames. Neither has Always On or slots.
- Basic (B1–B3) — the first dedicated tier. Custom-domain TLS certificates and Always On are available here, along with VNet integration and app backups. Still no autoscale and no slots.
- Standard (S1–S3) — the production default. Autoscale, up to 5 deployment slots, and scheduled backups.
- Premium v3 (P1v3 and up) — larger selected instances, up to 20 slots, scale-out to 30, and reserved-instance pricing for steady workloads.
Everything below is the detail behind that list — what you actually get and give up at each rung, and the four features that draw a hard line through the ladder.
Free and Shared (F1 / D1): what you can and can't do
The Free (F1) and Shared (D1) tiers run your app on a VM shared with other customers' apps, with a CPU quota measured in minutes per day. That is fine for what they are meant for: trying a framework, hosting a demo, or checking that a deploy pipeline works end to end. You get roughly 1 GB of storage and 60 minutes of CPU per day on F1, and Azure serves your app on the default *.azurewebsites.net hostname.
Neither Free nor Shared supports Always On or deployment slots. Free cannot map a custom domain. Shared can map a custom hostname, but custom-domain certificate bindings require Basic or higher. The default azurewebsites.net endpoint has HTTPS; that is different from securing your own hostname.
Basic (B1–B3): the first "real" tier
Basic is where App Service starts behaving like production hosting. Your app moves onto dedicated VM instances that only your plan uses, so a noisy neighbor stops being your problem. Three things switch on that Free does not have, and they are the reasons most people leave Free:
- Custom domains and free managed SSL — map your own domain and get an auto-renewing certificate.
- Always On — keep the app warm so there is no cold start and background jobs keep running.
- Manual scale-out to 3 instances — you can run more than one copy for availability, though you set the count yourself.
Storage jumps to about 10 GB, and the instances (B1 through B3) get progressively more vCPU and RAM. What Basic still lacks is the two features that define Standard: autoscale and deployment slots. You can add instances, but only by hand, and you have no staging slot to swap into production. For a small internal tool or a low-traffic site on its own domain, Basic is genuinely enough. For anything you release often, it is one rung short.
You do not upgrade App Service tiers for speed. You upgrade them for a feature the rung below simply does not have.
Standard (S1–S3): autoscale and slots
Standard is the tier most production web apps should start on. It keeps everything Basic has and adds the operational capabilities that make releases and traffic spikes manageable:
- Autoscale — the platform adds and removes instances on rules or a schedule, up to 10 instances, instead of you watching a graph. See how autoscaling in Azure works for the rule model.
- Deployment slots (up to 5) — deploy to a staging slot, warm it, verify it on a real URL, then swap it into production near-instantly and swap back if it misbehaves. This is the feature that makes releases boring in the good way; it has its own field note on deployment slots.
- Backups — supported on Basic as well as Standard and higher. Basic can back up and restore the production slot; Standard also offers deployment slots for a staged restore. Automatic and custom backups have different limits.
Storage rises to about 50 GB. If you had to name a single default tier for a team shipping a web app on Azure, S1 is the honest answer — it is the first rung where the platform does the operational work you would otherwise do by hand.
Premium v3 (P1v3+): capacity and higher limits
P1v3 provides 2 vCPU and 8 GB RAM, compared with the selected S1 size’s 1 vCPU and approximately 1.75 GB. Premium v3 is one performance option; Premium v4 is also available. Choose from measured workload needs, limits and regional availability rather than assuming the newest or highest tier is required.
- Outbound VNet integration — supported on Basic, Standard and Premium dedicated tiers. It lets the app reach resources through a VNet; it does not itself make the app privately accessible to inbound clients.
- More slots and more scale-out — up to 20 deployment slots and scale-out to 30 instances, with storage around 250 GB.
- Reserved-instance and savings-plan pricing — commit to a one- or three-year term and the effective hourly cost drops well below pay-as-you-go, whose actual cost must be compared with eligible usage, term and region.
Compare actual prices and commitment utilization. A discounted Premium plan is not automatically cheaper than Standard; an unused commitment still costs money. Match the plan’s capacity and release requirements before committing.
The gap: the feature cliffs that force an upgrade
Forget the vCPU numbers for a second. In practice, four features draw hard lines through the ladder, and hitting any one of them is what actually forces you up a tier:
- Always On — off on Free and Shared, on from Basic up. If you have background jobs or cannot tolerate cold starts, you are on Basic or higher, full stop.
- Custom domain and SSL — Free has no custom hostname; Shared supports one, while custom-domain TLS requires Basic or higher. The day you need
app.yourcompany.comwith a certificate, you leave Free. There is a field note on custom domains and free SSL that walks the binding. - Deployment slots — none on Free or Basic, up to 5 on Standard, up to 20 on Premium. If your release process depends on a staging swap, Basic will not do it; you need Standard.
- VNet integration — available on Basic and higher dedicated tiers. Check subnet and routing requirements; distinguish outbound integration from an inbound private endpoint.
Read the table below with those four cliffs in mind. Every jump you make is usually one of them, not a stopwatch.
| Feature | F1 (Free) | B1 (Basic) | S1 (Standard) | P1v3 (Premium v3) |
|---|---|---|---|---|
| Compute type | Shared | Dedicated | Dedicated | Dedicated |
| vCPU / RAM | Shared / ~1 GB | 1 / ~1.75 GB | 1 / ~1.75 GB | 2 / 8 GB |
| Storage | ~1 GB | ~10 GB | ~50 GB | ~250 GB |
| Max instances | 1 (no scale-out) | 3 (manual) | 10 (autoscale) | 30 (autoscale) |
| Autoscale | No | No | Yes | Yes |
| Deployment slots | None | None | Up to 5 | Up to 20 |
| Always On | No | Yes | Yes | Yes |
| Custom domain + SSL | No | Yes | Yes | Yes |
| Outbound VNet integration | No | Yes | Yes | Yes |
| Price framing | Free | Low, flat | Mid, per instance | Higher; reservations cut it |
Numbers like storage and instance ceilings move over time and vary by region and OS, so treat them as the current shape of the ladder rather than a contract. Check the pricing page for the exact figure in your region before you commit a budget. The order of the ladder and the feature cliffs are the stable part, and those are what you reason with.
Every app on a plan shares that plan's instances and cost. Stacking several small apps on one S1 plan is cheap and sensible. But if one of those apps gets busy and you scale the plan out, you pay for the bigger footprint across all the apps sharing it — even the idle ones. When one app has spiky, independent load, give it its own plan instead of scaling a shared one.
Questions people also ask
What is the difference between Basic and Standard App Service plans?
Basic provides dedicated compute, Always On, custom-domain TLS, outbound VNet integration and app backup/restore. Standard adds deployment slots and autoscale with higher instance limits. Basic backup/restore applies to the production slot; a staging slot for testing a restore requires Standard or higher.
Does the Free App Service tier support custom domains?
Free F1 cannot map your own domain. Shared D1 can map a custom hostname, but custom-domain TLS certificate bindings require Basic or higher. HTTPS on the default azurewebsites.net hostname is a separate feature.
What is Always On in Azure App Service?
Always On keeps your app loaded in memory instead of letting it unload after about 20 minutes of no traffic. Without it, the first request after idle waits for a cold start, and background jobs stop when the app unloads. Always On is available on Basic and higher — it is not available on the Free or Shared tiers, which is one of the main reasons production apps leave Free.
How many apps can share one App Service plan?
You can put many apps on a single plan — there is no fixed per-plan app cap you hit in normal use — but they all share the same instances, CPU, and memory. Density is limited by resources, not a hard count: a P1v3 plan can host several small apps comfortably, while one busy app may want the plan to itself. Every app on the plan scales together when you scale the plan.
Is P1v3 worth it over S1?
Compare P1v3 when you need more CPU/RAM, deployment slots or instance capacity than S1 provides. VNet integration alone does not require Premium: Basic and Standard support it too. Compare current regional prices and commitment utilization rather than assuming Premium is always cheaper for steady workloads.
Every class is open to read. A free account saves your progress. Azure resources used for labs may incur charges.
It worked for them.
Sources and review
Reviewed 1 October 2026. Corrected the Basic/Standard VNet, Shared-domain and Basic-backup comparisons. This is a comparison of selected sizes; check current SKU, OS and region-specific limits before purchasing.