Azure Functions Flex Consumption generating continuous ListBlobs requests despite Event Grid-only triggers

Question

We are investigating a continuous and unexpectedly high volume of ListBlobs operations on an Azure Storage account used by an Azure Functions application running on Flex Consumption in Germany West Central.

The storage account receives approximately:

• 13,000–13,500 ListBlobs requests/hour
• approximately 320,000 requests/day
• requests continuously target a specific workplaces/ prefix
• authentication type: AccountKey
• user agent: azsdk-cpp-storage-blobs/12.14.0-beta.1
• source: a private Azure platform IP (10.x.x.x)

We enabled StorageRead diagnostics for a short controlled period and observed that essentially all these ListBlobs operations came from the same Azure-private caller and C++ SDK user agent.

Azure Functions configuration

The Function App is:

• Azure Functions Flex Consumption
• dotnet-isolated
• all application functions currently use Event Grid triggers
• there are zero deployed BlobTrigger functions
• the deployed package metadata confirms eventGridTrigger only
• Microsoft.Azure.WebJobs.Extensions.Storage.Blobs is not loaded by the Functions host

We sequentially migrated the relevant handlers from Blob-trigger behaviour to explicit Event Grid delivery and validated functional parity.

After migration, the continuous ListBlobs volume remained essentially unchanged.

The application worker itself uses the .NET Azure Storage SDK (Azure.Storage.Blobs 12.x), so the observed C++ user agent does not appear to originate from our application code.

Other causes investigated

We also checked the storage account for other potential sources of continuous scanning.

We found no active:

• Blob Inventory
• Lifecycle Management policy
• Object Replication
• Azure Data Protection / Blob Backup
• Defender for Storage scanning configuration that would explain this traffic

The storage account has versioning, change feed, soft delete and point-in-time restore enabled, but we have found no evidence that these features explain continuous full-prefix ListBlobs requests with this C++ SDK user agent.

The traffic also does not match the public outbound addresses of our Function App or Container Apps.

Timeline

The continuous scanner appeared shortly after the initial infrastructure provisioning of the Function App/storage environment and has remained active since then.

The current Function package contains no application BlobTrigger listener, but the scanner is still present.

Questions

Could Microsoft please clarify:

1. Which Azure-managed component uses the user agent azsdk-cpp-storage-blobs/12.14.0-beta.1 to perform repeated ListBlobs operations from Azure-private IP addresses?
2. Can the Flex Consumption scale controller, Event Grid integration, Functions host infrastructure or another Azure-managed component perform container/prefix scans even when all application functions are pure eventGridTrigger functions?
3. Is this expected behaviour, or could this indicate a platform issue?
4. Is there a supported configuration that prevents these continuous listings without affecting Event Grid delivery or Function scaling?

We can provide Microsoft Support privately with the exact storage account, Function App, timestamps, internal caller IP, diagnostic samples, deployment metadata and Azure Activity Log evidence if required.We are investigating a continuous and unexpectedly high volume of ListBlobs operations on an Azure Storage account used by an Azure Functions application running on Flex Consumption in Germany West Central.

The storage account receives approximately:

• 13,000–13,500 ListBlobs requests/hour
• approximately 320,000 requests/day
• requests continuously target a specific workplaces/ prefix
• authentication type: AccountKey
• user agent: azsdk-cpp-storage-blobs/12.14.0-beta.1
• source: a private Azure platform IP (10.x.x.x)

We enabled StorageRead diagnostics for a short controlled period and observed that essentially all these ListBlobs operations came from the same Azure-private caller and C++ SDK user agent.

Azure Functions configuration

The Function App is:

• Azure Functions Flex Consumption
• dotnet-isolated
• all application functions currently use Event Grid triggers
• there are zero deployed BlobTrigger functions
• the deployed package metadata confirms eventGridTrigger only
• Microsoft.Azure.WebJobs.Extensions.Storage.Blobs is not loaded by the Functions host

We sequentially migrated the relevant handlers from Blob-trigger behaviour to explicit Event Grid delivery and validated functional parity.

After migration, the continuous ListBlobs volume remained essentially unchanged.

The application worker itself uses the .NET Azure Storage SDK (Azure.Storage.Blobs 12.x), so the observed C++ user agent does not appear to originate from our application code.

Other causes investigated

We also checked the storage account for other potential sources of continuous scanning.

We found no active:

• Blob Inventory
• Lifecycle Management policy
• Object Replication
• Azure Data Protection / Blob Backup
• Defender for Storage scanning configuration that would explain this traffic

The storage account has versioning, change feed, soft delete and point-in-time restore enabled, but we have found no evidence that these features explain continuous full-prefix ListBlobs requests with this C++ SDK user agent.

The traffic also does not match the public outbound addresses of our Function App or Container Apps.

Timeline

The continuous scanner appeared shortly after the initial infrastructure provisioning of the Function App/storage environment and has remained active since then.

The current Function package contains no application BlobTrigger listener, but the scanner is still present.

Questions

Could Microsoft please clarify:

1. Which Azure-managed component uses the user agent
   azsdk-cpp-storage-blobs/12.14.0-beta.1
   to perform repeated ListBlobs operations from Azure-private IP addresses?
2. Can the Flex Consumption scale controller, Event Grid integration, Functions host infrastructure or another Azure-managed component perform container/prefix scans even when all application functions are pure eventGridTrigger functions?
3. Is this expected behaviour, or could this indicate a platform issue?
4. Is there a supported configuration that prevents these continuous listings without affecting Event Grid delivery or Function scaling?

We can provide Microsoft Support privately with the exact storage account, Function App, timestamps, internal caller IP, diagnostic samples, deployment metadata and Azure Activity Log evidence if required.