Big download speed difference between Storage accounts despite same configuration

Question

Big download speed difference between Storage accounts despite same configuration

Jonathan Roy-Noel 20

Hello,

I have two different Storage accounts in which I store videos, one for development and one for production for example.

After I uploaded the same video file into both Storage accounts in their respective Blob container, I consistently observed much slower download speeds in my production Storage account. I have not compared upload speeds yet as they matter less for me at the moment.

Here are the results of my tests for a file of size 167 MB, using AzCopy:

Important thing to note: I purposely set AZCOPY_CONCURRENCY_VALUE=1 because I could not reproduce the issue with the default value of 300 (based on my CPUs). This tells me it could be related to some sort of per-connection bandwidth limit?

More importantly, the difference is very noticeable when generating a SAS url and playing the video from the browser. The download speed for the production version is actually too slow for realtime playback.

I want to make it clear that these Storage accounts have the exact same configuration (to the best of my knowledge):

Same location: canadacentral
Same subscription (and resource group)
Same performance tier: Standard
Same account kind: General purpose v2
Same replication: LRS
Same access tier: Hot

Let me know if you need more information.

Jonathan

Vallepu Venkateswarlu 5,960 Reputation points Microsoft External Staff Moderator

2026-02-26T18:55:38.81+00:00
Hi @ Jonathan Roy-Noel,

Welcome to Microsoft Q&A Platform.

Run the same AzCopy download from a completely different machine or network. If production is still slow, stop blaming your laptop — the issue is upstream (storage config, region, networking, or throttling).

Then check the storage account metrics in Azure Portal under Storage Account → Insights → Performance → Latency of successful calls by API name. Look at average and P95 latency for GetBlob and compare prod vs non-prod. If prod latency is higher there, the storage service itself is responding slower.

Also verify networking configuration on both accounts. Go to Storage Account → Networking and confirm whether they’re using Public access or Private endpoints. If one account is private and the other is public, that alone can explain the difference.

Private endpoints introduce routing and DNS dependencies ,especially if traffic is hair-pinning through a firewall or crossing regions.

From the same machine where you’re running AzCopy, resolve both storage account FQDNs:

nslookup scenariste360.blob.core.windows.net nslookup scenariste360production.blob.core.windows.net

Compare the IPs. If one resolves to a private IP (10.x, 172.x, 192.168.x) and the other resolves to a public Microsoft IP, you’re not taking the same network path.

If prod remains slower across machines and shows higher API latency, the next suspects are: different region, different redundancy tier (LRS vs GRS/RA-GRS), different performance tier, firewall inspection, or cross-region traffic.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Jonathan Roy-Noel 20 Reputation points

2026-02-26T21:17:16.78+00:00
Hello Vallepu,

Here's what I found by comparing the Insights latency in the time range just after my previous tests (around 18:07 UTC).

Success E2E Latency (max) Success E2E Latency (avg)

Development 7.35sec 102.97ms

Production 47.66sec 3.18sec

To answer your other points:

Both are using Public access. Although nslookup gives different addresses, both are in the range 20.209.XX.XX which is not private.

Region, redundancy tier and performance tier are the same.

But just by looking at the data overall, there's a clear indication that something is wrong with the Production instance. I guess my next step would be to create a new Storage Account to see how that one behaves.
Vallepu Venkateswarlu 5,960 Reputation points Microsoft External Staff Moderator

2026-02-27T20:48:18.1133333+00:00
Hi @ Jonathan Roy-Noel,

Based on the Azure Storage Insights metrics, the elevated latency observed in Production suggests the delay may be occurring within the Azure Storage request path rather than the client network layer.

As per Azure documentation: Latency metrics for block blobs

Success E2E Latency reflects total request duration.

Success Server Latency reflects processing time inside the Azure Storage service.

If Production shows:

Server Latency ≈ 3 seconds

Development shows Server Latency ≈ 100 ms

This indicates that the delay is occurring within the storage service processing layer rather than external networking.

Compare Transaction Metrics:

To identify whether the latency difference is workload-related or service-specific, compare transaction volume between the two storage accounts.

Azure Portal → Storage Account---->Select Insights---->Open Transactions tab--->Set identical Time Range (UTC) for both accounts.

Compare the following metrics:

Total Requests

Success Requests

Failed Requests

Throttling Errors (503 / ServerBusy)

Transactions by API name (e.g., GetBlob)

Apply filters:

API Name = GetBlob

Response Type = Success

Option 2: Using Azure Monitor Metrics

Go to Storage Account → Metrics---->Metric Namespace: Blob--->Add metric: Transactions--->Aggregation: Sum

Apply filters:

API Name = GetBlob

Response Type = Success

Repeat for both Development and Production.

Azure Monitor provides full visibility into request volume and latency metrics. Comparing transaction counts and Server Latency between Development and Production during the same time window is the correct approach to determine whether the latency difference is:

Workload-driven

Partition-related

Throttling-related

Or indicative of a storage account-specific performance condition

I hope this information helps resolve your issue. Please feel free to ask if the provided solution does not help or if you have any additional questions.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Jonathan Roy-Noel 20 Reputation points

2026-03-02T15:10:17.9366667+00:00
Hello,

I think I found out where the issue comes from, but I don't think I can do much on my end to resolve this.

I ended up creating a new Storage Account. To my surprise, the high latency and slow speeds were the exact same as the production account. I then decided to check the addresses with nslookup again. My new Storage Account was on the same instance as the production one:

Name: blob.yto26prdstr03a.store.core.windows.net Address: 20.209.168.96 Aliases: scenariste360production.blob.core.windows.net Name: blob.yto26prdstr03a.store.core.windows.net Address: 20.209.168.96 Aliases: scenariste360prodv2.blob.core.windows.net

Comparing with development gives me a different IP address and name:

Name: blob.yto23prdstr06a.store.core.windows.net Address: 20.209.70.193 Aliases: scenariste360.blob.core.windows.net

To confirm this, I created another Storage Account, but this time in the US East 2 region. Although latency was higher (to be expected), download speeds were very similar if not identical to development.

Here are some screenshots from Insights. All are from some tests I did about an hour ago:

Development (scenariste360.blob.core.windows.net)

New prod (scenariste360prodv2)

US East 2 region (scenariste360useast2)

In conclusion, I believe the instance yto26prdstr03a (20.209.168.96) is the source of the issues I'm currently having. It would be great if you could confirm this on your end.

Thanks, Jonathan

Answer accepted by question author

0 additional answers

Your answer

Vallepu Venkateswarlu 5,960 Reputation points Microsoft External Staff Moderator

2026-02-26T18:55:38.81+00:00

Hi @ Jonathan Roy-Noel,

Welcome to Microsoft Q&A Platform.

Run the same AzCopy download from a completely different machine or network. If production is still slow, stop blaming your laptop — the issue is upstream (storage config, region, networking, or throttling).

Then check the storage account metrics in Azure Portal under Storage Account → Insights → Performance → Latency of successful calls by API name. Look at average and P95 latency for GetBlob and compare prod vs non-prod. If prod latency is higher there, the storage service itself is responding slower.

Also verify networking configuration on both accounts. Go to Storage Account → Networking and confirm whether they’re using Public access or Private endpoints. If one account is private and the other is public, that alone can explain the difference.

Private endpoints introduce routing and DNS dependencies ,especially if traffic is hair-pinning through a firewall or crossing regions.

From the same machine where you’re running AzCopy, resolve both storage account FQDNs:

nslookup scenariste360.blob.core.windows.net nslookup scenariste360production.blob.core.windows.net

Compare the IPs. If one resolves to a private IP (10.x, 172.x, 192.168.x) and the other resolves to a public Microsoft IP, you’re not taking the same network path.

If prod remains slower across machines and shows higher API latency, the next suspects are: different region, different redundancy tier (LRS vs GRS/RA-GRS), different performance tier, firewall inspection, or cross-region traffic.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Jonathan Roy-Noel 20 Reputation points

2026-02-26T21:17:16.78+00:00

Hello Vallepu,

Here's what I found by comparing the Insights latency in the time range just after my previous tests (around 18:07 UTC).

Success E2E Latency (max) Success E2E Latency (avg)

Development 7.35sec 102.97ms

Production 47.66sec 3.18sec

To answer your other points:

Both are using Public access. Although nslookup gives different addresses, both are in the range 20.209.XX.XX which is not private.

Region, redundancy tier and performance tier are the same.

But just by looking at the data overall, there's a clear indication that something is wrong with the Production instance. I guess my next step would be to create a new Storage Account to see how that one behaves.
Jonathan Roy-Noel 20 Reputation points

2026-03-02T15:10:17.9366667+00:00

Hello,

I think I found out where the issue comes from, but I don't think I can do much on my end to resolve this.

I ended up creating a new Storage Account. To my surprise, the high latency and slow speeds were the exact same as the production account. I then decided to check the addresses with nslookup again. My new Storage Account was on the same instance as the production one:

Name: blob.yto26prdstr03a.store.core.windows.net Address: 20.209.168.96 Aliases: scenariste360production.blob.core.windows.net Name: blob.yto26prdstr03a.store.core.windows.net Address: 20.209.168.96 Aliases: scenariste360prodv2.blob.core.windows.net

Comparing with development gives me a different IP address and name:

Name: blob.yto23prdstr06a.store.core.windows.net Address: 20.209.70.193 Aliases: scenariste360.blob.core.windows.net

To confirm this, I created another Storage Account, but this time in the US East 2 region. Although latency was higher (to be expected), download speeds were very similar if not identical to development.

Here are some screenshots from Insights. All are from some tests I did about an hour ago:

Development (scenariste360.blob.core.windows.net)

New prod (scenariste360prodv2)

US East 2 region (scenariste360useast2)

In conclusion, I believe the instance yto26prdstr03a (20.209.168.96) is the source of the issues I'm currently having. It would be great if you could confirm this on your end.

Thanks, Jonathan

Answer 1

Hello Jonathan Roy-Noel

When you perform any operation from machine to server, so main factors which play role in terms of process is:

Server Processing Time => Network Time to reach to client => Client machine processing time

Please find below information on latency.

E2ELatency (duration): The total time in milliseconds taken to complete a request in the Windows Azure Storage Service. This value includes the required processing time within Windows Azure Storage to read the request, send the response, and receive acknowledgement of the response.

Server Latency (duration): The total processing time in milliseconds taken by the Windows Azure Storage Service to process a request. This value does not include the network latency specified in E2E Latency.

A high E2E latency points to either a client-side performance issue and/or network latency. To analyze this further, you could check on the below parameters at the client side.

High CPU on the client.
Low available memory on the client.
Running out of network bandwidth on the client.
Misconfigured client application.

Latency in Blob storage - Azure Storage | Microsoft Learn

You can also check this metric in Azure Portal which provides you a picture of Success Server Latency and Success E2E latency.

Monitor and troubleshoot Azure Storage (classic logs & metrics) - Azure | Microsoft Learn

You can compare both Success E2E latency (Avg) and Success Server latency (Avg); both lines should be similar to pass. If they are not matching, check whether E2E latency or Server latency is higher. Please refer to the screenshot below for guidance on how to analyze.

User's image

Please find below the reference article which pointed at isolation of the latency issue from the storage end.

How to isolate latency issue for Azure Storage Account | Microsoft Community Hub

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.

	Success E2E Latency (max)	Success E2E Latency (avg)
Development	7.35sec	102.97ms
Production	47.66sec	3.18sec

Share via

Big download speed difference between Storage accounts despite same configuration

0 additional answers

Your answer