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 0

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,

Venkatesan S 1,180 Reputation points Microsoft External Staff Moderator

2025-12-17T09:19:32.13+00:00
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.

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.

Kindly let us know if the above helps or you need further assistance on this issue.

Please "up vote" if the information helped you. This will help us and others in the community as well.

1 answer

Your answer

Answer 1

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,085 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 answer

References

Your answer