Edit

Share via

Use customer-managed storage accounts in Azure Monitor Logs

Azure Monitor typically manages storage automatically, but some scenarios require you to configure a customer-managed storage account. This article describes the use cases, requirements, and procedures for setting up a customer-managed storage account link to a Log Analytics workspace.

Scenarios requiring customer-managed storage account
Private links used for custom/IIS log ingestion
Customer-managed key (CMK) data encryption of log alert queries and saved queries

Custom log content uploaded to customer-managed storage accounts might change in formatting or other unexpected ways. Carefully consider your dependencies on this content and understand the special circumstances for your use case.

Prerequisites

Warning

Starting June 30, 2025, creating or updating Custom logs and IIS logs linked storage accounts will no longer be available. Existing storage accounts will be unlinked by November 1, 2025. We strongly recommend migrating to an Azure Monitor Agent to avoid losing data. For more information, see Azure Monitor Agent overview.

Warning

Starting August 31, 2025, Log Analytics Workspaces must have a managed identity (MSI) assigned to them to add or update linked storage accounts for saved queries and saved log alert queries. For more information, see Link storage accounts to your Log Analytics workspace.

Action Permission required
Manage linked storage accounts for a workspace Microsoft.OperationalInsights/workspaces/write - workspace scope
For example, as provided by the built-in role, Log analytics Contributor.
Assign any managed identity to a workspace Microsoft.OperationalInsights/workspaces/write - workspace scope
For example, as provided by the built-in role, Log analytics Contributor.
Manage a user assigned managed identity for a workspace Microsoft.ManagedIdentity/userAssignedIdentities/assign/action - identity scope
For example, as provided by the built-in roles, Managed Identity Operator or Managed Identity Contributor.
Minimum permissions for managed identity on storage account Storage Table Data Contributor.

Additionally, the linked storage account must be in the same region as the workspace.

Customer-managed storage accounts are used to ingest custom logs when private links are used to connect to Azure Monitor resources. The ingestion process of these data types first uploads logs to an intermediary Azure Storage account, and only then ingests them to a workspace.

Workspace requirements

When you connect to Azure Monitor over a private link, Azure Monitor Agent can only send logs to workspaces accessible over a private link. This requirement means you should:

  • Configure an Azure Monitor Private Link Scope (AMPLS) object.
  • Connect it to your workspaces.
  • Connect the AMPLS to your network over a private link.

For more information on the AMPLS configuration procedure, see Use Azure Private Link to securely connect networks to Azure Monitor.

When you connect to Azure Monitor over a private link, the storage account must be accessible over a private link. This requirement means you should: For the storage account to connect to your private link, it must:

  • Be located on your virtual network or a peered network and connected to your virtual network over a private link.

  • Allow Azure Monitor to access the storage account. To allow only specific networks to access your storage account, select the exception Allow trusted Microsoft services to access this storage account.

    Screenshot that shows Storage account trust Microsoft services.

If your workspace handles traffic from other networks, configure the storage account to allow incoming traffic coming from the relevant networks/internet.

Coordinate the TLS version between the agents and the storage account. We recommend that you send data to Azure Monitor Logs by using TLS 1.2 or higher. If necessary, configure your agents to use TLS. If that's not possible, configure the storage account to accept TLS 1.2.

Customer-managed key data encryption

Azure Storage encrypts all data at rest in a storage account. By default, it uses Microsoft-managed keys (MMKs) to encrypt the data. However, Azure Storage also allows you to use customer-managed keys (CMKs) from Azure Key Vault to encrypt your storage data. Either import your own keys into Key Vault or use the Key Vault APIs to generate keys.

A customer-managed storage account is required for:

  • Encrypting log-alert queries with CMKs.
  • Encrypting saved queries with CMKs.

Configure your storage account to use CMKs with Key Vault. For more information, see Configure customer-managed keys for Azure Storage.

Considerations for customer-managed storage with CMK

The storage account and the key vault must be in the same region. They don't need to be from the same subscription though. For more information, see Azure Storage encryption for data at rest.

Special case Remediation
When a storage account is linked for queries, existing saved queries and functions in the workspace are deleted permanently for privacy and moved to a table in storage account. Copy existing saved queries before configuring the storage link. Here's an example using PowerShell. You can unlink the storage account for queries, to move saved queries and functions back to your workspace. Refresh the browser if you don't saved queries or functions don’t show up in the Azure Portal after the operation.
Queries saved in query packs aren't encrypted with CMK. Select Save as Legacy query when saving queries instead, to protect them with CMK.
Saved queries and log search alerts aren't encrypted in customer-managed storage by default. Encrypt your storage account with CMK at storage account creation even though CMK is configurable after.
A single StorageV2 storage account can be used for all purposes - queries, alerts, custom logs, and IIS logs. Linking storage for custom logs and IIS logs might require more storage accounts (up to 5 per workspace) for scale, depending on the ingestion rate and storage limits. Keep in mind all customer-managed storage for custom logs and IIS logs will be unlinked November 1, 2025.

The following requirements will be enforced no earlier than August 31, 2025.

Upcoming requirement Description
Managed identity assigned to the workspace Creating new links to customer-managed storage accounts when no managed identity is assigned will be blocked for all workspaces, including updating existing links.
Storage account configured with role assignment for managed identity Creating new links to customer-managed storage accounts when the storage account doesn't have a role assignment for the managed identity will be blocked for all workspaces, including updating existing links.

Create a managed identity

Get ready for the upcoming enforcement change by configuring your workspace with a managed identity.

Screenshot showing the workspace identity setting in the Azure portal.

Until that enforcement, the workspace doesn't use the managed identity for authentication to private storage. Don't remove your existing authentication method until the announcement is made that managed identities are enabled for authentication to private storage.

Create or update your workspace with a managed identity using one of these methods:

For more information, see What are managed identities for Azure resources?.

Add a role assignment

Once the managed identity is assigned to the workspace, update the storage account to allow access to the managed identity. Assign that identity the Storage Table Data Contributor role on the storage account to allow the workspace to access saved queries and log alert queries. Note the required permissions needed to assign managed identities and manage user assigned identities.

On the Azure portal, open your workspace menu and select Linked storage accounts. The linked storage account is shown for each type.

Screenshot that shows the Linked storage accounts pane.

Selecting a Type or the connection icon opens the storage account link details to set up or update the linked storage account for this type. Use the same storage account for multiple types to reduce complexity.

Manage linked storage accounts

Follow this guidance to manage your linked storage accounts.

When you link a storage account to a workspace, Azure Monitor Logs starts using it instead of the storage account owned by the service. You can:

  • Register multiple storage accounts to spread the load of logs between them.
  • Reuse the same storage account for multiple workspaces.

To stop using a storage account, unlink the storage from the workspace. When you unlink all storage accounts from a workspace, Azure Monitor Logs uses service-managed storage accounts. If your network has limited access to the internet, these storage accounts might not be available and any scenario that relies on storage will fail.

Replace a storage account

To replace a storage account used for ingestion:

  1. Create a link to a new storage account. The logging agents get the updated configuration and start sending data to the new storage. The process could take a few minutes.
  2. Unlink the old storage account so agents stop writing to the removed account. The ingestion process keeps reading data from this account until it's all ingested. Don't delete the storage account until you see that all logs were ingested.

Maintain storage accounts

Follow this guidance to maintain your storage accounts.

Manage log retention

When you use your own storage account, retention is up to you. Azure Monitor Logs doesn't delete logs stored on your private storage. Instead, you should set up a policy to handle the load according to your preferences.

Consider load

Storage accounts can handle a certain load of read and write requests before they start throttling requests. For more information, see Scalability and performance targets for Azure Blob Storage.

Throttling affects the time it takes to ingest logs. If your storage account is overloaded, register another storage account to spread the load between them. To monitor your storage account's capacity and performance, review its Insights in the Azure portal.

You're charged for storage accounts based on the volume of stored data, the type of storage, and the type of redundancy. For more information, see Block blob pricing and Azure Table Storage pricing.

Next steps