AzCopy v10: the command line mover for Azure Storage, with S3 and GCS as sources

A transfer tool whose interface never changes shape

AzCopy v10 is a command-line utility for copying data to and from containers and file shares in Azure Storage accounts, and the README claims that it presents easy-to-use commands that are optimized for high performance and throughput.

The interface is the same for everything, and the README states the general format in one line.

The general format of the AzCopy commands is: `azcopy [command] [arguments] --[flag-name]=[flag-value]`

A command, its arguments, and then flags. That shape is what makes the tool learnable, and the help system is built around it. To see a list of commands, type `azcopy -h` and then press the ENTER key, and to learn about a specific command, just include the name of the command, for example `azcopy list -h`. The README also suggests adding the AzCopy directory location to your system path for ease of use, so that you can type `azcopy` from any directory on your system.

That consistency matters more than it sounds. A tool with twelve verbs and a uniform flag syntax can be driven from a script, wrapped in a pipeline step, or learned in an afternoon. The set of verbs here is bench, copy, sync, login, logout, list, doc, env, help, jobs, load, make and remove.

Two of those verbs are unusual and worth understanding. `doc` generates documentation for the tool in Markdown format, and `env` shows the environment variables that you can use to configure the behavior of AzCopy. So the tool can describe its own surface, and its configuration is inspectable at runtime rather than only through a file.

The implementation is Go, the module path is github.com/Azure/azure-storage-azcopy/v10, and the licence is MIT. The last push was on 2026-10-19, with releases v10.32.8 from 2026-08-27, v10.32.7 from 2026-08-12 and a v10.33.0-beta from 2026-07-31.

copy and sync, and the mistake that breaks a migration

Two verbs move data, and they are not interchangeable. `copy` copies source data to a destination location, and `sync` replicates source to the destination location.

The difference is what happens to files at the destination that are not in the source. A copy adds and overwrites; it does not remove. A sync mirrors the source, which means it can delete at the destination. That is the whole distinction, and it is the one thing to get right before pointing the tool at a directory that already contains data.

The direction tables in the README make the scope explicit, and they are not the same for the two verbs. For copy, the table runs from Local to Azure Blob with Microsoft Entra ID or SAS, from Local to Azure Files over SMB with Entra ID or a share or directory SAS, from Local to Azure Files over NFS with the same forms, and from Local to Azure Data Lake Storage with Entra ID, SAS or Shared Key. In the other direction, Azure Blob, Azure Files SMB, Azure Files NFS and Azure Data Lake Storage can all be copied back to Local with the matching forms of authorization.

The service to service rows are where the tool earns its keep, and there are eleven of them for copy, including Azure Blob to Azure Blob, Azure Blob to Azure Files SMB, Azure Files SMB to Azure Files SMB, Azure Files NFS to Azure Files NFS, Azure Data Lake Storage to Azure Data Lake Storage, and the cross pairs between Blob, Files and ADLS.

For sync the table is shorter, with nine rows covering Local to and from Blob and File, Blob to Blob, Blob to File, File to Blob, File to File with the note that it is SAS or public, and ADLS to ADLS.

Notice what is not in either table. There is no S3 to GCS row, no S3 to Blob sync row, and no sync from S3 at all. The cross-cloud rows are copy only.

S3 and GCS as sources, but only into block blob

The feature list includes copying objects, directories, and buckets from Amazon Web Services to Azure Blob Storage, blobs only, and the same from Google Cloud Platform to Azure Blob Storage, blobs only.

The documentation mirrors that with two separate pages, one on transferring data with AzCopy and Amazon S3 buckets, and one on Google GCP buckets. The authorization forms are listed in the copy table and they are different from the Azure forms. AWS S3 with Access Key, and Google Cloud Storage with a Service Account Key, in both cases copying to Azure Block Blob with Microsoft Entra ID or SAS.

So the cross-cloud story is deliberately narrow in two directions. The destination is block blob, not file share and not ADLS, and the source is a bucket or a prefix of one, not a full cross-cloud replication arrangement. The Go module confirms the shape of the implementation, with a separate Google Cloud Storage client and a Google API module alongside the Azure SDK clients for blob, data lake and file.

There is one interesting dependency in the list that is not about cloud storage at all. The module includes minio-go, the Go client for MinIO, and the repository has a mock_server directory. That points to the S3 path being exercised against a local S3-compatible server in tests rather than against Amazon itself, which is a sensible way to test a bucket-copy implementation without network dependence.

The practical reading is that AzCopy v10 is an Azure Storage tool with a convenience migration path from the two other major object stores, not a multi-cloud synchronisation engine. If your source of truth lives in S3 and you want it mirrored in Azure continuously, that is a different product.

Jobs, resume, and the benchmark command

The feature list includes recover from failures by restarting previous jobs, and the `jobs` command group exists for managing them. Combined with the `copy` and `sync` verbs, that gives the tool a job model where a transfer is an addressable object rather than a side effect of a running process.

That is the property that matters for large transfers. A multi-terabyte copy over a link that drops is the normal case, not the exception, and a tool where the job can be restarted and where the destination state is tracked is the difference between resuming and starting over.

There is also `bench`, which runs a performance benchmark by uploading or downloading test data to or from a specified destination. That command is the one to reach for first on an unfamiliar link, because the whole value of the tool is that it is optimised for high performance and throughput, and the number your transfer will actually achieve is a property of your network and your storage account rather than of the binary. Benchmarking against your own destination is the way to find out what you are dealing with before committing a large copy to it.

Two more verbs fit the operational picture. `make` creates a container or file share, which saves a separate step before a copy. And `remove` deletes blobs or files from an Azure storage account, which is listed as a supported capability alongside `list`, the command that lists the entities in a given resource.

`load` is the one whose description is the least clear, described as sub-commands related to transferring data in specific formats. The README does not enumerate them, so a reader looking for a particular format has to ask the tool itself.

How the tool is installed, and where the real documentation lives

The README does not contain an install command, and the reason is stated directly. The latest binary for AzCopy along with installation instructions may be found in the Azure Storage documentation, and the same is true of the getting started page with its download links.

So the distribution is a downloadable binary rather than a package you build, and the documentation site is the place where the install steps, the platform packages and the configuration guidance live. The README is a reference for the command surface, not a getting started guide.

The documentation links are organised by task, and the list is a good index of what people actually ask. There are pages on uploading files to Azure Blob storage by using AzCopy, downloading blobs, copying blobs between Azure storage accounts, synchronizing between Local File System, Azure Blob Storage Gen1 and Azure File Storage, transfer data with AzCopy and file storage, transfer with Amazon S3 buckets, transfer with Google GCP buckets, use data transfer tools in Azure Stack Hub Storage, and configure, optimize, and troubleshoot AzCopy. There is also an AzCopy WiKi and a set of instructions for use in Azure Stack Hub Storage.

The repository itself is a full Go project with an Azure Pipelines setup, and the top level gives a sense of the scope. There are directories for the command implementation, the common packages, the traverser that walks a source tree, the jobs administrator, the telemetry package, the setup code, the mock server used in tests, an end-to-end test directory with a PowerShell cleanup script, a test suite, a website directory for the docs site, and a docker directory. There is a MigrationGuideV8toV10.md at the top level, which is there for the people still moving from the previous version of the tool, and a ChangeLog.md alongside a per- release ChangeLog directory.

The Docker directory is worth a note for anyone who wants AzCopy in a pipeline image rather than on a workstation, and the presence of a Dockerfile-based path alongside the binary download reflects that a data transfer tool frequently ends up inside a container rather than on a laptop.

The limits, and what AzCopy is not for

Three boundaries are visible in the documentation and worth stating plainly.

The first is that Azure is always one side of the operation. The copy and sync tables both terminate in an Azure Storage type. A transfer from S3 to GCS, or a continuous mirror between two non-Azure object stores, is not in the tables and is not what the tool is for. The cross-cloud rows are a migration convenience, not a replication engine.

The second is the asymmetry between copy and sync, which is a safety issue rather than a capability one. The tool will mirror a source onto a destination, and mirroring means removal. The README does not document a dry run flag, a what-if mode, or a confirmation prompt for the destructive case, so the protection is the reader's own understanding of which verb was typed. That is why picking the verb deliberately, before a large transfer, is the practical step.

The third is the blob-only restriction on the cloud-to-cloud paths, which rules out a common migration shape. A team that wants to move an S3 bucket into an Azure file share, or a GCS bucket into ADLS, has no direct path in the tool.

The honest alternative for a large migration is not another tool so much as a different arrangement of the work. A pipeline that stages objects through a machine you control, or a purpose-built migration service, gives more control over the path and the credentials involved. AzCopy is the right tool when both sides of the transfer are Azure Storage, or when the source is S3 or GCS and the destination is block blob, and it is a good tool for those cases because the job model and the benchmark command make the work resumable and measurable.

The MIT licence permits use in commercial pipelines without obligation beyond retaining the notice, and the security documentation and the SECURITY.md file in the repository are the right place to look before wiring it into an automated path with storage credentials in its environment.

Editorial conclusion

AzCopy v10 fits a team moving terabytes into or out of Azure Storage, or ingesting from S3 or GCS, who wants throughput and a job model that survives an interrupted run. It does not fit a workload whose data is spread across several clouds in a way that needs bidirectional sync between two non-Azure stores, since Azure is always one side of the operation. Before starting a large transfer, read the copy and sync direction tables in the README and pick the verb deliberately, because copy moves what you name and sync mirrors the source, and use azcopy bench against your own destination first to find out what your link can actually sustain.

Frequently asked questions

Official sources

1. Azure/azure-storage-azcopy on GitHub
2. Issues
3. License: MIT
4. README
5. Releases