AzCopy S3 to Azure: How It Works and the Limits to Check
· 3 min read · Updated
AzCopy's documented AWS S3 transfer uses Azure's Put Block From URL operation. AWS S3 and Azure Storage exchange the object data without using your computer's network bandwidth.[1]
For teams comfortable with a command line, that makes AzCopy a strong option. It can copy one object, a directory, a bucket, or wider groups of AWS buckets.
Server-to-server copying settles the data route. You still have to plan names, metadata, authentication, and the destination tier.
The Azure side can use Microsoft Entra ID or a SAS token. The documented AWS flow uses an AWS access key and secret access key supplied through environment variables.
Keep those credentials out of shell history, scripts, logs, and CI output, and use the narrowest permissions that cover the source and destination.
AWS S3 bucket names and Azure container names allow different characters. AzCopy rewrites names that Azure cannot accept.
Periods can become hyphens, and consecutive hyphens can be rewritten too. Two different S3 bucket names can therefore map to the same Azure container name, which forces another rename.
Before a large migration, write down which bucket goes to which container. Otherwise you find out the naming plan from the destination after the copy has finished.
S3 and Azure also allow different characters in metadata keys. AzCopy's --s2s-handle-invalid-metadata flag has three behaviors:
ExcludeIfInvalidomits incompatible metadata and logs a warning.FailIfInvalidfails that object.RenameIfInvalidchanges the metadata key.
With the default exclusion behavior, an object can copy successfully and arrive without some of its metadata. If metadata drives retention, compliance, processing, or ownership, review this flag before running the job.
Microsoft's documented S3 flow uses AWS S3 URL formats. Don't assume the same command accepts every Wasabi, Cloudflare R2, MinIO, DigitalOcean Spaces, or private S3-compatible endpoint.
Test the exact provider and endpoint. For non-AWS sources, a tool that accepts generic S3 endpoint URLs may be a better fit.
Use AzCopy when the team wants server-to-server speed, scripting, automation, and repeatable command lines.
Use a desktop tool when the person running the move needs visual file selection, browsing, previews, and fewer command flags. Blober connects AWS S3, Azure Blob Storage, and generic S3-compatible endpoints in one app on your computer, and lets you pick the Azure tier the copies land on. Its data path differs from AzCopy's: Blober downloads each object from the source and uploads it to Azure over your own connection. Choose by network, security, and operational needs; neither design is better in every case.
AzCopy also supports job resume and restart. Its source code and current release details are published on GitHub.[2]
Does AzCopy use my bandwidth when copying from S3 to Azure? No. It uses Azure's Put Block From URL operation, so S3 and Azure exchange the data without passing it through your computer[3].
What happens to S3 metadata that Azure doesn't accept?
By default AzCopy leaves it out and logs a warning. Set --s2s-handle-invalid-metadata to FailIfInvalid to fail those objects instead, or to RenameIfInvalid to rename the keys.
Can AzCopy copy from Wasabi or Cloudflare R2? Microsoft documents the S3 flow with AWS S3 URL formats. Test your exact provider and endpoint before you rely on it.
Can an interrupted AzCopy job be resumed? Yes. AzCopy supports resuming and restarting jobs[4].