Effectively deploying a network-locked Function App – Part 1: Consumption Plan

Overview

• Overview
• Scenario
• Consumption Plan
• Wrapping Up

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: 

• Consumption Plan (this article) – 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 a completely network-locked architecture can be deployed effectively. 
• App Service Environment – outlines the solution with an ASE (App Service Environment) v3 by covering similar effectiveness. 

Scenario

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.

Some important considerations from the above architecture: 

• A Virtual Private Network named 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).

• Inside the Virtual Network, there are 5 dedicated subnets for Virtual Machines, App Service Plans, App Service Environments, Private Endpoints, and Azure Bastion. 
• 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.
• There are also 3 Private DNS Zones for Blob, File Share and Key Vault, which can be used for DNS resolution using an Azure-provided DNS server. 
• A network-locked Storage Account and Key Vault are also deployed with private endpoints, which means they are not accessible from the public internet as shown below.

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.

Consumption Plan

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?

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.

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. 

Wrapping Up

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.

Some important points about the Function App deployed using a Consumption Plan can be listed as follows: 

• The Function App is accessible from the public internet and cannot access any private resources inside the Virtual Network. The issue to add this feature is still open, and Microsoft has no plan to provide this addition anytime soon. 
• This app cannot leverage the existing network architecture due to its deployment limitations. 

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.

Featured @ Deloitte’s Cloud & Engineering Articles: Link