Edit

Share via

Basic web application

Azure App Service
Azure Monitor
Azure SQL Database

This article provides a basic architecture intended for learning about running web applications on Azure App Service in a single region.

Important

This architecture isn't meant to be used for production applications. It's intended to be an introductory architecture you can use for learning and proof of concept (POC) purposes. When designing your production Azure App Service application, see the Baseline highly available zone-redundant web application.

Important

GitHub logo The guidance is backed by an example implementation which showcases this basic App Service implementation on Azure. This implementation can be used as a basis for your POC to experience working with Azure App Service.

Architecture

Diagram that shows a basic App Service architecture.

Figure 1: Basic Azure App Service architecture

Download a Visio file of this architecture.

Workflow

  1. A user issues an HTTPS request to the App Service's default domain on azurewebsites.net. This domain automatically points to your App Service's built-in public IP. The TLS connection is established from the client directly to app service. The certificate is managed completely by Azure.
  2. Easy Auth, a feature of Azure App Service, ensures that the user accessing the site is authenticated with Microsoft Entra ID.
  3. Your application code deployed to App Service handles the request. For example, that code might connect to an Azure SQL Database instance, using a connection string configured in the App Service configured as an app setting.
  4. The information about original request to App Service and the call to Azure SQL Database are logged in Application Insights.

Components

  • Microsoft Entra ID is a cloud-based identity and access management service. It provides a single identity control plane to manage permissions and roles for users accessing your web application. It integrates with App Service and simplifies authentication and authorization for web apps.
  • App Service is a fully managed platform for building, deploying, and scaling web applications.
  • Azure Monitor is a monitoring service that collects, analyzes, and acts on telemetry data across your deployment.
  • Azure SQL Database is a managed relational database service for relational data.

Recommendations and considerations

The components listed in this architecture link to Azure Well-Architected service guides. Service guides detail recommendations and considerations for specific services. This section extends that guidance by highlighting key Azure Well-Architected Framework recommendations and considerations that apply to this architecture. For more information, see Microsoft Azure Well-Architected Framework.

This basic architecture isn't intended for production deployments. The architecture favors simplicity and cost efficiency over functionality to allow you to evaluate and learn Azure App Service. The following sections outline some deficiencies of this basic architecture, along with recommendations and considerations.

Reliability

Reliability ensures your application can meet the commitments you make to your customers. For more information, see Design review checklist for Reliability.

Because this architecture isn't designed for production deployments, the following outlines some of the critical reliability features that are omitted in this architecture:

  • The App Service Plan is configured for the Standard tier, which doesn't have Azure availability zone support. The App Service becomes unavailable in the event of any issue with the instance, the rack, or the datacenter hosting the instance.
  • The Azure SQL Database is configured for the Basic tier, which doesn't support zone-redundancy. This means that data isn't replicated across Azure availability zones, risking loss of committed data in the event of an outage.
  • Deployments to this architecture might result in downtime with application deployments, as most deployment techniques require all running instances to be restarted. Users may experience 503 errors during this process. This is addressed in the baseline architecture through deployment slots. Careful application design, schema management, and application configuration handling are necessary to support concurrent slot deployment. Use this POC to design and validate your slot-based production deployment approach.
  • Autoscaling is not enabled in this basic architecture. To prevent reliability issues due to lack of available compute resources, you'd need to overprovision to always run with enough compute to handle max concurrent capacity.

See how to overcome these reliability concerns in the reliability section in the Baseline highly available zone-redundant web application.

If this workload will eventually require a multi-region active-active or active-passive architecture, see the following resources:

Security

Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Design review checklist for Security.

Because this architecture isn’t designed for production deployments, the following outlines some of the critical security features that were omitted in this architecture, along with other reliability recommendations and considerations:

  • This basic architecture doesn't implement network privacy. The data and management planes for the resources, such as the Azure App Service and Azure SQL Server, are reachable over the public internet. Omitting private networking significantly increases the attack surface of your architecture. To see how implementing private networking ensures the following security features, see the networking section of the Baseline highly available zone-redundant web application:

    • A single secure entry point for client traffic
    • Network traffic is filtered both at the packet level and at the DDoS level.
    • Data exfiltration is minimized by keeping traffic in Azure by using Private Link
    • Network resources are logically grouped and isolated from each other through network segmentation.

  • This basic architecture doesn't include a deployment of the Azure Web Application Firewall. The web application isn't protected against common exploits and vulnerabilities. See the baseline implementation to see how the Web Application Firewall can be implemented with Azure Application Gateway in an Azure App Services architecture.

  • This basic architecture stores secrets such as the Azure SQL Server connection string in App Settings. While app settings are encrypted, when moving to production, consider storing secrets in Azure Key Vault for increased governance. An even better solution is to use managed identity for authentication and not have secrets stored in the connection string.

  • Leaving remote debugging and Kudu endpoints enabled while in development or the proof of concept phase is fine. When you move to production, you should disable unnecessary control plane, deployment, or remote access.

  • Leaving local authentication methods for FTP and SCM site deployments enabled is fine while in the development or proof of concept phase. When you move to production, you should disable local authentication to those endpoints.

  • You don't need to enable Microsoft Defender for App Service in the proof of concept phase. When moving to production, you should enable Defender for App Service to generate security recommendations you should implement to increase your security posture and to detect multiple threats to your App Service.

  • Azure App Service includes an SSL endpoint on a subdomain of azurewebsites.net at no extra cost. HTTP requests are redirected to the HTTPS endpoint by default. For production deployments, you'll typically use a custom domain associated with application gateway or API management in front of your App Service deployment.

  • Use the integrated authentication mechanism for App Service ("EasyAuth"). EasyAuth simplifies the process of integrating identity providers into your web app. It handles authentication outside your web app, so you don't have to make significant code changes.

  • Use managed identity for workload identities. Managed identity eliminates the need for developers to manage authentication credentials. The basic architecture authenticates to SQL Server via password in a connection string. Consider using managed identity to authenticate to Azure SQL Server.

For some other security considerations, see Secure an app in Azure App Service.

Operational excellence

Operational excellence covers the operations processes that deploy an application and keep it running in production. For more information, see Design review checklist for Operational Excellence.

The following sections provide guidance around configuration, monitoring, and deployment of your App Service application.

App configurations

Because the basic architecture isn't intended for production, it uses App Service configuration to store configuration values and secrets. Storing secrets in App Service configuration is fine for the PoC phase. You aren't using real secrets and don't require secrets governance that production workloads require.

The following are configuration recommendations and considerations:

  • Start by using App Service configuration to store configuration values and connection strings in proof of concept deployments. App settings and connection strings are encrypted and decrypted just before being injected into your app when it starts.
  • When you move into production phase, store your secrets in Azure Key Vault. The use of Azure Key Vault improves the governance of secrets in two ways:
    • Externalizing your storage of secrets to Azure Key Vault allows you to centralize your storage of secrets. You have one place to manage secrets.
    • Using Azure Key Vault, you are able to log every interaction with secrets, including every time a secret is accessed.
  • When you move into production, you can maintain your use of both Azure Key Vault and App Service configuration by using Key Vault references.

Diagnostics and monitoring

During the proof of concept phase, it's important to get an understanding of what logs and metrics are available to be captured. The following are recommendations and considerations for monitoring in the proof of concept phase:

  • Enable diagnostics logging for all items log sources. Configuring the use of all diagnostic settings helps you understand what logs and metrics are provided for you out of the box and any gaps you'll need to close using a logging framework in your application code. When you move to production, you should eliminate log sources that are not adding value and are adding noise and cost to your workload's log sink.
  • Configure logging to use Azure Log Analytics. Azure Log Analytics provides you with a scalable platform to centralize logging that is easy to query.
  • Use Application Insights or another Application Performance Management (APM) tool to emit telemetry and logs to monitor application performance.

Deployment

The following lists guidance around deploying your App Service application.

  • Follow the guidance in CI/CD for Azure Web Apps with Azure Pipelines to automate the deployment of your application. Start building your deployment logic in the PoC phase. Implementing CI/CD early in the development process allows you to quickly and safely iterate on your application as you move toward production.
  • Use ARM templates to deploy Azure resources and their dependencies. It's important to start this process in the PoC phase. As you move toward production, you want the ability to automatically deploy your infrastructure.
  • Use different ARM Templates and integrate them with Azure DevOps services. This setup lets you create different environments. For example, you can replicate production-like scenarios or load testing environments only when needed and save on cost.

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

Containers

The basic architecture can be used to deploy supported code directly to Windows or Linux instances. Alternatively, App Service is also a container hosting platform to run your containerized web application. App Service offers various built-in containers. If you are using custom or multi-container apps to further fine-tune your runtime environment or to support a code language not natively supported, you'll need to introduce a container registry.

Control plane

During the POC phase, get comfortable with Azure App Service's control plane as exposed through the Kudu service. This service exposes common deployment APIs, such as ZIP deployments, exposes raw logs and environment variables.

If using containers, be sure to understand Kudu's ability to Open an SSH session to a container to support advanced debugging capabilities.

Performance efficiency

Performance efficiency is the ability of your workload to scale to meet the demands placed on it by users in an efficient manner. For more information, see Design review checklist for Performance Efficiency.

Because this architecture isn't designed for production deployments, the following outlines some of the critical performance efficiency features that were omitted in this architecture, along with other recommendations and considerations.

An outcome of your proof of concept should be SKU selection that you estimate is suitable for your workload. Your workload should be designed to efficiently meet demand through horizontal scaling by adjusting the number of compute instances deployed in the App Service Plan. Do not design the system to depend on changing the compute SKU to align with demand.

  • The App Service in this basic architecture doesn't have automatic scaling implemented. The service doesn't dynamically scale out or in to efficiently keep aligned with demand.
    • The Standard tier does support auto scale settings to allow you to configure rule-based autoscaling. Part of your POC process should be to arrive at efficient autoscaling settings based on your application code's resource needs and expected usage characteristics.
    • For production deployments, consider Premium tiers that support automatic autoscaling where the platform automatically handles scaling decisions.
  • Follow the guidance to scale up individual databases with no application downtime if you need a higher service tier or performance level for SQL Database.

Deploy this scenario

The guidance is backed by an example implementation that showcases a basic App Service implementation on Azure.

Next steps

Baseline highly available zone-redundant web application

Product documentation:

Microsoft Learn modules: