Data Lake Storage Gen2: High Bandwidth Usage — Investigation and Resolution Suggestions

For ADLS Gen2, high bandwidth utilisation without errors typically indicates significant read or write activity rather than a service failure. Since the increase started around a specific datea/time, I would investigate it using the following approach:

Correlate storage metrics with the spike

In Azure Monitor > Storage account > Metrics, review the following metrics around the time the increase began:

• Ingress
• Egress
• Transactions
• SuccessE2ELatency
• Used Capacity

Compare the affected period with previous hours and days to determine whether the increase was driven primarily by reads, writes, or a surge in transaction volume.

Analyse Storage diagnostic logs

If diagnostic logging is enabled, verify that StorageRead, StorageWrite, and StorageDelete logs are being sent to Log Analytics. You can use the StorageBlobLogs table to identify which operations, clients, or paths generated the most traffic.

For example:

StorageBlobLogs
| where TimeGenerated between (
    datetime(2026-07-15 20:00:00) ..
    datetime(2026-07-15 23:00:00)
)
| summarize
    Requests = count(),
    BytesSent = sum(ResponseBodySize),
    BytesReceived = sum(RequestBodySize)
    by OperationName, CallerIpAddress, Uri
| order by BytesSent desc

This can help determine whether bandwidth consumption is primarily caused by reads, writes, or specific clients accessing particular files or directories.

Correlate with consuming services

Review workloads that access the storage account during the same timeframe, such as:

• ADF pipelines
• Fabric workloads
• Databricks or Spark jobs
• Synapse workloads
• VMs
• Backup/replication processes
• Custom applications and scripts

Large data scans, repeated retries, full-table reads, or broad directory traversals can generate substantial bandwidth without producing storage errors.

Check for repeated or inefficient data access patterns

If specific files or folders account for most of the traffic, investigate whether workloads are:

• Re-reading the same data repeatedly
• Performing full dataset scans instead of incremental processing
• Using inefficient partitioning strategies
• Triggering unnecessary copy operations
• Bypassing caching mechanisms

These patterns can significantly increase bandwidth consumption even when all operations complete successfully.

Validate the network path

Determine whether the traffic remains within Azure or traverses regions, on-premises networks, or the public internet. Cross-region and external data transfers can result in higher egress volumes and may help explain unexpected bandwidth increases.

Configure proactive monitoring

To make future investigations easier:

• Create Azure Monitor alerts for Ingress and Egress thresholds.
• Retain Storage diagnostic logs in Log Analytics.
• Build Azure Monitor Workbooks that track bandwidth by:
  • Operation
  • Caller IP address
  • URI/path
  • Time

Key point

The absence of failures in transaction or diagnostic logs does not rule out excessive bandwidth usage. The most effective next step is to correlate the storage metrics with StorageBlobLogs and identify the combination of operation, URI/path, and caller IP address responsible for the largest volume of data transfer.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

i have done all primary investigation , but still the usage is going on

not yet solved, requested support person help

i dont get any ... support