Azure Function is a serverless service offering on Azure that allows one to write less code, maintain less infrastructure, and focus on writing code to solve the problem at hand. The deployment of Azure Function is usually not too complicated, but it tends to get harder to manage when deployed with various network integration approaches.
With this 3-part blog series, I will try to show all ways in which a network-locked Function App can be deployed effectively. I will aim to ensure that the components of the app are not accessible via the public internet. Starting with a basic architecture that will have all the networking capabilities to demonstrate this scenario, I will try to show diverse ways in which to deploy a Function App inside the network-locked configuration.
This post is a part of a series outlined below:
To demonstrate how a network-locked Function App can be deployed, let's start with a simple architecture that is to be leveraged by a Function App. This architecture diagram is shown below.
Figure 1: A simple architecture for the scenario
Some important considerations from the above architecture:
vnet-blog-dev-01
is being used with an Azure-provided DNS (Domain Name Resolution) server with the IP (Internet Protocol) address 168.63.129.16
(reference: official documentation). Figure 2: Virtual Network
AspSubnet
and AseSubnet
are dedicated subnets for App Service Plan and App Service Environment respectively, which are currently blank and can be used by any function app if needed.Figure 3: Network-locked Storage Account
Figure 4: Network-locked Key Vault
Assuming the above-shown architecture is already deployed correctly, my objective is to deploy a function app where all the components used by the app, including the functions, are not accessible from the public internet. Considering this, the outcome should be:
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 endpoint to the public internet.
In this Part 1 of the blog series, I will try to reach the above objective by using a Consumption Plan-based network-locked Function App. I am looking to create a Function App that is completely network-locked and can access all the private resources inside the Virtual Network.
First, I will try to deploy this app. As stated above, it is required to use a network-locked Storage Account (stblogazurewebjobs01
), which is not accessible from the public internet, as the main web jobs Storage Account for the app.
While trying to deploy this Function App, I can see that the required Storage Account is accessible from the dropdown in the Hosting section as shown below. But will the deployment work?
Figure 5: Deploying a Function App with a Consumption Plan
Unfortunately, Consumption Plans do not support the usage of the network-locked Storage Account, as they do not have the support for integrating to the Virtual Networks.
An issue has been opened to add this support in 2018 as the Consumption Plans are the only true serverless offering from Azure, but this addition is not coming anytime soon. Hence, the deployment will not complete, and an error is thrown as shown below.
Figure 6: Error while deploying a Consumption Plan-based Function App
The error is quite descriptive with the message “Creation of storage file share failed with: 'The remote server returned an error: (403) Forbidden.'”, which points out that the Storage Account is not accessible. This is because the Consumption Plan is not sitting inside the Virtual Network.
In this post, I tried to deploy a complete network-locked Consumption Plan-based Function App that is supposed to leverage an existing complicated networking architecture. This architectural solution is shown below.
Figure 7: Architectural solution with a Consumption Plan-based Function App
Some important points about the Function App deployed using a Consumption Plan can be listed as follows:
In conclusion, a Consumption Plan will not work to solve the required objective. In the next post, I will be covering how an App Service Plan can be used to create another architectural solution and provide details on how effectively it can be used to solve the current problem.
Cross Posted on Abhinav's Blog