Azure App Service Environment Set up

This article provides a comprehensive guide on creating an App Service Environment v3 (ASEv3) in Azure to ensure secure, reliable, and scalable applications. The ASE allows users to deploy web applications into a virtual network, providing isolation and security. Furthermore, this article delves into the use case of ASE, different plans available, considerations for subnets, custom domain integration, and the secure execution of apps within the ASE environment. This article is an essential read for developers and system administrators who are looking to deploy PaaS applications securely and at scale on Azure.

Introduction

An application requires deployment in multiple environments, necessitating the creation of a distinct ASE for each environment to maintain segregation. For instance, in this article, we will examine the Dev, QA, and Prod environments, requiring three ASE instances associated with their respective environment-specific custom domains. These needs little planning as the ASE needs a dedicated subnet, however, a subnet with sufficient buffer should be prepared based on the anticipated load and scaling instances. Kindly find our point of view below, which includes the entire configuration for your applications across different environments. Our suggestion is to design ASE subnets according to the specific environments and applications they will host. Please see our point of view on this below.

This blog is part of series based on our cloud migration experience which you can read @ Migration to Azure: Our Journey to the Cloud — blog.

Prerequisite:

1. Virtual network where App Service Environment to be hosted
2. Dedicated subnet for each App Service Environment. Any App instance provisioned will gets its private IP from this subnet range.

Let’s create an ASE for Dev environment, here we’ll use Azure Portal:

While creating the ASE, either use an existing resource group or create a new one. Additionally, there are two options for creating the ASE: an internal ASE or an external ASE. It is suggested that you create an internal ASE and then use an Application Gateway to make the apps accessible externally. Please be cautious when choosing the name for the ASE, as it will be appended as a suffix to the native domain of any applications that are hosted within it.

Figure 2: Create ASE

Hosting: This is where we configure our ASE hosting environment. Some decision needs to be made in the setting right configuration for ASE hosting.

Physical hardware isolation: Our applications are hosted in App Service plans within an App Service Environment. These plans act as provisioning profiles for the application host during operation. If you require true hardware isolation, you may enable dedicated server hosting for the App Service plans, but only if necessary. Otherwise, it’s recommended to disable dedicated hosting and use virtual isolated hardware. It’s important to understand the limitations of dedicated hosting before making this decision. https://learn.microsoft.com/en-us/azure/app-service/environment/overview#dedicated-environment.

Zone redundancy: Deploying apps as zone redundant is strongly advised, although it can be opted out for non-production environments if you have well-established DevOps pipelines. It’s worth noting that this decision only applies during deployment, and it’s not possible to change zone redundancy after deployment has occurred.

Figure 3: Hosting

Networking: An App Service Environment is a deployment of Azure App Service into a subnet in your Azure Virtual Network (VNet). This is a critical step as it involves selecting the appropriate VNET and Subnet for your ASE, which will be used to assign IP addresses to any apps hosted within it.

Subnet: The subnet that will host an ASE needs to be empty, as the ASE will occupy all IP addresses in the subnet. This means that you cannot have any other resources deployed in the same subnet as the ASE.

Additionally, the recommended size for the subnet is /24, which provides 256 IP addresses. This is sufficient to support the default number of instances in an ASE, as well as any additional instances you may want to add in the future. It’s also important to note that the subnet size cannot be /28 or above. This is because the ASE requires a minimum number of available IP addresses, and a subnet of /28 or above does not provide enough addresses to meet this requirement.

Overall, when deploying an ASE, it’s important to carefully consider the VNet and subnet configuration to ensure that it meets the necessary requirements and can support the desired level of capacity and scalability.

DNS: When creating an Azure App Service Environment (ASE), there is an option to select either Azure DNS Private Zones for your domain names or you can use your own custom DNS solution.

Inbound IP Address: It is recommended to use automatic IP assignment to avoid the overhead of manual maintenance. However, if a specific IP address needs to be assigned to the ASE, manual IP assignment can be chosen and a private IP from the subnet range can be provided.

Figure 4: Networking

Tags: Using tags with ASE can help you manage and organize your resources more effectively, making it easier to search and filter resources and apply governance policies. It is a best practice to apply certain standard tags to all Azure resources, including Azure App Service Environments (ASE), in order to set appropriate governance on the resources. Here are some of the recommended tags that should be applied to all resources:

Figure 5: Tags

By applying these standard tags to all Azure resources, including ASEs, you can ensure that appropriate governance is applied to your resources and that they are managed effectively. Additionally, using these tags can help with organizing resources, tracking costs, and assigning responsibility to the appropriate owners.

Review and Create: It is important to carefully review and verify all the settings including the name, resource group, redundancy, VNET, subnets, DNS settings, and tags to ensure they meet your requirements. Once you are satisfied with the settings, you can proceed to create the ASE. Keep in mind that the provisioning process may take several hours, typically around 2–3 hours.

Figure 6: Review and create ASE

App Service Environment (ASE), it provides a fully isolated and dedicated environment for running your web applications, including the ability to configure custom domains for your applications. However, to secure the communication between the client and the server, you will need to add an SSL/TLS certificate for your custom domain.

An SSL/TLS certificate is used to encrypt the data transmitted between the client and the server, preventing unauthorized access to the sensitive information exchanged during the communication. Without a valid SSL/TLS certificate, any communication between the client and the server will be vulnerable to interception, data theft, and other security threats.

When you configure a custom domain for your App Service Environment, you can either use a self-signed certificate or a certificate from a trusted Certificate Authority (CA) to secure the communication with your custom domain. However, using a self-signed certificate is not recommended for production environments, as it can cause trust issues with the users and browsers.

Therefore, it is highly recommended to obtain a certificate from a trusted CA, such as GlobalSign or DigiCert, and install it on your App Service Environment. This will ensure that your custom domain is secure, trusted, and can be accessed by your users without any security warnings or errors.

Please follow below points to ensure the procurement of the certificate for custom domain suffix that must be stored in Azure Key Vault. Your certificate must be a wildcard certificate for the custom domain name that you would add in the suffix. For. e.g.: for your app to be hosted in ASE that you need to be accessible on bookshow.mycinema.com would need certificate covering *.mycinema.com.

1. Purchase or obtain an SSL/TLS certificate from a trusted Certificate Authority (CA). You will need to provide them with the domain name(s) that the certificate will cover.
2. Once you have obtained the certificate, you will need to export it as a .pfx file, which includes the private key.
3. Upload the .pfx file to your Azure Key Vault. This is a secure repository for storing keys and secrets, including SSL/TLS certificates.
4. Add the (System assigned) identity to the ASE. This is required to grant necessary (least privileged) access on the other resources.
5. Grant this identity access to Key Vault from where the Certificate to be referenced from, to associate with the custom domain.
6. In the Azure portal, navigate to your ASE, select the “Custom domain suffix” under Settings, and Custom domain name that aligns with the certificate.
7. Under Managed identity select the System assigned. This is the identity that was granted access to Key vault to reference the certificate.
8. Key Vault certificate secret URL — Select Certificate. Here you’ll be prompted with the pane to select Subscription -> Key Vault -> Certificate to add with the custom domain suffix.
9. Once the Certificate is added, save the configurations.
10. Now your ASE has the require custom domain suffix added and ready to host the applications.

Figure 7: Identity for ASE

Figure 8: ASE Domain suffix

Figure 9: SSL Certificate from Key Vault

Pricing

By now we have the App Service Environment created with Domain name suffix. The pricing structure for App Service Environment v3 depends on the type of deployment for the environment. There are three distinct pricing models available, which include:

App Service Environment v3: In the case where the App Service Environment has no resources, you will be billed as if you have a single Windows I1v2 instance. This charge for a single instance is not added on top of other charges but is only applicable when the environment has no resources. Please refer below the indicative charges for this plan for various combinations (plans, hourly, monthly and RI). We suggest to look at this always for the latest pricing on the Isolated v2 Service Plan: https://azure.microsoft.com/en-us/pricing/details/app-service/windows/

Figure 10: Various pricing based on plan and RI

Zone redundant App Service Environment v3: There’s a minimum charge of nine instances and there are no extra fees for utilizing availability zone support if you have nine or more instances in your App Service plan. However, if you have fewer than nine instances, regardless of their size, in your zone redundant App Service Environment, the difference between the running instance count and nine will be charged as additional Windows I1v2 instances.

Dedicated host App Service Environment v3: When setting up an App Service Environment v3 with a dedicated host deployment, you will be charged for two dedicated hosts (please refer below pricing structure). As the workload scales, charges will be based on a specialized Isolated v2 rate per vCore. Each instance type uses a different number of vCores, with I1v2 using two vCores, I2v2 using four vCores, and I3v2 using eight vCores per instance.

Create an App Service

Now time for an action to create a Web App in the App Service environment. The process is similar to creating a regular App Service, but you need to ensure that you select your previously created App Service environment as the Region. When selecting the region, take note of the domain extension that appears under the Name text box, as it will automatically switch to your ASE default domain.

Figure 11: Create Web App in ASE

Overall, when an app has multiple instances in an ASE, each instance has its own private IP address and ASE load balancer is responsible for distributing incoming traffic across the available App Service instances (based on the inbuilt configured load-balancing algorithm).

Once the Web is created in the ASE, please note the Domains of the App. You will see Default Domain and App Service Environment domain, that would name: <AppService.Name>.<ASE.Domain.Suffix>. In case your domain suffix was mycinema.com and App name is ticketsInWest, then ASE domain on App service would be ticketsInWest.mycinema.com with certificate automatically associated with the domain.

Figure 12: Validate Domain name

Conclusion

In conclusion, App Service Environment provides a secure and scalable platform for hosting your web applications with the benefits of isolation, customizability, and enhanced networking capabilities. It is particularly suitable for organizations that require a high level of control and compliance over their web applications, such as those in the finance, healthcare, and government sectors. With the ability to deploy ASE in multiple regions and connect to on-premises resources, it provides a versatile solution for hosting and managing your web applications. I hope that this technical blog has provided you with valuable insights on how to provision an App Service Environment, the prerequisites required, ways to establish secure communication with SSL certificates, and how to add custom domains to the environment.”