Azure App Service: A Complete Guide to Web App Hosting

App Service is like renting a furnished apartment. No plumbing to fix, no wiring to worry about. You move in and start living, and someone else handles the building.

That is what it does for a web application. Azure runs the servers, the networking, the patching and the scaling, and you deal with your code. It is Microsoft's managed platform for web apps, REST APIs and mobile backends, supporting .NET, Java, Node.js, Python, PHP and Ruby, plus containers when you want them.

Where it sits among the compute options

Virtual machines give you everything and hand you everything. Operating system, runtime, patching, networking, all yours. You bought the house, you fix the roof.

Containers, whether Container Apps or AKS, sit in the middle. You package the application with its dependencies and the platform orchestrates it.

App Service is the managed end. You push code or an image and Azure handles what is underneath.

For most web applications and APIs, App Service is the right first choice. Moving to containers later is a normal progression rather than an admission of error, and starting there because it sounds more serious is how people acquire an orchestration problem they did not need.

Plans, and what you are actually buying

An App Service Plan is the compute your app runs on. The tier decides how much CPU and memory you get and which features unlock.

Prices move, so check the calculator rather than any table in an article. The structural point is that Standard is where production features begin. Deployment slots, autoscale and VNet integration all arrive at that tier, and those three are what separate a hobby deployment from an operable one.

Getting the first one running is the fastest way to make the tier differences concrete. Create a web app on App Service through the portal.

Getting code onto it

GitHub Actions is the usual answer for teams already on GitHub. Azure provides starter workflows, you connect the repository, and pushes to your main branch deploy themselves.

Azure DevOps Pipelines does the same job for organisations standardised on DevOps.

ZIP deploy is the direct route, useful in scripts and simple pipelines:

az webapp deploy --resource-group myRG --name myApp --src-path app.zip --type zip

Containers let App Service pull an image from a registry, which gives you container packaging without container orchestration.

For most teams GitHub Actions is the right starting point. Deploying containerised applications with GitHub Actions covers the pipeline end to end.

Scaling in two directions

Scaling up means a bigger plan, more CPU and memory in one place. It needs a brief restart, so it belongs in a maintenance window.

Scaling out means more instances behind a load balancer. Manual scaling fixes the count, which suits predictable load. Autoscale adjusts it against rules you write, based on CPU, memory, HTTP queue length or a custom metric.

Autoscale rule example
  Metric: CPU percentage
  Condition: average above 70 percent for 5 minutes
  Action: add one instance
  Cooldown: 5 minutes
  Maximum: 10 instances

Deployment slots

Slots are the strongest argument for Standard tier. A slot is a live instance of your app with its own hostname, and the usual arrangement is production plus staging.

Deploy the new version to staging. Test it on the staging URL. Swap, which routes production traffic to what you just tested. If it misbehaves, swap back.

The swap works by exchanging virtual IPs, so there is no downtime and no cold start. Slots also support percentage routing, so you can send a fraction of traffic to a new version and watch the error rate before committing everyone.

The detail that catches people is which settings travel. Connection strings usually should not, because staging should point at a staging database. Mark those as deployment slot settings so they stay put during a swap, or you will swap your staging app onto the production database at the worst possible moment.

Set up a staging environment with deployment slots and perform a swap, because the mechanics are much clearer once you have watched one.

Domains and certificates

Your app arrives on an azurewebsites.net address. For production you map your own domain: add a CNAME or A record pointing at the app, add the domain in the portal, let Azure validate ownership, then bind a certificate.

App Service issues free managed certificates for custom domains from Basic tier upward, and renews them itself. Bring your own certificate or integrate Key Vault when policy requires specific ones.

Turn on HTTPS Only in production. It is one setting and it removes the entire category of accidental plaintext access.

Private networking

Apps are publicly reachable by default, and enterprise workloads usually need that changed. Two features do different halves of the job, and they are constantly confused.

VNet integration is outbound. It lets your app reach into a virtual network to talk to databases, storage and internal services without those services being exposed publicly. Available from Standard upward.

Private endpoints are inbound. They give the app a private address inside your VNet so it is reachable privately rather than over a public URL.

Used together they produce a fully private path in both directions, which is what regulated environments generally require. Start with VNet integration for the outbound half.

Then private network access for the inbound half, including the DNS configuration that makes the private name resolve correctly.

Mistakes that show up repeatedly

Starting on Premium. Standard handles most production workloads. Scale up on evidence, not on assumption.

Deploying straight to production. Slots are included with the plan you are already paying for. Not using them is choosing risk for no saving.

Leaving Always On off. Without it the app unloads after a period of inactivity and the next visitor absorbs a cold start. Enable it for anything in production.

No health check endpoint. Configure one and App Service routes traffic away from unhealthy instances. Without it, a crashing instance keeps receiving requests until someone notices.

Never opening App Service Diagnostics. It analyses performance, availability and configuration and is genuinely good. It is also invisible unless you go looking.

No backups. App content and configuration can be backed up automatically. For anything with real data behind it, configure this before you need it.

What to learn next

Once App Service is comfortable, the natural extensions are observability and traffic management. Application Insights for App Service monitoring is the highest value next step, because until you have request level telemetry you are guessing about performance.

Beyond that, look at Container Apps when you outgrow the single application model, and Front Door when you need global routing or a CDN in front of the app.

App Service is a substantial AZ-104 topic, and scaling, slots and network integration are the parts most likely to appear. They are also the parts that make the difference in real deployments, which is a rare and convenient overlap.