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 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.
Note
This article provides a deployable architecture that aligns to the Cloud Adoption Framework guidance for App Service in Azure landing zones.
Architecture
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 an Azure 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 Azure 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 App Service Environment 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
- 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. First, they'll need to connect to the Azure Bastion host.
- By using the Azure Bastion host, the operator or administrator can then use Remote Desk Protocol (RDP) to access the jumpbox server.
- 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 App Service Environment instance, to perform administrative tasks or to perform advanced troubleshooting.
Deployment
- 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.
- The artifacts will then be deployed to the app service by connecting to the App Service Environment over the VNet peering.
User
- 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:
Azure App Service Environment v3 (ASEv3) is a feature of Azure App Service and is a single-tenant service for customers that require high scale, network isolation, security, and/or high memory utilization. Apps are hosted in App Service plans that are created in App Service Environment v3, with options of using different tiers within an Isolated V2 service plan. Compared to an earlier version of App Service Environment, numerous improvements have been made including, but not limited to, network dependency, scale time, and the removal of the stamp fee. This solution uses an App Service Environment v3 that's configured for internal access.
Azure Private DNS allows you to manage and resolve domain names within a virtual network, without needing to implement a custom DNS solution. An Azure Private DNS zone can be aligned to one or more virtual networks through virtual network links. Due to the internal nature of the App Service Environment v3 that this reference architecture uses, a private DNS zone is required to resolve the domain names of applications that are hosted on the App Service Environment.
Azure Application Insights is a feature of Azure Monitor that helps developers detect anomalies, diagnose issues, and understand usage patterns. Application Insights features extensible application performance management and monitoring for live web apps. Various platforms are supported, including .NET, Node.js, Java, and Python. It supports apps that are hosted in Azure, on-premises, in a hybrid environment, or in other public clouds. Application Insights is included as part of this reference architecture, to monitor the behaviors of the deployed application.
Azure Log Analytics is a feature of Azure Monitor that allows you to edit and run log queries with data in Azure Monitor Logs, optionally from within the Azure portal. Developers can run simple queries for a set of records or use Log Analytics to perform an advanced analysis. They can then visualize the results. Log Analytics is configured as part of this reference architecture, to aggregate all the monitoring logs for analysis and reporting.
Azure Virtual Machines is an on-demand, scalable computing resource that can be used to host several different workloads. In this reference architecture, virtual machines are used to provide a management jumpbox server, and to provide a host for the DevOps agent or GitHub runner.
Azure Key Vault is a cloud service that securely stores and accesses secrets, which range from API keys and passwords to certificates and cryptographic keys. An Azure key vault is deployed as part of this architecture's infrastructure, to facilitate secret management for future code deployments.
Azure Bastion is a platform-as-a-service that's provisioned within the developer's virtual network. It provides secure RDP/SSH connectivity to the developer's virtual machines over TLS, from the Azure portal. With Azure Bastion, virtual machines no longer require a public IP address to connect via RDP/SSH. This reference architecture uses Azure Bastion to access the DevOps agent or GitHub runner server or the management jumpbox server.
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.
- Consider your requirements for zone redundancy in this reference implementation, as well as the zone redundancy capabilities of any other Azure Services in your solution. App Service Environment v3 supports zone redundancy by spreading instances to all three zones in the target region. This configuration can only be set at the time of the App Service Environment creation, and it might not be available in all regions. See more information, see Availability zone support for App Service Environment. This reference implementation implements zone redundancy, but you can change it by cloning this repo and setting the
zoneRedundantproperty tofalse.
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.
- Employ the appropriate use of access restrictions, so that the app service is only reachable from valid locations. For example, if the app service is hosting APIs, and it's fronted by APIM, you can set up an access restriction so that the app service is only accessible from APIM.
- Since this reference implementation deploys an App Service Environment into a virtual network (referred to as an internal App Service Environment), all applications deployed to the App Service Environment are inherently network-isolated, at the scope of the virtual network.
- Store application secrets (database credentials, API tokens, and private keys) in Azure Key Vault. Configure your App Service app to access them securely with a managed identity. Determine when to use Azure Key Vault vs Azure App Configuration.
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.
- Although there's no stamp fee for an App Service Environment v3 instance, there's a charge that's levied when no app service Plans are configured within the App Service Environment v3 instance. This charge is levied at the same rate as one instance of a Windows I1v2 instance, for the region in which the App Service Environment v3 instance is deployed.
- When configured to be zone redundant, the charging model is adjusted to account for the underlying infrastructure that's deployed in this configuration. You might be liable for additional instances, as per ASEv3 Pricing.
- For App Service Environment v3 App Service plans (known as Isolated V2 App Service plans), use Azure Reservations and Azure savings plan for compute with a one-year or three-year contract and receive significant savings off pay-as-you-go prices. For more information, see How reservation discounts apply to Isolated v2 instances.
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.
- Use Application Insights or another application performance management solution to monitor and learn how your application behaves in different environments.
- There are two ways to enable Application Insights. For different environments, collect telemetry data into different Application Insights instances.
- If your application has multiple components separated into different services, you might want to examine their behavior together. Collect their telemetry data into the same Application Insights instance, but label them with different cloud role names.
- Export the Application Insights data to an Azure Log Analytics workspace. We recommend you use a single workspace for the organization.
- Include operational dashboards in application and feature design, to ensure the solution can be supported in production.
- Implement health checks for your endpoints, and then use them for health probes, dependency checks, and availability tests.
- Consider using prefixes and suffixes with well-defined conventions, to uniquely identify every deployed resource. These naming conventions avoid conflicts, when you deploy solutions next to each other and improve the overall team agility and throughput.
- Depending on the network configuration, App Service might not be reachable from the public internet, and the use of public hosted agents won't work for deployments. Use self-hosted agents in that scenario.
Deploy this scenario
To get started and better understand the specifics of this implementation, review the reference implementation resources, at User Guide for Reference Implementation Deployment.
- We recommend that you clone this repo and modify the reference implementation resources to suit your requirements and your organization's specific landing zone guidelines.
- Before deploying, ensure that the service principal that's used to deploy the solution has the required permissions to create the resource types that we listed above.
- Consider the CI/CD service that you'll use to deploy the reference implementation. As this reference implementation is an internal App Service Environment, you'll need a self-hosted agent to execute the deployment pipelines. You have the choice to use either a DevOps agent or a GitHub runner. Refer to the user guide on the specific configuration values that are required.
- Consider the regions to which you intend to deploy this reference implementation. Consult the ASEv3 Regions list to ensure the selected regions are enabled for deployment.
Contributors
This article is maintained by Microsoft. It was originally written by the following contributors.
Principal authors:
- Pete Messina | Senoir Cloud Solution Architect
- Nabeel Prior | Senior Cloud Solution Architect
To see non-public LinkedIn profiles, sign in to LinkedIn.
Next steps
- Security in Azure App Service
- Networking for App Service
- Cloud Adoption Framework guidance for App Service in Azure landing zones
Learn more about these key services:
- Azure App Service Environment v3 (ASEv3)
- Azure Private DNS Zones
- Azure Application Insights
- Azure Log Analytics
- Azure Virtual Machines overview
- Azure Key Vault concepts
- Azure Bastion