How to request big network bandwidth for gen2 blob storage

Question

How to request big network bandwidth for gen2 blob storage

Jianfei Wang 20 Microsoft Employee

currently, my single aml job to access gen2 blob can have 1GB/s speed, but sometimes its not stable, eg get 0.01GB/s speed and even failed.

P Kamala 0 Reputation points Microsoft Employee Moderator

2026-08-10T16:54:09.9766667+00:00
@Jianfei Wang Request to please check on below parameters:

1. Partition-Level Throttling (Most Likely Cause)

ADLS Gen2 has per-partition throughput limits — not just account-level limits. A single storage partition can serve up to ~60 MB/s for egress. If the AML job reads many files that happen to land on the same partition (files with similar path prefixes), it can hit partition-level throttling even though the account-level limit (~50 Gbps for Standard GPv2) is nowhere near saturated.

Symptoms: Intermittent 503 (Server Busy) or 500 errors, ServerBusy error codes, dramatic throughput drops.

Fix:

Distribute files across different path prefixes (e.g., hash-based directory structure instead of sequential).

Use multiple containers if workload is concentrated.

2. Client-Side Parallelism & SDK Configuration

Achieving stable 1 GB/s requires correct parallelism settings. The Azure Storage SDK defaults are conservative. If the AML job uses a single-threaded reader or low max_concurrency, throughput will be bottlenecked client-side.

Key settings to check:

max_concurrency on download_blob() — set to 16–64 for large reads.

max_single_get_size — default is 32 MB; increase to 256 MB for large blobs.

max_chunk_get_size — increase to 8–16 MB for parallel chunk downloads.

If using azcopy or Data Factory under the hood, verify block size and parallelism are tuned.

3. AML Compute Network Path

The network path between AML compute and the storage account is critical:

Same-region? Cross-region reads add latency and are subject to backbone congestion — this alone can explain instability.

Private Endpoint vs. public endpoint? Private Endpoints give more consistent throughput by avoiding public internet variability.

VNet integration? If AML compute is in a VNet with NSGs or UDRs, check for packet drops.

Managed VNet? AML managed VNets route through Microsoft backbone but can have variable latency.

4. Compute-Side Bottleneck

Check the AML compute SKU:

VM-level network bandwidth is capped by SKU. For example, a Standard_D8s_v3 has ~4 Gbps network bandwidth. Sustained 1 GB/s (= 8 Gbps) exceeds its NIC limit.

Use SKUs with Accelerated Networking and sufficient network bandwidth (e.g., Standard_E16s_v5 = 12.5 Gbps, or Standard_L8s_v3 for storage-optimized workloads).

Check if the VM is also doing GPU transfers, checkpoint writes, or other I/O that competes for bandwidth.

5. Storage Account Configuration

Account type: Standard GPv2 has lower per-blob limits than Premium BlockBlobStorage (which offers lower latency and higher per-partition throughput).

Redundancy: LRS > ZRS > GRS for throughput — GRS replication overhead can impact write-path performance.

Access tier: Files in Cool or Archive tier have a retrieval latency penalty — verify all files are in Hot tier.

Answer accepted by question author

Praveen Bandaru 11,720 Microsoft External Staff Moderator

Hello Jianfei Wang

Thank you for your patience while we looked into the Azure Storage scalability guidance.

According to the Microsoft Azure Storage scalability and performance targets documentation, the default storage account egress limit of 200 Gbps is available only in the specific regions listed there. UK South is included, but UK West is not listed. That means storage accounts in UK West are covered by the default maximum egress limit of 50 Gbps, or about 6.25 GB/s of aggregate throughput.

Based on the performance figures you shared, where approximately 10 AML jobs running in parallel achieve a combined throughput of around 6 GB/s, the observed throughput looks to be close to the documented 50 Gbps storage account egress target for regions that are not eligible for the 200 Gbps limit.

At this time, based on the published Microsoft documentation, UK West is not among the regions that support the default 200 Gbps storage account egress target.

For reference, please see the official Microsoft documentation:

If you would like, we can also review the storage account metrics further to see whether any additional throughput optimizations may be available for your workload.

Please check the below screen shot:

User's image

Check the below reference document:

https://learn.microsoft.com/en-us/azure/storage/common/scalability-targets-standard-account#scale-targets-for-standard-storage-accounts-and-disk-access-resources

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

0 comments

1 additional answer

Your answer

Answer 1

Hello Jianfei Wang,

Greetings! Thanks for raising this question in Q&A forum.

The most likely reason is that Azure Data Lake Storage Gen2/Blob Storage bandwidth is not something that can be manually increased for a single job on request. Large fluctuations in throughput are usually related to workload patterns, storage account limits, network conditions, partition distribution, or temporary service-side throttling.

Check the storage account metrics in Azure Monitor and review Ingress, Egress, SuccessE2ELatency, ServerLatency, and Throttling metrics during the periods when throughput drops.
Verify whether multiple AML jobs or other workloads are accessing the same storage account at the same time and consuming available throughput.
Confirm that the storage account type and redundancy option are appropriate for your performance requirements and that you are operating within documented scalability targets.
If the issue is intermittent and throughput drops from around 1 GB/s to 0.01 GB/s with failures, collect the correlation IDs, timestamps, storage account name, and AML job details.
Open a Microsoft Azure support ticket so the support team can review backend logs and validate whether service-side throttling, networking, or storage partitioning issues are involved.

The next action is with the customer and Azure Support. After you provide the affected timestamps and diagnostics, the support team can perform a backend investigation and confirm whether there are any service-side limitations or anomalies impacting throughput.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

How to request big network bandwidth for gen2 blob storage

1. Partition-Level Throttling (Most Likely Cause)

2. Client-Side Parallelism & SDK Configuration

3. AML Compute Network Path

4. Compute-Side Bottleneck

5. Storage Account Configuration

1 additional answer

Your answer