Using AzCopy to copy blobs between storage accounts with network restrictions

Question

Using AzCopy to copy blobs between storage accounts with network restrictions

Nassim Cherifi 55

We followed the recommendations outlined in this document by implementing Workaround 1.

Before implementing Workaround 1, we had two private endpoints in two different VNets, and Workaround 4 was working perfectly in this setup. However, this approach is not scalable. Therefore, we followed the recommendations of Workaround 1 by moving one of the private endpoints.

However, I don’t fully understand technically how Workaround 1 works. Could you please explain? I assume that the traffic is not initiated by the private endpoint itself, as this would be technically impossible.

Regards,

Nassim Cherifi 55 Reputation points

2025-12-18T10:08:06.91+00:00

Hello Venkatesan,First thanks for your time and your answer.

In my case, public access is disabled on both the source and destination storage accounts. I want to understand why the Get Blob from the source and the Put Block to the destination fail when the two private endpoints are not in the same subnet.

I'm testing with a VM outside of Azure, it's behind the ER.

The network side (firewall and routing) is OK, since workaround 4 works for me.

Regards,

Answer accepted by question author

1 additional answer

Your answer

Nassim Cherifi 55 Reputation points

2025-12-18T10:08:06.91+00:00

Hello Venkatesan,First thanks for your time and your answer.

In my case, public access is disabled on both the source and destination storage accounts. I want to understand why the Get Blob from the source and the Put Block to the destination fail when the two private endpoints are not in the same subnet.

I'm testing with a VM outside of Azure, it's behind the ER.

The network side (firewall and routing) is OK, since workaround 4 works for me.

Regards,

Answer 1

Hi Nassim Cherifi,

Thanks for posting question in Microsoft Q&A,

Workaround 1:

Workaround 1 creates a private endpoint for the destination storage account directly in the source VNet (Spoke A), resolving the 403 "CannotVerifyCopySource" error in hub-spoke topologies. This allows the VM in the Hub VNet to successfully trigger server-side copies via AzCopy.
Diagram that shows the process of copying blobs between storage accounts in Workaround 1.

AzCopy issues a Put Block From URL request to the destination storage service, providing the source blob URL. The destination service attempts to fetch blocks directly from the source storage over Azure's internal backbone (server-side copy, no client bandwidth used).

If the source firewall rejects this (due to private endpoints and no direct trust), the destination falls back to proxy mode: it requests the client (VM) perform Get Blob from source and Put Block to destination. Your assumption is correct traffic isn't "initiated by the private endpoint"; the destination storage service starts the source fetch internally.

Why It Succeeds Post-Workaround

VM (Hub) accesses source via existing Spoke A private endpoint (VNet peering enables reachability).
VM accesses destination via new private endpoint in same Spoke A VNet.
Proxy fallback authenticates via VM's permissions; no source firewall block on destination service since client-proxied path bypasses direct service-to-service check.

This scales better than Workaround 4 (VM download/upload) by preferring efficient server-side copy.

Yes, your assumption is correct. Private endpoints do not initiate traffic themselves; they serve as network interfaces that map private IP addresses within the VNet to the storage service, enabling inbound connections from authorized clients or services in that VNet.

Update:

The Problem (Different VNets)

VM → Source (VNet A) > Works
VM → Destination (VNet B)  ? Works separately

But PutBlockFromURL proxy needs BOTH at the SAME TIME > Fails

Destination storage expects your VM to talk to it through its specific private endpoint during the proxy session. Cross-VNet routing confuses this session.

The Fix (Workaround 1)

Put Destination endpoint in Source VNet (Spoke A):
VM → Spoke A VNet → [Source PE + Dest PE together] > Works!

Workaround 4 succeeds because it doesn't need this coordination—just simple download from source.

Your ER routing is fine. Proxy just needs both endpoints in same VNet for the "handshake" to work.

Check NSG logs on destination endpoint during copy attempt you'll see the connection drops.
Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Pepijn Clarijs 0 Reputation points

2026-03-27T05:39:03.16+00:00

Hi venkatesan,

Thank you for taking the time to answer this question. It sounds like the explanation is along the lines of there being some different network layer that Azure backbone is using to authenticate the cross VNet traffic. But if that is the case, then why does workaround 2 work? Or is workaround 2 actually also doing a download + upload, like workaround 4 is? Why does direct peering work, but not indirect peering from a request from the VM in a third VNet?

Answer 2

Hi Nassim Cherifi ,

Thanks for the question.

How Workaround 1 works (technically)
In Workaround 1, AzCopy is the component that initiates all network traffic. A private endpoint does not initiate traffic by itself—it is simply a private IP mapped to the Azure Storage service. This is expected behavior for Azure Private Endpoint.

When AzCopy runs from a VM or host that:

Is placed in a VNet with access to both storage accounts

Resolves both storage account DNS names to their private endpoint IPs

AzCopy establishes two outbound connections:

One to the source storage account private endpoint

One to the destination storage account private endpoint

Data is streamed through the AzCopy client (source → AzCopy → destination). There is no direct storage-to-storage communication between private endpoints.

Why your assumption is correct
You are right that traffic is not initiated by the private endpoint. Private Endpoints only accept inbound connections; the client (AzCopy) always drives the data transfer.

Why this approach is scalable
Only the AzCopy execution environment requires network access to both storage accounts. This avoids needing multiple private endpoint peerings across VNets, making the setup more scalable.

References

Copy blobs between storage accounts with network restrictions
https://learn.microsoft.com/troubleshoot/azure/azure-storage/blobs/connectivity/copy-blobs-between-storage-accounts-network-restriction

Azure Private Endpoint overview
https://learn.microsoft.com/azure/private-link/private-endpoint-overview

Private Endpoint DNS behavior
https://learn.microsoft.com/azure/private-link/private-endpoint-dns

AzCopy networking and authentication overview
https://learn.microsoft.com/azure/storage/common/storage-use-azcopy-v10

I hope this clarifies. If the answer is helpful, please accept it to close the thread.

Gowtham CP 7,880 Reputation points Volunteer Moderator

2025-12-18T06:43:12.13+00:00

Nassim Cherifi Just checking in to see if the answer was helpful. If it resolved your question, please consider accepting the answer to close the thread. If you have any additional questions or need further clarification, feel free to let me know.

Share via

Using AzCopy to copy blobs between storage accounts with network restrictions

1 additional answer

References

Your answer