🚧 This is still under development! 🚧
This sample shows how to use Azure Functions with private endpoints for Azure Storage and CosmosDB. The use of private endpoints enables private (virtual network only) access to designated Azure resources.
One of the key scenarios in this sample is the use of Azure Storage private endpoints with the storage account required for use with Azure Functions. Azure Functions uses a storage account for metadata related to the runtime and various triggers, as well as application code. The storage account is referenced in the AzureWebJobsStorage application setting. The AzureWebJobsStorage account will be configured for access via private endpoints.
- Azure subscription. Get a free Azure account at https://azure.microsoft.com/free/.
- Azure CLI
- Azure Functions Core Tools
Execute the ARM template in the template directory. A script is provided to deploy the template.
The template will provision all the necessary Azure resources. The template will also create the application settings needed by the included Azure Function sample code. The function can optionally (disabled by default) publish the function.
The function can be published manually by using the Azure Functions Core Tools.
func azure functionapp publish <function-app-name>
This sample will demonstrate an Azure Function which retrieves files from an Azure Storage blob container, performs simple operations against the retrieved file data, and finally persists the data to an Azure CosmosDB collection. The function will communicate with the source Azure Storage account and the destination CosmosDB collection via private endpoints.
The Azure Function app provisioned in this sample uses an Azure Functions Premium plan. The Premium plan is used to enable virtual network integration. Virtual network integration is significant in this sample as the storage accounts used by the function app can only be accessed via private endpoints within the virtual network.
There are a few important details about the configuration of the function:
- Virtual network trigger support must be enabled in order for the function to trigger based on resources using a private endpoint
- In order to make calls to a resource using a private endpoint, it is necessary to integrate with Azure DNS Private Zones. Therefore, it is necessary to configure the app to use a specific Azure DNS server. This is accomplished by setting
WEBSITE_DNS_SERVER
to 168.63.129.16 andWEBSITE_VNET_ROUTE_ALL
to 1. - Enable the application content to be accessible over the virtual network. This is accomplished by setting
WEBSITE_CONTENTOVERVNET
to 1.
The function is configured to run from a deployment package. As such, the package is persisted in an Azure File share referenced by the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING application setting.
For more information on restricting an Azure storage account to a virtual network for use with Azure Functions, please refer to this official documentation.
There are three Azure Storage accounts used in this sample:
- a storage accounts which use a private endpoint for the Azure Functions runtime
- a storage account with a private endpoint, which is set up with a blob container (created by the ARM template). This is the storage account on which the function triggers (blob trigger).
- one storage account used by the VM for diagnostics
Azure CosmosDB is used to persist the data processed by the Azure Function. An Azure Function output binding is used for writing the data to the configured database and collection. The ARM template will create the CosmosDB database account and collection.
A private endpoint is created and configured for use with CosmosDB.
An Azure VM is created as a way to access the Azure resources from within the virtual network. The VM has no public IP address nor port access (e.g. RDP). Azure Bastion is used to connect to the VM.
The included ARM template configures the VM to shut down each evening at 7pm UTC. This is done as a cost-savings measure.
Azure resources in this sample either integrate with or are placed within a virtual network. The use of private endpoints keeps network traffic contained with the virtual network.
The sample uses four subnets:
- Subnet for Azure Function virtual network integration. This subnet is delegated to the function.
- Subnet for private endpoints. Private IP addresses are allocated from this subnet.
- Subnet for the virtual machine.
- Subnet for the Azure Bastion host.
Azure Private Endpoints are used to connect to specific Azure resources using a private IP address. This ensures that network traffic remains within the designated virtual network, and access is available only for specific resources. This sample configures private endpoints for the following Azure resources:
- CosmosDB
- Azure Storage
- Azure File storage
- Azure Blob storage
- Azure Queue storage
- Azure Table storage
Using a private endpoint to connect to Azure resources means connecting to a private IP address instead of the public endpoint. Existing Azure services are configured to use existing DNS to connect to the public endpoint. The DNS configuration will need to be overridden to connect to the private endpoint.
A private DNS zone will be created for each Azure resource configured with a private endpoint. A DNS A record is created for each private IP address associated with the private endpoint.
The following DNS zones are created in this sample:
- privatelink.queue.core.windows.net
- privatelink.blob.core.windows.net
- privatelink.table.core.windows.net
- privatelink.file.core.windows.net
- privatelink.documents.azure.com
Application Insights is used to monitor the Azure Function.