Edit

Share via

Basic web application

Azure App Service
Azure Key Vault
Azure Monitor
Azure SQL Database

This architecture shows the fundamental components of a basic web application. You can use the architecture to build a web application and then customize the application to your needs.

Architecture

Diagram showing the reference architecture for a basic web application in Azure.

Download a Visio file of this architecture.

Components

  • Azure App Service is a fully managed platform for creating and deploying cloud applications. It lets you define a set of compute resources for a web app to run, deploy web apps, and configure deployment slots.
  • Deployment slots lets you stage a deployment and then swap it with the production deployment. That way, you avoid deploying directly into production. See the release engineering and deployment section below for specific recommendations.
  • IP address: The App Service app has a public IP address and a domain name. The domain name is a subdomain of azurewebsites.net, such as contoso.azurewebsites.net.
  • Azure DNS is a hosting service for DNS domains, providing name resolution using Microsoft Azure infrastructure. By hosting your domains in Azure, you can manage your DNS records using the same credentials, APIs, tools, and billing as your other Azure services. To use a custom domain name (such as contoso.com), create DNS records that map the custom domain name to the IP address. For more information, see Configure a custom domain name in Azure App Service.
  • Azure SQL Database is a relational database-as-a-service in the cloud. SQL Database shares its code base with the Microsoft SQL Server database engine. Depending on your application requirements, you can also use Azure Database for MySQL or Azure Database for PostgreSQL. These alternatives are fully managed database services based on the open-source MySQL Server and Postgres database engines.
  • Microsoft Entra ID is a cloud-based identity and access management service that lets employees access cloud apps developed for your organization.
  • Azure Monitor is a solution for collecting, analyzing, and acting on logs and metrics across your environments.
  • Azure Key Vault supports secrets management, key management, and certificate management. It can store application secrets like database connection strings.

Recommendations

Your requirements might differ from the architecture described and given in the code. The code deploys with production configurations. Use the recommendations to customize your deployment to meet your needs.

App Service plan

The App Service plan has different pricing tiers. Each pricing tier supports several instance sizes that differ by the number of cores and memory. You can change the pricing tier after deployment by selecting "Scale up (App Service Plan)" on the left navigation. Here are some App Service recommendations:

  • Run your production workload on the Basic, Standard, and Premium pricing tiers. In these three tiers, the app runs on dedicated virtual machine instances and has allocated resources that can scale out.
  • Use the Standard and Premier tiers if you need autoscale and TLS/SSL.
  • Create a different App Service plan for testing and development. Use the Free and Shared (preview) tiers for testing and development for cost efficiency. But don't use the Free and Shared tiers for production workloads. Shared resources can't scale out.
  • Make sure to delete plans that you aren't using, such as testing deployments. App Service plans are billed on a per-second basis. You're charged for the instances in the App Service plan even if the app is stopped. For more information about App Service plans and billing, see:

The ARM template below deploys to the Standard pricing tier.

SQL Database

  • Use Azure SQL Database to reduce management overhead. Azure SQL Database creates a logical construct that acts as a central administrative point for a collection of databases. This logical construct reduces management overhead. Each database within the group is deployed with a specific service tier. Within each group, the databases can't share resources. There are no compute costs for the server, but you need to specify the tier for each database. Therefore, the performance might be better because of the dedicated resources, but the cost can be higher.
  • Perform capacity planning and choose a tier and performance level that meets your requirements. SQL Database supports Basic, Standard, and Premium service tiers, with multiple performance levels within each tier measured in Database Transaction Units (DTUs).

Region

  • Create the App Service plan and the SQL Database in the same region to minimize network latency. Generally, choose the region closest to your users.
  • The resource group also has a region. It specifies where deployment metadata is stored. Put the resource group and its resources in the same region to improve availability during deployment.
  • Use the pricing calculator to estimate costs.
  • For more information, see the cost section in Microsoft Azure Well-Architected Framework.

Considerations

These considerations implement the pillars of the Azure Well-Architected Framework. The pillars are a set of guiding tenets that improve the quality of a workload. For more information, see Microsoft Azure Well-Architected Framework.

Performance efficiency

A major benefit of Azure App Service is the ability to scale your application based on load. Here are some considerations to keep in mind when planning to scale your application.

Scaling the App Service app

There are two ways to scale an App Service app:

  • Scale up means changing the instance size. The instance size determines the memory, number of cores, and storage on each VM instance. You can scale up manually by changing the instance size or the plan tier.
  • Scale out means adding instances to handle increased load. Each pricing tier has a maximum number of instances. You can scale out by manually changing the instance count or by configuring autoscaling to have Azure automatically add or remove instances based on a schedule and/or performance metrics. Each scale operation happens quickly, typically within seconds.

To enable autoscaling, create an autoscale profile that defines the minimum and maximum number of instances. You can set up schedule-based profiles to trigger scale events. For example, you can create separate profiles for weekdays and weekends. A profile can contain rules for when to add or remove instances. For example, adding two instances if CPU usage is above 70% for 5 minutes.

Recommendations for scaling a web app:

  • Limit scaling up and down as much as possible. It can trigger an application restart. Instead, scale out. Select a tier and size that meet your performance requirements under typical load and then scale out the instances to handle changes in traffic volume.
  • Enable autoscaling. If your application has a predictable, regular workload, create profiles to schedule the instance counts ahead of time. If the workload isn't predictable, use rule-based autoscaling to react to changes in load as they occur. You can combine both approaches.
  • Use CPU usage for autoscaling rules. CPU usage is generally a good metric for autoscale rules. However, you should load test your application, identify potential bottlenecks, and base your autoscale rules on that data.
  • Set a shorter cool-down period for adding instances and a longer cool-down period for removing instances. Autoscale rules include a cool-down period. The cool-down period is the interval to wait after a scale action has been completed before starting a new scale action. The cool-down period lets the system stabilize before scaling again. For example, set 5 minutes to add an instance, but 60 minutes to remove an instance. It's better to add new instances quickly under heavy load to handle the extra traffic and then gradually scale back.

Scaling SQL databases

Scale up individual databases with no application downtime if you need a higher service tier or performance level for SQL Database.

For more information, see Scale single database resources in Azure SQL Database.

Reliability

At the time of writing, the service level agreement (SLA) for App Service is 99.95%. The App Service SLA applies to both single and multiple instances. The SLA for SQL Database is 99.99% for Basic, Standard, and Premium tiers.

Backups

SQL Database provides point-in-time restore and geo-restore to restore data loss. These features are available in all tiers and are automatically enabled. You don't need to schedule or manage the backups.

Operational excellence

Create separate resource groups for production, development, and test environments. Separating environments makes it easier to manage deployments, delete test deployments, and assign access rights.

When assigning resources to resource groups, consider the following features:

  • Lifecycle. In general, put resources with the same lifecycle into the same resource group.
  • Access. You can use Azure role-based access control (RBAC) to apply access policies to the resources in a group.
  • Billing. You can view the rolled-up costs for the resource group.

For more information, see Azure Resource Manager overview.

App configurations

  • Store configuration settings as app settings. Define the app settings in your Resource Manager templates or using PowerShell. At runtime, app settings are available to the application as environment variables.
  • Never check passwords, access keys, or connection strings into source control. Instead, pass secrets as parameters to a deployment script that stores these values as app settings.
  • When you swap a deployment slot, the app settings are swapped by default. If you need different production and staging settings, you can create app settings that stick to a slot and don't get swapped.

Diagnostics and monitoring

DevOps

  • Use ARM templates to deploy Azure resources and their dependencies. The accompanying ARM template deploys a single web application. All the resources are isolated in the same basic workload. This isolation makes it easier to associate the workload's specific resources to a team. The team can then independently manage all aspects of those resources. This isolation enables the DevOps team to perform continuous integration and continuous delivery (CI/CD).
  • Use different ARM Templates and integrate them with Azure DevOps services. This setup lets you create different environments in minutes. For example, you can replicate production-like scenarios or load testing environments only when needed and save on cost.
  • Provision multiple instances of the web application. You don't want your web app to depend on a single instance and potentially create a single point of failure. Multiple instances improve resiliency and scalability.

For more information, see the DevOps section in Azure Well-Architected Framework.

Release engineering and deployment

  • Use Azure Resource Manager templates to provision Azure resources. Templates make it easier to automate deployments via PowerShell or the Azure CLI.
  • Deploy the application (code, binaries, and content files). You have several options, including deploying from a local Git repository, using Visual Studio, or continuous deployment from cloud-based source control. See Deploy your app to Azure App Service.

An App Service app always has one deployment slot named production. The production slot represents the live production site. We recommend creating a staging slot for deploying updates. The benefits of using a staging slot include:

  • You can verify the deployment succeeded before swapping it into production.
  • Deploying to a staging slot ensures that all instances are warmed up before being swapped into production. Many applications have a significant warmup and cold-start time.
  • Create a third slot to hold the last-known-good deployment. After you swap staging and production, move the previous production deployment (which is now in staging) into the last-known-good slot. That way, if you discover a problem later, you can quickly revert to the last-known-good version.

Swapping slots for production and staging deployments

  • If you revert to a previous version, make sure any database schema changes are backward compatible.
  • Don't use slots on your production deployment for testing because all apps within the same App Service plan share the same VM instances. For example, load tests might degrade the live production site. Instead, create separate App Service plans for production and test. By putting test deployments into a separate plan, you isolate them from the production version.

Security

This section lists security considerations that are specific to the Azure services described in this article. It's not a complete list of security best practices. For some other security considerations, see Secure an app in Azure App Service.

SQL Database auditing

Auditing can help you maintain regulatory compliance and get insight into discrepancies and irregularities that could indicate business concerns or suspected security violations. See Get started with SQL database auditing.

Deployment slots

Each deployment slot has a public IP address. Secure the nonproduction slots using the Microsoft Entra login so that only members of your development and DevOps teams can reach those endpoints.

Logging

Logs should never record users' passwords or other information that might be used to commit identity fraud. Scrub those details from the data before storing it.

SSL

An App Service app includes an SSL endpoint on a subdomain of azurewebsites.net at no extra cost. The SSL endpoint includes a wildcard certificate for the *.azurewebsites.net domain. If you use a custom domain name, you must provide a certificate that matches the custom domain. The simplest approach is to buy a certificate directly through the Azure portal. You can also import certificates from other certificate authorities. For more information, see buy and configure an SSL certificate for your Azure App Service.

HTTPS isn't enabled by default in the ARM template deployment. As a security best practice, your app should enforce HTTPS by redirecting HTTP requests. You can implement HTTPS inside your application or use a URL rewrite rule as described in enable HTTPS for an app in Azure App Service.

Authentication

We recommend authenticating through an identity provider (IDP), such as Microsoft Entra ID, Facebook, Google, or Twitter. Use OAuth 2 or OpenID Connect (OIDC) for the authentication flow. Microsoft Entra ID provides functionality to manage users and groups, create application roles, integrate your on-premises identities, and consume backend services such as Microsoft 365 and Skype for Business.

Avoid having the application manage user logins and credentials directly. It creates a potential attack surface. At a minimum, you would need to have an email confirmation, password recovery, and multi-factor authentication, validate password strength, and store password hashes securely. The large identity providers handle all of those things for you and are constantly monitoring and improving their security practices.

Consider using App Service authentication to implement the OAuth or OIDC authentication flow. The benefits of App Service authentication include:

  • Easy to configure.
  • No code is required for simple authentication scenarios.
  • Supports delegated authorization using OAuth access tokens to consume resources on behalf of the user.
  • Provides a built-in token cache.

Some limitations of App Service authentication:

  • Limited customization options.
  • Delegated authorization is restricted to one backend resource per login session.
  • If you use more than one IDP, there's no built-in mechanism for home realm discovery.
  • For multi-tenant scenarios, the application must implement the logic to validate the token issuer.

Deploy this scenario

This architecture includes an Azure App Service plan and an empty application. It uses Azure SQL Database, Azure Key Vault for storing the database connection string, and Azure Monitor for logging, monitoring, and alerting.

Use the following command to create a resource group for the deployment. Select the Try it button to use an embedded shell.

az group create --name basic-web-app --location eastus

Run the following command to deploy the web application and supporting infrastructure. When prompted, enter a user name and password. These values are used for accessing the Azure SQL Database instance.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

For detailed information and more deployment options, see the ARM Templates used to deploy this solution.

Basic web application ARM Template

Next steps

Tips for troubleshooting your application:

Product documentation:

Microsoft Learn modules: