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.

New to cloud? CAMPUX is a free, build-first course. Start here →

The short version: pick Free (F1) to try something throwaway, Basic (B1) for a small always-on app on your own domain, Standard (S1) the moment you want autoscale or a staging slot, and Premium v3 (P1v3) when you need private networking, real headroom, or up to 20 slots. An App Service plan is the compute your apps run on, and its tier sets both the hardware and the feature set. The trap is that people compare tiers on vCPU and RAM alone. The numbers matter, but the reason you upgrade is almost always a feature that does not exist on the tier below — Always On, deployment slots, autoscale, or VNet integration. This note lays out the ladder, then names the exact cliffs that force each step.

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. No custom domain, no Always On, no slots.
• Basic (B1–B3) — the first dedicated tier. Custom domains, free SSL, and Always On arrive here. 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) — bigger, faster instances, VNet integration, 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.

What you cannot do is the whole point. There is no Always On, so the app unloads after about 20 minutes of no traffic and the next visitor eats a cold start. There is no custom domain and no TLS binding, so you are stuck on the azurewebsites.net URL. There are no deployment slots, no autoscale, and no scale-out at all. Treat Free as a sandbox, not a home for anything a real user will see.

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, slots, backups

Standard is the tier most production web apps should start on. It keeps everything Basic has and adds the three 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.
• Scheduled backups — automated app and configuration backups you can restore from.

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+): VNet, performance, reserved savings

Premium v3 is the current performance tier. The instances use faster processors, SSD-backed storage, and memory-optimized options, and P1v3 starts at 2 vCPU and 8 GB of RAM — noticeably more headroom than S1's single vCPU and roughly 1.75 GB. Beyond raw specs, three things pull people up to Premium:

• VNet integration — reach private resources like a database behind a private endpoint or an internal API. This is the single most common reason to jump from Standard to Premium.
• 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, which often makes P1v3 cheaper than S1 for a workload that runs 24/7.

That last point catches people out. On-demand, Premium v3 looks expensive next to Standard. For an app that never turns off, a reservation can flip the math so the faster tier costs less over the year.

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 — none on Free or Shared; both from Basic up. The day you need app.yourcompany.com with 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 — the classic Premium cliff. If your app must reach a private resource, that is your ticket from Standard to Premium v3.

Read the table below with those four cliffs in mind. Every jump you make is usually one of them, not a stopwatch.

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.

Questions people also ask

What is the difference between Basic and Standard App Service plans?

Basic gives you dedicated compute, custom domains, free SSL, and Always On, and it scales out to 3 instances — but it has no deployment slots, no autoscale, and no backups. Standard adds autoscale, up to 5 deployment slots, scheduled backups, and scale-out to 10 instances. If you release with a staging slot or want the platform to add instances under load, you need Standard, not Basic.

Does the Free App Service tier support custom domains?

No. The Free (F1) tier runs on shared compute and only serves your app on the default *.azurewebsites.net hostname. You cannot map your own domain or bind a TLS certificate on Free or on the Shared (D1) tier. Custom domains and free managed SSL begin at the Basic tier, which is the first dedicated-compute tier.

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?

It is worth it when you need any of three things: VNet integration to reach private resources, more headroom (P1v3 starts at 2 vCPU and 8 GB RAM versus S1's 1 vCPU and roughly 1.75 GB), or up to 20 deployment slots and scale-out to 30 instances. P1v3 also supports reserved-instance and savings-plan pricing, which cuts the sticker cost for steady workloads. For a small always-on app with no private networking, S1 is fine.