Overview
In the previous posts, I talked about different scenarios of deploying a Function App with a Consumption Plan and an App Service Plan in a network-locked architecture. In this post, I will cover a different architectural solution using App Service Environment v3. I will go through the complete deployment process, where I will verify the hosting through Kudu Tools and dive deep into the DNS (Domain Name System) workings with the Function App by showing an end-to-end example of how Key Vault references can be integrated with the app. Finally, I will wrap up this post with an architectural diagram of the complete solution.
This post is a part of a series outlined below:
- Consumption Plan – talks about how a Consumption Plan can be used to architect a network-locked solution.
- App Service Plan – describes the usage of the App Service Plan and how effectively a complete network-locked architecture can be deployed.
- App Service Environment (this article) – outlines the solution with an ASE (App Service Environment) v3 by covering similar effectiveness.
Objectives
Please refer to Part 1 to understand the scenario using the simple architectural diagram as shown below.
Figure 1: A simple architecture for the scenario
Some of the important points to be noted from the scenario are:
- There is an empty
AseSubnetinside the virtual network which can be used by the App Service Environment for any networking-related purposes. - The Virtual Network used in this scenario is configured with Azure-provided DNS service as the DNS servers can be accessed via the public IP (Internet Protocol) address
168.63.129.16.
Let us revise the objective that I will try to reach in this post. The expected outcome is as follows.
A Function App that is using the above-shown storage account (
stblogazurewebjobs01) as the web jobs storage and can access network-locked Key Vault (kvblogdev01) secrets without exposing any functionality to the public internet.
With that in mind, let us look at an App Service Environment v3-based approach.
App Service Environment v3
An App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for running App Service apps securely. When you deploy an app into an App Service Environment, the app is exposed on the inbound address that is assigned to the App Service Environment.
- If your App Service Environment is deployed with an internal virtual IP (VIP) address, the inbound address for all the apps will be an address in the App Service Environment subnet.
- If your App Service Environment is deployed with an external VIP address, the inbound address will be an internet-addressable address, and your apps will be in a public Domain Name System.
As the objective is to deploy a network-locked Function App, I will use an App Service Environment with an internal VIP address as shown below.
Figure 2: Creating ASE v3 with ILB (Internal Load Balancer)
One of the caveats of provisioning an App Service Environment is that it is very time-consuming. As shown in the screenshot below, it took me almost 3 hours to provision this ASE v3. In comparison, it takes minutes to provision an App Service Plan.
Figure 3: Duration to deploy an ASE v3
Once your App Service Environment is provisioned successfully, you should be able to see that it is placed inside the Virtual Network on a dedicated subnet. Hence, no delegation is needed to access the resources inside the Virtual Network. The environment also comes with its custom domain suffix, hence a separate Private DNS Zone for this suffix is also created to enable DNS resolutions.
Figure 4: ASE v3 IP addresses
Create & Test Function App
Once the environment is ready, I will try to create a Function App using this dedicated environment and use my network-locked Storage Account for AzureWebJobsStorage as shown below.
Figure 5: Creating a Function App with ASE v3
One thing to note here is that ASE v3 works like a dedicated region and hence it is not a replacement for the App Service Plan. This means I still need an App Service Plan to host my Function Apps on it, though it will sit in the dedicated App Service Environment as opposed to a region. Again, the deployment of the App Service Plan is comparatively slower with ASE v3 as shown below.
Figure 6: App Service Plan deployment duration time in ASE v3
Once the Function App is deployed successfully, some of the things you would notice different are as follows.
The network-locked storage account has been successfully configured in the application settings as before, though a new app setting WEBSITE_VNET_ROUTE_ALL with value 1 is added automatically. This setting is required to access the resources inside the Virtual Network, which is added to the App Service Plan after enabling regional virtual network integration. Here, it is added by default.
Figure 7: Application settings of the Function App
There will be no need to have a delegated subnet for regional virtual network integration as the App Service Plan sits inside a dedicated ASE subnet. Hence, you can see that virtual network integration is now disabled.
Figure 8: Networking settings of the Function App
The function URL is slightly different as it has the App Service Environment’s domain suffix as compared to the default *.azurewebsites.net.
Figure 9: Function URL of the app
This function URL is also not accessible from the internet anymore. As the App Service Environment is using an ILB (Internal Load Balancer), all public internet access has been disabled.
Figure 10: Function in ASE v3 is not accessible from the public internet
This means that I have completely network-locked my Function App using an App Service Environment with ILB. This was not the case with my previous App Service Plan, as I was still able to access the function URL from the internet. Now, to verify if the Function App is running, I need a Virtual Machine that sits inside the Virtual Network. Using such a Virtual Machine, I should be able to access the function URL as shown below.
Figure 11: Function App in ASE v3 accessible from the Virtual Machine via Bastion
I can also verify if I can resolve the App Service Environment properly by using nslookup from the Virtual Machine itself as shown below.
Figure 12: DNS resolution of the Function App
This nslookup gives us the private IP address as 172.16.3.4 which is indeed matching with the ASE v3 Private DNS Zone as shown below. Next, I will complete the testing by verifying if I can add a network-locked Key Vault reference and successfully resolve it.
Testing DNS with Key Vault Reference
I will use the same network-locked Key Vault again with the same secret name and try to see if my new Function App sitting inside the ASE v3 can resolve it or not. I can first try resolving the Key Vault using Kudu Tools as shown below. Note that the Kudu Tools are also network-locked now and are only accessible from inside the Virtual Machine.
Figure 13: DNS resolution using the Kudu Tools
As the resolution seems to happen correctly, I can try adding this Key Vault reference. As shown below, the Key Vault reference has been resolved successfully.
Figure 14: Key Vault reference in the app settings
Wrapping Up
In this post, I tried to reach the objective of deploying a network-locked App Service Environment v3-based Function App that is supposed to leverage an existing network-locked architecture. This architectural solution is shown below.
Figure 15: Architectural solution with an App Service Environment v3-based Function App
Some important points about the Function App deployed inside an App Service Environment v3 can be listed as follows:
- The Function App is not accessible from the public internet using an ILB and can access any of the private resources inside the Virtual Network.
- The Function App is fully deployed inside the Virtual Network and leverages the architecture without using subnet delegation.
In conclusion, App Service Environment v3 is the seamless solution for deploying a network-locked Function App as it natively supports the integration of the app with the Virtual Network. On the other hand, the pricing of ASE v3 is quite high as it provides an isolated plan which is intended to run in a private, dedicated environment in the provisioned Azure datacentre.
Cross Posted on Abhinav's Blog