Edit

Configure connections to remote services in Azure Functions

This article is the primary reference for how Azure Functions connects to remote services. It provides specific guidance based on connection type and authentication method.

Important

Use managed identities with Microsoft Entra ID whenever possible. This authentication method eliminates secrets and provides the highest security.

Connection categories

Azure Functions connections fall into these basic categories:

  • Host required: Connections the Functions host needs to operate, such as storage and monitoring.
  • Bindings: Connections that the host manages for your triggers and bindings.
  • Client SDK: Connections you create and manage in your own function code.

Tip

Functions also supports managed connectors (in preview), which let you connect to services like Office 365, Teams, and SharePoint with built-in OAuth and webhook handling through a Connector Namespace. For more information, see Use connectors in Azure Functions.

The Functions host requires your app to have these specific named connections, which support both function executions and logging:

Authentication methods

Important

When possible, use managed identities for your connections. This approach eliminates secrets entirely. When the target service doesn't support Microsoft Entra ID authentication, use Azure Key Vault to centrally manage secrets. Only use shared secrets directly in app settings as a last resort.

Functions supports these authentication methods when connecting to remote services:

Authentication method Security When to use
Managed identities Highest Target service supports Microsoft Entra ID. No secrets to manage.
Azure Key Vault High Service doesn't support managed identities, or you need centralized secret management with rotation.
Shared secret Low Legacy default. Migrate to managed identities or Key Vault as soon as possible.

Choose your preferred authentication method at the top of the article to see detailed configuration guidance.

Define connections

At runtime, your function app accesses connection information as environment variables from these locations:

Environment Where settings are stored
Azure Application settings (encrypted at rest)
Local development local.settings.json (optionally encrypted)

In both environments, settings are exposed to your code as environment variables. The specific settings you need depend on both the connection type and the authentication method you choose.

When you use Microsoft Entra authentication to connect to an Azure service, the specific app settings you use depend on the connected service and whether you're using a system-assigned or user-assigned identity to authenticate the connection.

The identities that you use for your connections must have permissions to perform the intended actions. For most Azure services, this requirement means you need to assign a role in Azure RBAC, using either built-in or custom roles that provide those permissions. To learn more, see Grant permissions to an identity.

For a tutorial on configuring your function apps with managed identities, see the creating a function app with identity-based connections tutorial.

Keep these considerations in mind when using identity-based connections:

  • In a Functions-hosted app, identity-based connections use a managed identity. The system-assigned identity, which is specific to to your app, is used by default. However, user-assigned identities, which also require the *__credential and *__clientID properties, are more flexible and recommended.

  • When your app runs in other contexts, such as local development, your developer identity is used instead. For more information, see the local development article.

  • Identity-based connections are only supported on version 4.x and later of the Functions runtime. If you're running a legacy C# app on version 1.x of the Functions runtime, you must first migrate to version 4.x.

You can configure your function app to use an identity instead of a connection string when connecting to the default storage account (AzureWebJobsStorage) and other host-required connections.

Managed identity support for AzureWebJobsStorage varies by hosting plan:

Hosting plan MI for host storage Azure Files requirement Recommendation
Flex Consumption Full support None (no Azure Files) Recommended for MI
Dedicated (App Service) Full support None (no dynamic scaling) Full MI, no workaround needed
Consumption Blobs, queues, tables Key Vault or remove Azure Files Store WEBSITE_AZUREFILESCONNECTIONSTRING in Key Vault
Elastic Premium Blobs, queues, tables Key Vault or remove Azure Files Store WEBSITE_AZUREFILESCONNECTIONSTRING in Key Vault

Before using managed identities for host-required connections, consider these limitations:

  • For Consumption and Premium plans, implement one of these workarounds for Azure Files:

    • Store only the WEBSITE_AZUREFILESCONNECTIONSTRING connection string in Key Vault, which is the next most secure option.
    • Create a Consumption or Premium plan app that runs without Azure Files. There are performance impacts when running without Azure Files. For more information, see Create an app without Azure Files.

  • These triggers rely on AzureWebJobsStorage to run correctly:

    • Azure Blob Storage
    • Azure Event Hubs
    • Durable Functions (by default)
    • Timer

    If your app uses any of these extensions, make sure its version also supports managed identities.

  • AzureWebJobsStorage maintains deployment artifacts in server-side (remote) builds in a Linux Consumption plan. In this scenario, you must deploy and run your app from an external deployment package.

  • Other components of your function app might reuse the AzureWebJobsStorage connection, which could include storage binding extensions or storage clients created using the Azure SDK. When using managed identities, create new application settings for these nonhost components, even when they support managed identities.

These specific app settings define identity-based connections to both AzureWebJobsStorage and APPLICATIONINSIGHTS_CONNECTION_STRING:

Setting Description
AzureWebJobsStorage__blobServiceUri The URI for Blob Storage in the default storage account. Required for sovereign clouds or a custom storage DNS, such as: https://mystorageaccount.blob.contoso.com. HTTPS is required.
AzureWebJobsStorage__queueServiceUri The URI for Queue Storage in the default storage account. Required for sovereign clouds or a custom storage DNS, such as: https://mystorageaccount.queue.contoso.com. HTTPS is required.
AzureWebJobsStorage__tableServiceUri The URI for Table Storage in the default storage account. Required for sovereign clouds or a custom storage DNS, such as: https://mystorageaccount.table.contoso.com. HTTPS is required.
AzureWebJobsStorage__credential Set to managedidentity to use managed identity authentication. A managed identity must be available in the hosting environment.
AzureWebJobsStorage__clientId or
AzureWebJobsStorage__managedIdentityResourceId		 Returns a specific user-assigned identity used to obtain an access token for managed identity authentication. When neither is set, the system-assigned identity of the application is used.
APPLICATIONINSIGHTS_AUTHENTICATION_STRING Enables connections to Application Insights using Microsoft Entra authentication. Set to either Authorization=AAD (system-assigned) or ClientId=<YOUR_CLIENT_ID>;Authorization=AAD (user-assigned).

Because the double-underscore value (__) is interpreted at runtime as a colon (:), the series of settings are interpreted as properties of the AzureWebJobsStorage object. For example, consider these AzureWebJobsStorage connection settings:

  • AzureWebJobsStorage__blobServiceUri=https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net
  • AzureWebJobsStorage__queueServiceUri=https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net
  • AzureWebJobsStorage__tableServiceUri=https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net
  • AzureWebJobsStorage__credential=managedidentity
  • AzureWebJobsStorage__clientId=<MY_USER_ASSIGNED_IDENTITY_ID>

At runtime, the host interprets these settings as a complex AzureWebJobsStorage setting.

"AzureWebJobsStorage":
{
    "blobServiceUri": "https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net",
    "queueServiceUri": "https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net",
    "tableServiceUri": "https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net",
    "credential": "managedidentity",
    "clientId": "<MY_USER_ASSIGNED_IDENTITY_ID>"
}

You must also grant permissions for the identity in the default storage account so that the host can connect with sufficient permissions to perform the required tasks. To learn how, see Grant permissions to an identity.

Grant permissions to an identity

When you use managed identities with Microsoft Entra ID authentication, you must specifically assign permissions to the identity your app uses when making connections to the remote service. The easiest way to grant least-privilege permissions to your app is by assigning built-in roles.

Keep these recommendations in mind when granting RBAC permissions to your app's identities:

  • Whenever possible, adhere to the principle of least privilege by granting the identity only the minimum required privileges. For example, if the app only needs to read from a data source, use a role that only has permission to read and not to write data.
  • Don't use broad built-in roles like Owner, even just to get the app to work.
  • After you create or modify a role assignment, it can take up to 10 minutes for the change to propagate. During this time, your function might receive authorization errors (403) even though the role is correctly assigned. If you encounter errors immediately after creating a role assignment, wait a few minutes and retry.
  • When multiple connections require permissions to the same service, use the role that is the minimum subset of permissions for all connections to that service.
  • Several bindings require broader permissions in your storage account than what is required by the AzureWebJobsStorage connection.
  • To access keys in Key Vault by using managed identities, assign your app to the Key Vault Secrets User role. You can also use a Key Vault access policy to assign the Get secrets permission to the managed identity. For more information, see grant an identity in your app access to your key vault.
  • This article refers only to built-in roles that provide minimum permissions. Depending on your app requirements, you might instead need to create your own custom roles.

The permissions you need depend on the kind of connection:

  • AzureWebJobsStorage: The Storage Blob Data Owner role provides the minimum storage account permissions for the host-required AzureWebJobsStorage connection. This role gives the level of storage access that the Functions host needs while following the principle of least privilege.

    For some types of problems, Functions can raise diagnostic events to help you troubleshoot, even when your app can't start. You must also add the Storage Table Data Contributor role, which provides access to Table Storage where those diagnostic events are persisted. Without these extra permissions, you might see warnings in your logs about the inability to write these events.

    Several other bindings might require you to use a slightly broader role. The Host-required storage column of the table in the Bindings tab lists these role requirements.

  • APPLICATIONINSIGHTS_AUTHENTICATION_STRING: The Monitoring Metrics Publisher role grants the minimum permissions the host needs to connect to Application Insights for logging.

Note

When using APPLICATIONINSIGHTS_AUTHENTICATION_STRING to connect to Application Insights using Microsoft Entra authentication, you should also Disable local authentication for Application Insights. This configuration requires Microsoft Entra authentication in order for telemetry to be ingested into your workspace.

Note

Use Key Vault only for connections that don't currently support Microsoft Entra ID with Azure managed identities.

Because some services don't yet support Microsoft Entra authentication, your app might still require secrets in certain cases. For these cases, Azure Key Vault can help streamline the management lifecycle for secrets-based authentication. Your app can use Key Vault to more securely store and access shared secrets, including the default storage account connection string. Although connections still use shared secrets, Key Vault provides a higher level of security for your secrets, including key maintenance and rotation. Your app can connect to Key Vault by using managed identities, even when the service itself doesn't yet support managed identity-based connections.

When you use Key Vault, create your application setting for the connection by using a Key Vault reference instead of the actual secret. For more information, see Source app settings from key vault.

Keep these considerations in mind when maintaining connections in Key Vault:

  • To access keys in the vault, you must grant an identity in your app access to your key vault.

  • You can use Key Vault to store settings for your managed identity-based connections. When your app uses Key Vault, references must use a key separator of : or /, such as Storage1:blobServiceUri. When you use the regular application setting delimiter of __, reference names don't resolve correctly.

For a complete end-to-end example, see the Tutorial: Create a function app that connects to Azure services using identities instead of secrets.

You can configure the AzureWebJobsStorage setting to return a Key Vault reference that contains the connection string instead of returning the connection string itself. To learn how, see Use Key Vault references as app settings.

Azure Files doesn't currently support managed identity connections. Because of this limitation, use Key Vault to secure the WEBSITE_AZUREFILESCONNECTIONSTRING setting, which is required for dynamic scaling by both Consumption and Premium plans. The Flex Consumption plan is also a dynamic plan that doesn't use Azure Files and fully supports managed identity connections.

Caution

Avoid working directly with shared secrets. Whenever possible, use a more secure method of authentication for your connections.

Mitigate the potential downside risks of lost or compromised secrets by using managed identities with Microsoft Entra ID authentication. When the remote service doesn't support managed identities, at least use Azure Key Vault, which more securely maintains shared secrets.

If for some reason you can't use a more secure authentication method, the platform encrypts data in your application settings while at rest. Migrate your apps away from using shared secrets to a more secure authentication method as soon as possible.

Set the connection string for the default storage account in the AzureWebJobsStorage setting. This setting is the default connection behavior when you create your function app.

Manage SDK client connections

When you create your own client SDK connections in function code, always reuse client instances across invocations rather than creating new ones. This best practice on all hosting plans reduces latency, avoids socket exhaustion, and improves resource efficiency.

Reuse client instances

Follow these guidelines when using a service-specific client in an Azure Functions application:

  • Don't create a new client with every function invocation.
  • Do create a single, shared client that every function invocation can reuse.
  • Consider creating a single, shared client in a helper class if different functions use the same service.

The recommended approach depends on your language:

Use dependency injection to register singleton or scoped clients.

See Client code examples for complete patterns in each language.

Connection limits in a Consumption plan

Note

The hard connection limits described in this section apply only to the legacy Consumption plan. The Flex Consumption plan doesn't run in the same sandbox environment and doesn't impose these limits. However, reusing clients is still recommended on all plans for optimal performance.

In the legacy Consumption plan, function apps run in a sandbox environment that limits the number of outbound connections to 600 active (1,200 total) per instance. When you reach this limit, the Functions host writes the following message to the logs: Host thresholds exceeded: Connections. For more information, see the Functions service limits.

This limit is per instance. When the scale controller adds function app instances to handle more requests, each instance has an independent connection limit. That means there's no global connection limit, and you can have more than 600 active connections across all active instances.

When troubleshooting connection issues, make sure that Application Insights is enabled for your function app. Application Insights lets you view metrics for your function apps like executions. For more information, see View telemetry in Application Insights.

Client code examples

This section demonstrates best practices for creating and using clients from your function code.

HTTP requests

Register a shared HttpClient by using dependency injection so that all function invocations reuse the same instance. In this case, you don't have to dispose of the client because the runtime manages its lifetime.

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]

namespace MyNamespace;

public class Startup : FunctionsStartup
{
    public override void Configure(IFunctionsHostBuilder builder)
    {
        builder.Services.AddHttpClient();
    }
}

Then inject IHttpClientFactory or HttpClient in your function class:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace MyNamespace;

public class MyFunction(HttpClient httpClient, ILogger<MyFunction> logger)
{
    [Function("MyFunction")]
    public async Task Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer)
    {
        var response = await httpClient.GetAsync("https://example.com");
        logger.LogInformation("Response status: {Status}", response.StatusCode);
    }
}

Azure Cosmos DB clients

Register a singleton CosmosClient in your startup so that all functions share one connection. The Azure Cosmos DB documentation recommends that you use a singleton client for the lifetime of your application.

using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]

namespace MyNamespace;

public class Startup : FunctionsStartup
{
    public override void Configure(IFunctionsHostBuilder builder)
    {
        builder.Services.AddSingleton(_ =>
        {
            var connectionString = Environment.GetEnvironmentVariable("CosmosDBConnection");
            return new CosmosClient(connectionString);
        });
    }
}

Then inject CosmosClient in your function class:

using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace MyNamespace;

public class MyCosmosFunction(CosmosClient cosmosClient, ILogger<MyCosmosFunction> logger)
{
    private readonly Container _container = cosmosClient.GetContainer("mydb", "mycontainer");

    [Function("MyCosmosFunction")]
    public async Task Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer)
    {
        var item = new { id = "myId", partitionKey = "myPartitionKey", data = "example" };
        await _container.UpsertItemAsync(item, new PartitionKey("myPartitionKey"));
        logger.LogInformation("Item upserted");
    }
}

SqlClient connections

Your function code can use the .NET Framework Data Provider for SQL Server (SqlClient) to make connections to a SQL relational database. This provider is also the underlying provider for data frameworks that rely on ADO.NET, such as Entity Framework. Unlike HttpClient and DocumentClient connections, ADO.NET implements connection pooling by default. But because you can still run out of connections, you should optimize connections to the database. For more information, see SQL Server Connection Pooling (ADO.NET).

Tip

Some data frameworks, such as Entity Framework, typically get connection strings from the ConnectionStrings section of a configuration file. In this case, you must explicitly add SQL database connection strings to the Connection strings collection of your function app settings and in the local.settings.json file in your local project. If you're creating an instance of SqlConnection in your function code, store the connection string value in Application settings with your other connections.

Azure App Configuration

Azure App Configuration is an Azure service that you can use to centrally manage application settings. App Configuration supports hierarchical key-value pairs and versioning, and it integrates with Azure Key Vault for more secure secret management. For more information, see What is Azure App Configuration?

For improved security, your function app uses managed identities with Microsoft Entra authentication to access settings in an Application Store. For more information, see Use App Configuration references for Azure Functions.

Note

When using Azure App Configuration to store settings for managed identity-based connections, references must use a key separator of : or / in the format <CONNECTION_NAME_PREFIX>:fullyQualifiedNamespace. When you use the regular application setting delimiter of __, reference names don't resolve correctly.

Related content

  • Last updated on