Securely managed web applications
This article describes how to deploy secure applications by using the App Service Environment. This architecture uses Azure Application Gateway and Azure Web Application Firewall to restrict application access from the internet. This article also explains how to integrate continuous integration and continuous deployment (CI/CD) with App Service Environments by using Azure DevOps.
Industries like banking and insurance often use this solution because customers value both platform-level and application-level security. To demonstrate these concepts, the following example application allows users to submit expense reports.
Architecture
Download a Visio file of this architecture.
Dataflow
The following dataflow corresponds to the previous diagram:
HTTP and HTTPS requests reach the application gateway.
Optionally, Microsoft Entra authentication is enabled for the web app. After the traffic reaches the application gateway, the user is prompted to supply credentials to authenticate with the application. The diagram doesn't show this step.
The user requests flow through the internal load balancer (ILB) of the environment, which routes the traffic to the expenses web app.
The user creates an expense report.
As part of creating the expense report, the deployed API app is invoked to retrieve the user's manager name and email.
The system stores the expense report in Azure SQL Database.
To facilitate continuous deployment, code is checked into the Azure DevOps instance.
The build virtual machine (VM) includes the Azure DevOps agent. This agent enables the build VM to pull the web app artifacts and use them to deploy the web app to the App Service Environment. The build VM resides in a subnet within the same virtual network as the App Service Environment.
Components
The App Service Environment provides a fully isolated, dedicated environment to securely run the application at high scale. Both the App Service Environment and its workloads reside behind a virtual network, so the setup adds an extra layer of security and isolation. This scenario uses an ILB App Service Environment to meet the need for high scale and isolation.
This workload uses the App Service Isolated pricing tier. The application runs in a private dedicated environment in an Azure datacenter that uses faster processors and solid-state drive (SSD) storage, and provides the maximum scale-out capabilities.
The Web Apps and API Apps features of App Service host web applications and RESTful APIs. These apps and APIs are hosted on the Isolated service plan, which also provides autoscaling, custom domains, and other capabilities in a dedicated tier.
Application Gateway is a layer-7 web traffic load balancer that manages traffic to the web application. It provides Secure Sockets Layer (SSL) offloading, which removes the overhead of decrypting traffic from the web servers that host the application.
Web Application Firewall is a feature of Application Gateway that enhances security. The web application firewall uses Open Worldwide Application Security Project (OWASP) rules to protect the web application against attacks, such as cross-site scripting, session hijacks, and SQL injection.
SQL Database stores the application's data. Most of the data is relational, with some of the data stored as documents and blobs.
Azure Virtual Network provides various networking capabilities in Azure. You can peer virtual networks together and establish connections with on-premises datacenters via ExpressRoute or a site-to-site virtual private network (VPN). This scenario enables a service endpoint on the virtual network to ensure that the data flows only between the Azure virtual network and the SQL Database instance.
Azure DevOps supports agile development by helping teams collaborate during sprints and by providing tools to create build and release pipelines.
An Azure build VM enables the installed agent to pull down the respective build and deploy the web app to the environment.
Alternatives
An App Service Environment can run regular web apps on Windows or, as in this example, web apps that run as Linux containers deployed inside the environment. This scenario uses an App Service Environment to host these single-instance containerized applications. Consider the following alternatives when you design your solution:
Azure Container Apps is a serverless platform that reduces infrastructure overhead and saves cost while running containerized applications. It eliminates the need to manage server configuration, container orchestration, and deployment details. Container Apps provides all the up-to-date server resources required to keep your applications stable and secure.
Azure Kubernetes Service (AKS) is an open-source project and an orchestration platform designed to host complex multicontainer applications that typically use a microservices-based architecture. AKS is a managed Azure service that simplifies provisioning and configuring a Kubernetes cluster. You must have significant knowledge of the Kubernetes platform to support and maintain it, so hosting a small number of single-instance containerized web applications might not be the best option.
Use the following alternative for the data tier:
- Azure Cosmos DB is a good option if most of your data is in nonrelational format. This service provides a platform to run data models such as MongoDB, Cassandra, graph data, or simple table storage.
Potential use cases
Consider this solution for the following use cases:
- Build an Azure web app that requires extra security.
- Provide dedicated tenancy rather than shared tenant App Service plans.
- Use Azure DevOps with an internally load-balanced App Service Environment.
Address TLS and DNS design decisions
The Domain Name System (DNS) settings for the default domain suffix of the App Service Environment don't restrict application reachability to those names. The custom domain suffix feature for an ILB App Service Environment allows you to use your own domain suffix to access the applications hosted in your App Service Environment.
A custom domain suffix defines a root domain that the App Service Environment uses. For an ILB App Service Environment, the default root domain is appserviceenvironment.net. An ILB App Service Environment is internal to a customer's virtual network, so customers can use a root domain in addition to the default domain that aligns with their virtual network environment. For example, Contoso Corporation might use a default root domain of internal.contoso.com for apps intended to be resolvable and reachable only within Contoso's virtual network. An app in this virtual network can be reached by accessing APP-NAME.internal.contoso.com.
The custom domain suffix applies to the App Service Environment. This feature differs from a custom domain binding on an individual App Service instance.
If the certificate used for the custom domain suffix contains a Subject Alternate Name (SAN) entry for *.scm.CUSTOM-DOMAIN, the Source Control Manager (SCM) site becomes reachable from APP-NAME.scm.CUSTOM-DOMAIN. You can only access SCM over custom domain by using basic authentication. Single sign-on is only available when you use the default root domain.
Consider the following factors when you manage certificates on an ILB App Service Environment:
Store a valid SSL or Transport Layer Security (TLS) certificate in an Azure key vault in .PFX format.
Ensure that the certificate is less than 20 KB.
Use a wildcard certificate for the selected custom domain name.
Configure a system-assigned or user-assigned managed identity for your App Service Environment. The managed identity authenticates against the Azure key vault where the SSL or TLS certificate resides.
Expect the App Service Environment to apply certificate changes within 24 hours after rotation in a key vault.
Network access to Azure Key Vault
You can access the key vault publicly or through a private endpoint that's reachable from the subnet where the App Service Environment is deployed.
If you use public access, you can secure your key vault to only accept traffic from the outbound IP address of the App Service Environment.
The App Service Environment uses the platform outbound IP address as the source address when it accesses the key vault. You can find this IP address in the IP Addresses page in the Azure portal.
DNS configuration
To access your applications in your App Service Environment by using your custom domain suffix, configure your own DNS server or configure DNS in an Azure private DNS zone for your custom domain. For more information, see DNS configuration.
Secure unique default hostname
The secure unique default hostname feature provides a long-term solution to protect your resources from dangling DNS entries and subdomain takeover. If you enable this feature for your App Service resources, no one outside your organization can recreate resources that have the same default hostname. This protection prevents malicious actors from exploiting dangling DNS entries and taking over subdomains. For more information, see Secure unique default hostnames.
Considerations
These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that you can use to improve the quality of a workload. For more information, see Well-Architected Framework.
Reliability
Reliability helps ensure that your application can meet the commitments that you make to your customers. For more information, see Design review checklist for Reliability.
Consider using geo-distributed scale with App Service Environments for greater resiliency and scalability.
Review the typical design patterns for resiliency and implement them where appropriate.
Consider using active geo-replication for the data tier and geo-redundant storage for images and queues.
For more information, see the following resources:
Availability
Consider applying the typical design patterns for availability when you build your cloud application.
Review the availability considerations in the appropriate App Service web application reference architecture.
For other availability considerations, see Reliability guides by service.
Security
Security provides assurances against deliberate attacks and the misuse of your valuable data and systems. For more information, see Design review checklist for Security.
Review the security considerations in the appropriate App Service web application reference architecture.
Consider following the Security Development Lifecycle process to help developers build more secure software and address security compliance requirements while reducing development cost.
Use Azure DDoS Protection and application-design best practices to improve protection against distributed denial-of-service (DDoS) attacks. Enable DDoS Protection on perimeter virtual networks.
Cost Optimization
Cost Optimization focuses on ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Design review checklist for Cost Optimization.
Explore the cost of running this scenario. The following sample cost profiles are based on expected traffic. All services are preconfigured in the cost calculator.
Small deployment: This pricing example represents the components for a minimum production-level instance that serves a few thousand users each month. The app uses a single small instance of an isolated web app. Each extra component scales to a Basic tier to minimize cost while ensuring service-level agreement (SLA) support and sufficient capacity to handle a production-level workload.
Medium deployment: This pricing example represents the components for a moderate-size deployment that serves approximately 100,000 users each month. A moderately sized single isolated App Service instance manages the traffic. The Application Gateway and SQL Database capacity increase to support the added workload.
Large deployment: This pricing example represents the components for a high-scale application that serves millions of users each month and moves terabytes of data. This level of usage requires high-performance, isolated-tier web apps deployed in multiple regions and fronted by Azure Traffic Manager. The estimate includes Traffic Manager and extra Application Gateway and Virtual Network instances. The capacity of the SQL Database increases to support the added workload.
To see the pricing for your particular use case, change the appropriate variables to match your expected traffic.
Performance Efficiency
Performance Efficiency refers to your workload's ability to scale to meet user demands efficiently. For more information, see Design review checklist for Performance Efficiency.
Understand how scale works in App Service Environments.
Review best practices for cloud apps autoscale.
Understand the typical design patterns for scalability when you build a cloud application.
Review the scalability considerations in the appropriate App Service web application reference architecture.
Contributors
Microsoft maintains this article. The following contributors wrote this article.
Principal author:
- Nicholas McCollum | Principal Customer Engineer
To see nonpublic LinkedIn profiles, sign in to LinkedIn.
Next steps
- Integrate your ILB App Service Environment with an Azure application gateway
- Geo-distributed scale with App Service Environments