Deploy a line-of-business application using Azure App Service Environment v3

For customers in segments that are tightly governed and restricted by compliance, it's important to have an isolated and dedicated environment, especially for line-of-business applications. While security is front and center, these critical applications also require the ability to scale and perform under scenarios of high memory utilization or high requests per second. This solution provides an example for how you can host line-of-business applications. You can use Azure App Service Environment to ensure that both security and performance can be addressed simultaneously. When deploying this solution, you'll have the flexibility to use existing resources in your Azure landing zone, which represents your resources in the hub VNet. Or, you can deploy this solution as a self-contained workload.

This article provides a deployable architecture that aligns to our landing zone accelerator for App Service.

Architecture

Diagram that shows the architecture of the App Service Environment v3 landing zone accelerator.

The entirety of this image is in the scope of a subscription and a private DNS Zone. It's denoted by a subscription icon and a Private DNS zone icon in the top-left corner. Below these icons, two blocks are side by side. They represent two virtual networks, with VNet peering between them. The block on the left represents the hub VNet, and the block on the right represents the spoke VNet. Within the left box, there are three smaller boxes. Each box indicates a different subnet and its associated network security group. Starting from the top left is an Azure Bastion instance within the Bastion subnet, and the top right is the jumpbox VM, which resides in the jumpbox subnet. On the bottom right is the third and last box in the hub VNet, which contains the CI/CD agent server that resides in the CI/CD subnet. The box on the right, which represents the spoke VNet, contains only one smaller box, the ASE subnet that has the App Service Environment v3 instance within it. A smaller box represents the App Service Environment. The App Service icon is inside that box. On the bottom center of the image, are shared resources that are also deployed as part of the process. Starting from the left to right, the shared resources include Azure Key Vault, Azure Log Analytics workspace, and Azure Application Insights.

Download a Visio file of this architecture.

Workflow

There are three flows with callouts in this architecture: Operations (orange), Deployment (green) and User (purple).

Operations

  1. Operators or administrators will want to perform administration tasks on the continuous integration/continuous deployment (CI/CD) server, or on the Kudu endpoint for the App Service Environment (ASE). First, they'll need to connect to the Azure Bastion host.
  2. By using the Bastion host, the operator or administrator can then use Remote Desk Protocol (RDP) to access the jumpbox server.
  3. From the jumpbox server, the operator or administrator can RDP into the CI/CD server and perform the required tasks, such as agent upgrades, OS upgrades, and so on. The operator or administrator can also connect from the jumpbox server to the Kudu endpoint of the ASE instance, to perform administrative tasks or to perform advanced troubleshooting.

Deployment

  1. Deployment of the solution is performed via the CI/CD agent server. The DevOps agent on this server will connect with Azure Pipelines when a new deployment is executed.
  2. The artifacts will then be deployed to the App Service by connecting to the App Service Environment (ASE) over the VNet peering.

User

  1. Users can connect to the deployed App Service over the company's network. They can use Azure ExpressRoute or a VPN if needed, and/or over any applicable Azure VNet peering.

Components

The solution uses the following Azure services:

Alternatives

Consider adding an Azure Application Gateway before the App Service instance, to provide Web Application Firewall (WAF) functionality to protect web applications from common exploits and vulnerabilities.

A self-hosted GitHub runner can be used in place of the Azure DevOps self-hosted agent.

Considerations

These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that can be used to improve the quality of a workload. For more information, see Microsoft Azure Well-Architected Framework.

Reliability

Reliability ensures your application can meet the commitments you make to your customers. For more information, see Overview of the reliability pillar.

Security

Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Overview of the security pillar.

Cost optimization

Cost optimization is about looking at ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Overview of the cost optimization pillar.

Operational excellence

Operational excellence covers the operations processes that deploy an application and keep it running in production. For more information, see Overview of the operational excellence pillar.