Azure App Service - Simply Explained

0:00 The tier you pick on Azure App Service decides what your app is even allowed to do. It's Microsoft's managed home for web apps and APIs, so you bring the code and Microsoft runs the machines underneath. You think you're choosing hosting, but you're actually choosing a feature set because the plan carries the domain name, the staging slot, and the ability to scale. That single decision is where most beginner projects either sail or stall. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. By the end, you'll know what app service is, which tier a beginner project actually needs, and the mistakes that cost people time and money. What it actually is as your app service is Microsoft's managed place to run web apps, APIs, and the back ends that mobile apps talk to.

0:43 The official wording is that you run your app without worrying about the infrastructure underneath it. That phrase sounds like marketing, and it's doing real work here because it describes exactly what you stop doing. You stop patching an operating system, you stop sizing a machine, and you stop keeping a spare machine alive in case the first one falls over. What you keep doing is what matters most. You write the code, you choose the settings, and you own the data your app touches. Microsoft owns the metal and the maintenance. That split is the whole idea behind platform as a service, which people shorten to parse, and it's why a beginner can put a working app on the internet in an afternoon without learning how a server boots the stacks. You can use R wide dot net, Java, Node.js, Python, and PHP all run here on windows or on Linux. And if your app is already packaged as a container, you can deploy that instead.

1:25 You choose the stack when you create the app, and you can change your mind later by deploying something else. The word manage deserves one more sentence because it's carrying a lot of weight. When you deploy here, you don't get a machine with your name on it. You get a service that already knows how to keep your app online, patch itself, and hand traffic to more than one copy when you ask it to. That's why the first deployment can feel anticlimactic because you push your code, you wait a minute and your app is simply there. The difference from a virtual machine is easy to state. A virtual machine is a computer you rent, and everything on it is your problem. From the operating system. Upward app service is a service you rent, and the operating system is never your problem. Microsoft also keeps narrower options around like managed instance for old windows apps that need deep access to the system and app service environment for teams that need their own private network.

2:11 A beginner needs neither one. Everything so far is the easy part. The decision that shapes your bill and the features you're allowed to switch on sits in a different box entirely, and that's where we're headed next. The plan is the product now for the part that catches almost everyone. Before you build anything in app service, you create an app service plan and the plan is what you're really buying. A plan is a bundle of computing resources, and it locks in five decisions at once. The operating system, the region your app lives in, the size of the machines, how many machines there are, and the pricing tier your app runs inside that bundle. Microsoft puts it plainly, and app service always runs in an app service plan. So the thing you're buying isn't hosting for one app. It's a shared pool of machines, and everything you drop into that pool draws from the same supply.

2:53 Two web apps in one plan run on the same machines. So do the deployment slots for those apps and so do backups, diagnostic logs, and any background jobs you add. None of that gets built separately because it's all just your plan doing its work. That sharing has a consequence which trips people up and Microsoft states it directly. All apps in a plan scale together because they share the same underlying machines. When you scale the plan by hand or by a rule, every app in it moves at once. One app having a busy afternoon can slow down its neighbours in the same plan. Compute is dedicated at the plan level, not the app level, and that sentence deserves a second reading. If you want one app to have its own resources, the answer is a second plan rather than a setting. The classic version of this story goes like this. Someone builds a demo.

3:33 It works. So they add a second app and then a third. A few months later, a support ticket arrives because the first app has started timing out. Nothing broke. They just filled the plan up. A plan has a fixed amount of CPU and memory, and every app inside it is competing for the same slice. Billing follows the same shape. The free tier costs nothing on the shared tier. Each app is charged for the amount of CPU it's allowed to use on the dedicated tiers. You're charged for the machines in the plan, rather than the number of apps sitting on them. Custom domains, certificates, deployment slots, and backups are features rather than line items, so they don't turn into extra charges later. There's a rough limit on how many apps fit in one plan, and Microsoft's guidance is about eight on a small B1 or S1 plan, sixteen on a medium one and thirty two on a large one.

4:15 Pass that you split. Hold on to one idea from this section, because the tier you pick does more than set the size, and that comes back in a moment. Web apps and APIs before the money talk. It helps to know what you can put in their app service hosts web apps, Rest APIs, and mobile back ends, and Microsoft describes all three as one service. The portal gives you different templates for them, but the engine underneath is the same. A web app serves pages to a browser. An API serves data to something else, which in your world could be a mobile app, a power automate flow, or a power BI report pulling fresh numbers. That's the whole difference. And it's smaller than the separate labels. Make it sound. A rest API is just one that follows the usual web conventions for asking for data and getting it back.

4:56 What people build here is grounded in ordinary work internal apps for a team, an API behind a mobile app, a webhook receiver that listens for events from another system, a marketing site, or a ready made template from the Azure marketplace like WordPress, Django or a node chaser starter. You also get a few things built in that beginners rarely expect. Sign in with Google, Facebook, or a Microsoft account works without you building an authentication system. Deployment can be wired straight to GitHub or Azure pipelines, so a push to a branch can become a live app. If your world is power platform, think of the API as the piece your flows and reports call when they need data from something you built yourself. That last idea is the one to sit with, because a single app can serve all of them at once.

5:37 Plenty of teams build one API and then point a power BI report, a power automate flow, and a small internal web page added. That's one deployment, three consumers and no extra hosting to pay for pricing. Tiers decoded. Here's the ladder running from free and shared at the bottom through basic, standard and premium up to isolated at the top. The first two run your app on machines shared with other customers and hand you a CPU quota. Basic and above run on machines dedicated to your plan. Isolated goes a step further and puts those machines on their own private network. The free tier is a test drive, and the numbers make that clear. You get one app per plan, one gigabyte of storage, one gigabyte of memory, sixty CPU minutes a day, and about one hundred and sixty five megabytes of bandwidth a day. Custom domains aren't available at all, so your app lives at a Microsoft address.

6:21 Sixty minutes of CPU. Sounds generous until you learn it's a daily budget and a busy page can eat through it. The shared tier is barely more generous. You get two hundred and forty CPU minutes a day, but you're still on shared machines, still without a custom domain and still unable to run more than a single instance of your app. Basic is the first tier where a real project starts to feel safe. You get dedicated machines, custom domains https a setting called Always On that keeps your app from going to sleep and up to three instances if you're building something for a client or a portfolio. This is the floor standard is where the two features people end up wanting appear, which are auto scale and deployment slots. And you also get ten instances and fifty gigabytes of storage premium pushes that to twenty slots, thirty instances, and two hundred and fifty gigabytes.

7:02 Isolated goes to one hundred instances and a terabyte. Now here's where it gets interesting. Scaling up doesn't just buy you a bigger machine. It switches features on. Microsoft says you can start testing on the free tier and scale up the moment you add your own domain name, and that sentence tells you the tier is a gate rather than a size. Custom domains per app go from zero on three to five hundred on everything else. Deployment slots go from none to five on standard, then twenty on premium and isolated auto scale and always on arrive at different rungs of the ladder. There's a pattern hiding in that list, and it explains why beginners end up disappointed. The features that make an app feel professional, meaning a real domain, a padlock, a version you can roll back, and a way to survive a busy day are spread across three separate tiers.

7:44 You rarely move up one rung. Most people move up two. There's a billing detail that shapes how you plan. You're paying for the plans machines rather than for each app, and that bill runs whether or not anyone visits. Deployment slots. Deployment slots keep coming up as the line between tiers. So here's what one is. A slot is a second live copy of your app with its own web address. You deploy your new version there, test it, and then swap it into production. The swap is the clever part. Before any traffic moves, app service starts up the instances in the slot and warms them up so nobody gets a cold start and no requests get dropped in the middle. If the new version turns out to be a problem. You swap the same two slots back and your last good version is live again. But here's the twist. And it's the one that catches people out. A swap moves more than your code, app settings and connection strings travel with the swap unless you mark them as slot settings, which is how a team ends up with a production app talking to a test database.

8:32 You can mark any setting to stay put, and the ones that always stay put include custom domain names, scale settings, IP restrictions always on, and network integration. Two rules decide whether you get to use slots at all. They need standard or higher and standard caps you at five. If an app already uses more than five slots, you can't scale it down to standard later. There's a gentler version of the swap as well. A swap with preview runs the first half of the swap and then stops, so you can look at the new version running with production settings before you commit to it. And when a release makes you nervous, you can send a slice of your traffic to the slot and watch how real users react before everyone gets the new version. The cost side is friendlier than people expect. Microsoft states there's no extra charge for using deployment slots, so the only price you pay is the higher tier.

9:14 Microsoft's own deployment guidance adds one habit worth copying. Never turn on continuous deployment for your production slot. Send your main branch to a slot and swap it in when you're ready. Scaling up versus out scaling an app service comes in two flavors, and mixing them up is where a lot of confusion starts. Scaling up means moving to a bigger machine or a higher tier. Scaling out means running more copies of your app behind the same address, so each one handles a share of the traffic. The first buys capacity and features, and the second buys room for more people at once. The ceilings are concrete, basic scales out to three instances, standard to ten, premium to thirty and isolated to one hundred. The free and shared tiers can't scale out at all, which is the honest reason they're test tiers rather than starter tiers. Auto scaling, which adds and removes instances based on rules or a schedule, starts at standard.

9:58 Below that, you can still change the instance count by hand, but nothing happens on its own. The part that shocks people who came from running their own servers is how fast this moves. Scale settings take seconds to apply. They affect every app in the plan and they need no code change and no redeployment. Your app never notices, it just finds more copies of itself. There's a practical detail to keep in your back pocket, too. If a plan is sitting above ninety percent of its CPU or memory. Even a deployment can struggle to finish. The documented workaround is to add instances for the deployment, then scale back down afterwards. Microsoft also ships a newer option called Automatic Scaling, which watches the requests coming in and adjusts the number of instances for you without you writing a single rule. If rules and schedules sound like homework, that's the setting to look for.

10:41 One honest warning about scaling out every instance you add is another instance you're paying for. So a rule that adds five instances at lunchtime shows up on the bill at the end of the month. Scaling is a dial with a price attached, not a free switch. Domains and certificates. The first thing you'll want to fix is the address. Every app starts live at something like your app name azurewebsites dot net, which works perfectly and looks exactly like a test. Putting your own name on it needs a paid tier because free and shared don't allow custom domains at all. Once you're on basic or higher, you get five hundred domain slots per app, which is more than anyone needs, and the HTTPs part is easier than you'd expect. You've got two paths here. You can buy a domain through Azure, which keeps the billing and the DNS records in one place.

11:21 Or you can bring a domain you already own and point its records at your app. Both end up in exactly the same place, so pick whichever is less annoying for you. The Free App Service Managed certificate does what it says, Microsoft issues it for your domain, binds it, and renews it automatically so you never buy or install anything. Digicert is the issuer behind these free certificates. Its limits are worth knowing up front. There are no wildcard certificates. You get one certificate per custom domain and you can't export it. That last one matters if you ever want to take the certificate somewhere else. One piece of jargon deserves a quick translation. TLS is the modern name for what everyone still calls SSL, and it's the thing that puts the padlock in the browser. The free certificate covers the common case. IP based connections are billed hourly instead, though standard and above include one at no extra cost.

12:04 There's a detail that trips up root domains, the kind without a w w in front. The DNS record has to point at your IP address, and the app can't have IP restrictions switched on because the certificate has to reach your app to renew itself. Mistakes beginners make. Now for the list. I'd hand anyone before their first deployment because every item here is a decision you're about to make. Building on the free tier and only discovering the walls later is the most common one. Custom domains. HTTPs deployment slots and scale out simply aren't on the menu there and waiting doesn't change that. Use it to learn, then move up when a real person needs to visit. Putting development and production in the same plan creates the same problem from a different direction. They share the same machines, they scale together, and a busy test environment can drag down the thing your customers are using.

12:46 Microsoft's answer is straightforward give it its own plan. Assuming each app gets its own slice of the machine is another one to unlearn. Compute belongs to the plan rather than to the app. So a plan works like a shared house and not a row of separate houses. Forgetting always on costs you real seconds. Without it, an idle app has to wake up when someone arrives, and the first visitor of the day pays for that. In waiting time, Always on starts at basic, which means a free tier app will always feel slow to wake. Swapping slots without pinning your connection strings and app settings is the one that bites hardest. That's the move that sends your production app looking at a test database and one checkbox per setting prevents it. Turning on continuous deployment for the production slot is another. Microsoft's deployment guidance is blunt about it. Your production branch belongs on a slot and you move it across when you're ready.

13:28 Mixing up, scaling up and scaling out leaves people staring at a greyed out autoscale button. Autoscale needs standard, and no amount of patience on a lower tier will switch it on. Treating the plan as permanent is the last one, and it's really a mindset rather than a mistake. Tier changes take seconds. You can move up or down and your app doesn't need to be redeployed. Starting small is the correct move, not a risk. And one more that's less dramatic but costs real money, which is leaving a paid plan. Running for a project nobody visits anymore. Since the bill follows the machines rather than the traffic. A forgotten plan keeps charging whether the app is busy, idle or completely unused. The short version. So that's the shape of it. Azure App Service is a managed home for your web apps and APIs. You buy a plan rather than a server, and the tier you choose decides what you're allowed to switch on as much as how much horsepower you get.

14:15 Slots and certificates take most of the fear out of shipping. If you want more plain English breakdowns like this one, subscribe to M365 FM. And here's my question for you. Now that it's all in plain language, what would you actually put in app service first and which tier would you honestly start on?