Skip to main content
Configuring App Service Azure App Service is a fully managed platform (PaaS) for hosting web apps, API apps, and mobile backends. It supports multiple runtimes — .NET, Node.js, PHP, Java, Python — and containerized applications. App Service removes the need to manage underlying virtual machines so developers can focus on code. Key benefits include enterprise compliance (ISO, SOC, PCI), authentication integration with Microsoft Entra ID and social providers, built-in CI/CD integrations, first-class Visual Studio tooling, and marketplace templates (WordPress, Drupal). You can also run Azure Functions on an existing App Service plan without provisioning additional infrastructure.
A colorful infographic titled "App Service" showing platform icons (.NET, Node.js, PHP, Java, Python, HTML5, Docker) across the top. Below are rounded gradient boxes listing features like single plan, multi-language support, fully managed PaaS, security/compliance, CI/CD integration, marketplace templates, API/mobile features and running Function apps.

​
Create an App Service from the Azure portal

Follow these steps to provision a Web App (App Service) using the Azure portal:
  1. In the Azure portal, search for App Services (or Web App). Click Create -> Web App.
  2. Select an existing resource group or create a new one.
  3. Enter a globally unique app name. This becomes the public hostname in the form yourapp.azurewebsites.net.
  4. Choose a publish option and runtime:
    • Publish: choose Code or Docker container. For static site workflows consider Azure Static Web Apps.
    • Runtime stack: pick from .NET, Node, PHP, Python, Java, etc., or choose a custom container image when publishing a Docker container.
    • OS: Windows or Linux — pick the OS compatible with your runtime/image.
  5. Select or create an App Service plan (this defines compute resources, pricing tier, and scaling behavior).
  6. Configure optional settings: database, deployment (CI/CD), networking, monitoring, tags. When ready, click Review + Create.
A screenshot of the Microsoft Azure portal on the "Create Web App" page, showing form fields for app name, publish type, runtime stack (ASP.NET V4.8), operating system (Windows), region (East US) and pricing plan. Action buttons at the bottom read "Review + create" and "Next: Database".
You do not need to create the App Service plan ahead of time—the portal can provision one for you during web app creation. After deployment completes, the portal provides the app URL which you can open in your browser. The app will run on the compute defined by the App Service plan you selected.
A screenshot of the Microsoft Azure portal showing a deployment overview for "Microsoft.Web-WebApp-Portal..." with a green check and the message "Your deployment is complete." The page shows deployment details, a "Go to resource" button, and cost/security links in the right pane.

​
Scaling and tiers

The App Service plan determines pricing tier (Free, Shared, Basic, Standard, Premium, etc.) and the compute available to all apps within that plan. Two primary scaling operations are available:
  • Scale up (vertical scaling): change the pricing tier or instance size to get more CPU, memory, or features. This often restarts the app and can cause brief downtime.
  • Scale out (horizontal scaling): increase the number of instances running the app to handle additional load without changing instance size.
You can change tiers from the portal, set instance counts for manual scaling, or create autoscale rules.
A screenshot of the Microsoft Azure portal showing the "asp-01 | Scale out (App Service plan)" page. It lists App Service tiers (Dev/Test and Production) with columns for vCPU, memory, remote storage and pricing (cost per hour/month in INR).
Resizing (scaling up) an App Service plan restarts application processes. Expect brief downtime when you change tiers or instance sizes.

​
App Service tier guidance

  • Free / Shared: Useful for development or testing; limited compute and features.
  • Basic: Low-cost production workloads with no autoscale.
  • Standard / Premium: Production workloads with autoscale, staging slots, and advanced features.
  • PremiumV2 / PremiumV3 and Isolated: High-performance workloads and network isolation.

​
Autoscale (rule-based scaling)

App Service supports rule-based autoscaling so your apps can scale out/in based on metrics such as CPU percentage, memory, HTTP queue length, or custom metrics. Typical autoscale configuration steps:
  • In your App Service plan, choose Scale out (App Service plan) -> Autoscale settings.
  • Create or edit an autoscale profile.
  • Add rules that define:
    • Metric (for example, CPU percentage)
    • Condition and threshold (for example, CPU > 70%)
    • Time aggregation and duration (for example, 5 minutes)
    • Action (increase instance count by X)
  • Add complementary scale-in rules (for example, decrease when CPU < 25%).
  • Set minimum and maximum instance counts.
Example autoscale rule (conceptual):
A screenshot of the Microsoft Azure portal open to an Autoscale setting for an App Service plan (asp-01), showing the default scale condition and instance limits. The right pane displays a Scale rule editor for a CPU-percentage-based autoscale rule (threshold, duration, and action fields).
When building autoscale rules, include cool-down periods and sensible min/max instance limits to avoid rapid scale-churn. Account for application warm-up time so new instances are ready before receiving production traffic.

​
Next steps and recommendations

  • Secure the app: configure Microsoft Entra ID, OAuth providers, and custom domains with TLS.
  • Implement CI/CD: connect your repository (GitHub, Azure Repos) and set up deployment pipelines.
  • Use deployment slots: configure staging slots to enable zero-downtime swaps.
  • Monitor and alert: enable Application Insights, logging, and alerts for key metrics.
  • Backups and high availability: configure backups and consider multiple regions for critical apps.
  • Consider Azure Static Web Apps for single-page static frontends and Azure Functions for serverless workloads.
Links and references Use the Web App you created here as a baseline to experiment with CI/CD, scaling rules, authentication, and deployment slots.

Watch Video

Practice Lab