Azure Storage Explorer and AzCopy

Two tools cover almost all hands-on work with Azure Storage data: a GUI for browsing and managing, and a command-line tool for moving data at volume. Neither is complicated, but both have sharp edges around authentication and endpoints that account for most of the time people lose to them.

Azure Storage Explorer

Storage Explorer is a standalone application for Windows, macOS, and Linux that uploads, downloads, and manages blobs, files, queues, tables, Data Lake Storage entities, and managed disks. It handles multiple accounts and subscriptions at once, and can preview data and configure storage permissions and access controls.

Its useful trick is the range of ways it can attach to storage you don't own outright:

Scenario	Description
Connect to an Azure subscription	Manage storage resources belonging to your subscription.
Work with local development storage	Manage local storage using the Azurite emulator.
Attach to external storage	Manage resources in another subscription or a national Azure cloud, using the account name, key, and endpoints. Choose Other in the Storage endpoints domain menu to enter a custom endpoint domain.
Attach a storage account with a SAS	Manage resources in another subscription using a shared access signature.
Attach a service with a SAS	Manage one specific service — a blob container, queue, or table — in another subscription using a SAS.

The last two are how you give someone scoped access to storage without adding them to your directory: issue a SAS, they attach with it, and the access expires on its own.

Course material still refers to the Azure Storage Emulator for local development. It's been superseded by Azurite, an open-source emulator written in JavaScript, running on Node.js, cross-platform, and updated for current Storage APIs. One limitation worth knowing before planning around it: Azurite emulates Blob, Queue, and Table only — not Azure Files and not Data Lake Storage Gen2. It does support RA-GRS, with the secondary reachable by appending -secondary to the account name.

AzCopy

AzCopy is a command-line tool for high-performance copying of data to, from, and between storage accounts. It's built for large datasets, performs parallel transfers, and is resilient to network interruptions. It resumes rather than restarting, which is what makes it viable for transfers measured in hours.

Authenticate with a SAS, not the account key

Using a SAS token rather than the account key is the right approach. It limits what the transfer can touch and avoids putting a full-access credential into a command line, a script, or a shell history file.

A typical upload:

Open a shell and change to the AzCopy directory.
Generate a SAS token for the destination container with write permissions, a limited duration — six hours, say — and HTTPS only. Copy the whole SAS URL including the account and container name.
Run the copy, giving the source path and the destination SAS URL.

azcopy copy <source_file_path> <SAS_token_URL>
azcopy copy '\\server1\images' 'https://corpimages.blob.core.windows.net/public' --recursive

The PowerShell equivalent pipes files into the storage cmdlet:

Get-ChildItem -Path \\server1\images -Recurse | Set-AzStorageBlobContent -Container "corpimages"

Creating a container

azcopy make creates a container, and it must be pointed at the blob endpoint:

azcopy make 'https://<storage-account-name>.blob.core.windows.net/<container-name>'

azcopy sync synchronises a source and a destination — it doesn't create containers, so it isn't a substitute for make.

The endpoint decides whether the command works

Getting the endpoint wrong is the most common AzCopy mistake, and the error it produces isn't always obvious:

Endpoint	Service
`blob.core.windows.net`	Blob Storage — the correct endpoint for creating containers
`file.core.windows.net`	Azure Files
`queue.core.windows.net`	Queue Storage
`table.core.windows.net`	Table Storage
`dfs.core.windows.net`	Data Lake Storage
`images.core.windows.net`	Not a valid Azure Storage endpoint

A command aimed at queue.core.windows.net won't create a blob container no matter how correct the rest of the syntax is.

When transfers fail

The SAS token expired mid-transfer, giving an authentication error. Regenerate with a longer duration and restart. For long transfers, size the validity window against the expected transfer time, not the optimistic one.

The SAS URL is wrong or incomplete. Check it includes the account name, container name, and all parameters.

Network connectivity dropped. AzCopy is designed for this and resumes automatically; ensure the connection is stable and retry.

Offline transfers

Azure Import/Export solves a different problem: large-scale offline transfers, where you ship physical disk drives to an Azure data centre. It supports blobs and files only, and it isn't an alternative to AzCopy for network transfers — the two aren't competing.

Worth knowing that Import/Export jobs are now created through the Azure Data Box resource rather than the standalone Import/Export interface. If a question or a runbook points you at the old path, that's why it isn't there.