Share via

Flex Consumption plan - Service Bus trigger using virtual network integration | Azure Functions

Browse code

A common scenario that Azure Functions can be used for is for the processing of queue based events. For example, a list of batch processing jobs is queued up with instructions for machine learning processing. The function app can do some ML inferencing before completing the message in the queue.

This sample demonstrates a function app running in a Flex Consumption plan that connects to Service Bus running in a virtual network. This sample demonstrates these two key features of the Flex Consumption plan:

  • High scale. A low concurency of 1 is configured for the function app in the host.json file. Once messages are loaded into Service Bus and the app is started, you can see how it scales to one app instance per message simultaneously.
  • Virtual newtork integration. The Service Bus that this Flex Consumption app reads events from is secured behind a private endpoint. The function app can read events from it because it is configured with VNet integration. All connections to Service Bus and to the storage account associated with the Flex Consumption app also use managed identity connections instead of connection strings.

Diagram showing Service Bus with a private endpoint and an Azure Functions Flex Consumption app triggering from it via VNet integration

Important

This sample creates several resources. Make sure to delete the resource group after testing to minimize charges!

Prerequisites

Before you can run this sample, you must have the following:

Provision the solution on Azure

To set up this sample, follow these steps:

  1. Clone this repository to your local machine.
  2. Sign in to Azure Developer CLI with the following command:
azd auth login
  1. Sign in to either the Azure CLI or PowerShell (with Az module) to provide authentication for the hooks.

Azure CLI authentication in bash terminal:

az login

PowerShell authentication in PowerShell terminal:

Connect-AzAccount
  1. Move into the SB-VNET folder using the following command:
cd E2E/SB-VNET
  1. Use Azure Dev CLI to provision a new resource group with the environment name you provide and all the resources for the sample, then publish the code to the function app. It will also ask you for a password to be used for the Virtual Machine.
azd up

Inspect the solution (optional)

  1. Once the deployment is done, inspect the new resource group. The Flex Consumption function app and plan, storage, App Insights, Service Bus, and networking services have been created and configured: List of resources created by the bicep template
  2. The Service Bus namespace public network access has been turned off so nothing outside the VNet can access Service Bus. You can check this in the Service Bus Namespace's Networking tab and the Public access tab: Service Bus public network access turned off
  3. The Service Bus namespace has a private endpoint configured to one of the subnets in the VNet. This means it can only be accessed from inside the VNet. You can check this in the Service Bus Namespace's Networking tab and the Private Endpoint connections: Service Bus private endpoint
  4. An outbound virtual network integration has been created in your Function App into another subnet in the same VNet. This means it can access the Service Bus namespace. You can check this in the function app's Networking tab in the Outbound traffic configuration section: Function App Networking tab
  5. Open the Application Insights instance that was created by the Bicep deploy. Open the Live metrics tab to monitor for live events. Notice that it can't connect to the application, or shows only one 'server' online. This is expected, because the Flex Consupmtion app is scaled to down as there's no traffic or executions happening yet.
  6. Inspect the host.json file and notice that Service Bus' maxConcurrentCalls has been set to 1. This makes the per instance concurrency be 1 so your function will scale to multiple instances to handle messages put in the Service Bus queue.
  7. Inspect the function_app.py and notice there is a delay of 30 seconds in the code, to simulate that the each message would take 30 seconds to complete being processed.

Test the solution

  1. You can use the Service Bus Explorer in the Azure Portal to send messages to the Service Bus queue. You'll need to configure your client IP Address in the Service Bus firewall first: Service Bus networking page adding client IP address to firewall You can then follow Use Service Bus Explorer to run data operations on Service Bus to send messages and peek messages from the queue. Service Bus explorer showing messages in the queue
  2. Use the Service Bus Explorer in the portal or app to send 1,000 messages.
  3. Open Application Insights live metrics and notice the number of instances ('servers online'). Notice your app scaling the number of instances to handle processing the messages. Given there is a purpuseful 30 second delay in the app code you should see the messages being processed in 30 seconds intervals once the the app's maximum instance count (default of 100) is reached. The sample telemetry should also show that your messages are triggering the function, and making their way from Service Bus through the VNet into the function app for processing. Live metrics available

Clean up resources

When you no longer need the resources created in this sample, run the following command to delete the Azure resources:

azd down

Resources

For more information on Azure Functions, Service Bus, and VNet integration, see the following resources: