Storage considerations for Azure Functions
Azure Functions requires an Azure Storage account when you create a function app instance. The following storage services may be used by your function app:
|Storage service||Functions usage|
|Azure Blob Storage||Maintain bindings state and function keys.
Also used by task hubs in Durable Functions.
|Azure Files||File share used to store and run your function app code in a Consumption Plan and Premium Plan.
Azure Files is set up by default, but you can create an app without Azure Files under certain conditions.
|Azure Queue Storage||Used by task hubs in Durable Functions and for failure and retry handling by specific Azure Functions triggers.|
|Azure Table Storage||Used by task hubs in Durable Functions.|
When using the Consumption/Premium hosting plan, your function code and binding configuration files are stored in Azure Files in the main storage account. When you delete the main storage account, this content is deleted and cannot be recovered.
Storage account requirements
When creating a function app, you must create or link to a general-purpose Azure Storage account that supports Blob, Queue, and Table storage. This requirement exists because Functions relies on Azure Storage for operations such as managing triggers and logging function executions. Some storage accounts don't support queues and tables. These accounts include blob-only storage accounts and Azure Premium Storage.
To learn more about storage account types, see Storage account overview.
While you can use an existing storage account with your function app, you must make sure that it meets these requirements. Storage accounts created as part of the function app create flow in the Azure portal are guaranteed to meet these storage account requirements. In the portal, unsupported accounts are filtered out when choosing an existing storage account while creating a function app. In this flow, you're only allowed to choose existing storage accounts in the same region as the function app you're creating. To learn more, see Storage account location.
Storage account guidance
Every function app requires a storage account to operate. When that account is deleted, your function app won't run. To troubleshoot storage-related issues, see How to troubleshoot storage-related issues. The following other considerations apply to the Storage account used by function apps.
Storage account location
For best performance, your function app should use a storage account in the same region, which reduces latency. The Azure portal enforces this best practice. If for some reason you need to use a storage account in a region different than your function app, you must create your function app outside of the portal.
Storage account connection setting
The storage account connection is maintained in the AzureWebJobsStorage application setting.
The storage account connection string must be updated when you regenerate storage keys. Read more about storage key management here.
Shared storage accounts
It's possible for multiple function apps to share the same storage account without any issues. For example, in Visual Studio you can develop multiple apps using the Azure Storage Emulator. In this case, the emulator acts like a single storage account. The same storage account used by your function app can also be used to store your application data. However, this approach isn't always a good idea in a production environment.
You may need to use separate store accounts to avoid host ID collisions.
Lifecycle management policy considerations
Functions uses Blob storage to persist important information, such as function access keys. When you apply a lifecycle management policy to your Blob Storage account, the policy may remove blobs needed by the Functions host. Because of this fact, you shouldn't apply such policies to the storage account used by Functions. If you do need to apply such a policy, remember to exclude containers used by Functions, which are prefixed with
Optimize storage performance
To maximize performance, use a separate storage account for each function app. This is particularly important when you have Durable Functions or Event Hub triggered functions, which both generate a high volume of storage transactions. When your application logic interacts with Azure Storage, either directly (using the Storage SDK) or through one of the storage bindings, you should use a dedicated storage account. For example, if you have an Event Hub-triggered function writing some data to blob storage, use two storage accounts—one for the function app and another for the blobs being stored by the function.
Storage data encryption
Azure Storage encrypts all data in a storage account at rest. For more information, see Azure Storage encryption for data at rest.
By default, data is encrypted with Microsoft-managed keys. For additional control over encryption keys, you can supply customer-managed keys to use for encryption of blob and file data. These keys must be present in Azure Key Vault for Functions to be able to access the storage account. To learn more, see Encryption at rest using customer-managed keys.
In-region data residency
When all customer data must remain within a single region, the storage account associated with the function app must be one with in-region redundancy. An in-region redundant storage account also must be used with Azure Durable Functions.
Other platform-managed customer data is only stored within the region when hosting in an internally load-balanced App Service Environment (ASE). To learn more, see ASE zone redundancy.
Host ID considerations
Functions uses a host ID value as a way to uniquely identify a particular function app in stored artifacts. By default, this ID is auto-generated from the name of the function app, truncated to the first 32 characters. This ID is then used when storing per-app correlation and tracking information in the linked storage account. When you have function apps with names longer than 32 characters and when the first 32 characters are identical, this truncation can result in duplicate host ID values. When two function apps with identical host IDs use the same storage account, you get a host ID collision because stored data can't be uniquely linked to the correct function app.
This same kind of host ID collison can occur between a function app in a production slot and the same function app in a staging slot, when both slots use the same storage account.
Starting with version 3.x of the Functions runtime, host ID collision is detected and a warning is logged. In version 4.x, an error is logged and the host is stopped, resulting in a hard failure. More details about host ID collision can be found in this issue.
Avoiding host ID collisions
You can use the following strategies to avoid host ID collisions:
- Use a separated storage account for each function app or slot involved in the collision.
- Rename one of your function apps to a value fewer than 32 characters in length, which changes the computed host ID for the app and removes the collision.
- Set an explicit host ID for one or more of the colliding apps. To learn more, see Host ID override.
Changing the storage account associated with an existing function app or changing the app's host ID can impact the behavior of existing functions. For example, a Blob Storage trigger tracks whether it's processed individual blobs by writing receipts under a specific host ID path in storage. When the host ID changes or you point to a new storage account, previously processed blobs may be reprocessed.
Override the host ID
You can explicitly set a specific host ID for your function app in the application settings by using the
AzureFunctionsWebHost__hostId setting. For more information, see AzureFunctionsWebHost__hostId.
When the collision occurs between slots, you may need to mark this setting as a slot setting. To learn how to create app settings, see Work with application settings.
Azure Arc-enabled clusters
When your function app is deployed to an Azure Arc-enabled Kubernetes cluster, a storage account may not be required by your function app. In this case, a storage account is only required by Functions when your function app uses a trigger that requires storage. The following table indicates which triggers may require a storage account and which don't.
|Not required||May require storage|
|• Azure Cosmos DB
• Service Bus
|• Azure SQL
• Blob storage
• Event Grid
• Event Hubs
• IoT Hub
• Queue storage
• Table storage
To create a function app on an Azure Arc-enabled Kubernetes cluster without storage, you must use the Azure CLI command az functionapp create. The version of the Azure CLI must include version 0.1.7 or a later version of the appservice-kube extension. Use the
az --version command to verify that the extension is installed and is the correct version.
Creating your function app resources using methods other than the Azure CLI requires an existing storage account. If you plan to use any triggers that require a storage account, you should create the account before you create the function app.
Create an app without Azure Files
Azure Files is set up by default for Premium and non-Linux Consumption plans to serve as a shared file system in high-scale scenarios. The file system is used by the platform for some features such as log streaming, but it primarily ensures consistency of the deployed function payload. When an app is deployed using an external package URL, the app content is served from a separate read-only file system. This means that you can create your function app without Azure Files. If you create your function app with Azure Files, a writeable file system is still provided. However, this file system may not be available for all function app instances.
When Azure Files isn't used, you must meet the following requirements:
- You must deploy from an external package URL.
- Your app can't rely on a shared writeable file system.
- The app can't use version 1.x of the Functions runtime.
- Log streaming experiences in clients such as the Azure portal default to file system logs. You should instead rely on Application Insights logs.
If the above are properly accounted for, you may create the app without Azure Files. Create the function app without specifying the
WEBSITE_CONTENTSHARE application settings. You can avoid these settings by generating an ARM template for a standard deployment, removing the two settings, and then deploying the template.
Because Functions use Azure Files during parts of the dynamic scale-out process, scaling could be limited when running without Azure Files on Consumption and Premium plans.
Mount file shares
This functionality is current only available when running on Linux.
You can mount existing Azure Files shares to your Linux function apps. By mounting a share to your Linux function app, you can use existing machine learning models or other data in your functions. You can use the following command to mount an existing share to your Linux function app.
In this command,
share-name is the name of the existing Azure Files share, and
custom-id can be any string that uniquely defines the share when mounted to the function app. Also,
mount-path is the path from which the share is accessed in your function app.
mount-path must be in the format
/dir-name, and it can't start with
For a complete example, see the scripts in Create a Python function app and mount a Azure Files share.
Currently, only a
AzureFiles is supported. You can only mount five shares to a given function app. Mounting a file share may increase the cold start time by at least 200-300 ms, or even more when the storage account is in a different region.
The mounted share is available to your function code at the
mount-path specified. For example, when
/path/to/mount, you can access the target directory by file system APIs, as in the following Python example:
import os ... files_in_share = os.listdir("/path/to/mount")
Learn more about Azure Functions hosting options.
Submit and view feedback for