Upload & Manage Blobs with CLI

You've built infrastructure with Azure CLI, deployed apps, and wrestled with databases—but now your application needs to store files, and you're about to discover that uploading a 200 MB video to a VM's local disk is a recipe for heartbreak. When your instances scale down or crash, that data vanishes with them; when you need to share it across services, you're stuck. Azure Blob Storage fixes this, and the Azure CLI is the fastest way to start using it—no SDK, no portal clicking, just commands that fit into your shell history and your CI/CD scripts. This lesson turns that pain into a skill: by the end, you'll upload blobs, set access tiers, and manage them with the same confidence you have with ls and curl.

The problem this lesson solves

Your app needs durable, scalable file storage. Local disks are ephemeral, database blobs are slow and expensive, and FTP servers are a security nightmare from the previous decade. You need a place to drop files—images, backups, logs, machine-learning artifacts—that is durable (survives VM reboots and region outages), accessible from anywhere via HTTP/HTTPS, and cheap to start with. That's exactly what Azure Blob Storage provides, but the challenge is managing it efficiently.

Clicking through the Azure portal to upload a dozen files is fine once, but it doesn't scale, isn't reproducible, and can't be automated. The Azure CLI (az) solves this: one tool, installed on your laptop or in your pipeline, that can create storage accounts, containers, and blobs in seconds—and manage thousands of them. This lesson is your escape from "I'll just use the portal this once" to "I'll script the whole thing."

Core concept / mental model

Think of a storage account as a giant warehouse building. Inside the warehouse, you have containers—think of them as labeled rooms, each with its own access rules. Inside each container, you place blobs, which are the actual files: the boxes on the shelves. The Azure CLI gives you the keys to the warehouse, the room numbers, and the forklift—it doesn't move the boxes for you, but it makes every operation scriptable.

More formally:

• Storage account: The top-level object in Azure. It holds all your blob data, plus tables, queues, and files if you choose. You pay for the account's storage and operations.
• Container: A logical grouping of blobs, similar to a directory (but not a real filesystem). It has a name (lowercase letters, numbers, and hyphens) and a default access level (private, blob, or container).
• Blob: The file itself. Azure Blob Storage supports three types: block blobs (for most files, including large uploads), page blobs (for random-access files like VHDs), and append blobs (for streaming logs). You'll work with block blobs 99% of the time.
• Access tier: Hot (frequent access), Cool (infrequent, cheaper), or Archive (long-term, offline). You can set tiers to optimize cost.

A mental model for the command structure: az storage is the root namespace, then you drill down: az storage account (manage the warehouse), az storage container (manage rooms), and az storage blob (manage boxes). Each command takes a --name and either --account-name or --connection-string, plus optional parameters for security and transfer performance.

How it works step by step

Here's the logical sequence from nothing to an uploaded blob—cause and effect at each step.

1. Create a storage account with az storage account create. This is the foundation; without it, containers don't exist. The account has a globally unique name (3–24 characters, lowercase letters and numbers) and a location (e.g., eastus). You also pick a performance tier (Standard or Premium) and a replication strategy (e.g., LRS for local, GRS for geo-redundant).
2. Grab the connection string or auth context. To talk to blobs, the CLI needs credentials. You have two options: use your Azure AD login (via az account set) or get a storage account key/connection string with az storage account show-connection-string. For scripts, connection strings are simpler, but for security, prefer Azure AD with managed identity in production.
3. Create a container with az storage container create. Give it a unique name within the account, and set the access level (--public-access off, blob, or container). Private is the default and safest.
4. Upload a blob with az storage blob upload. This sends the file from your local disk to the container. You can specify --content-type, --tier (Hot/Cool/Archive), and --overwrite to replace an existing blob.
5. Manage the blob: list blobs, download them, copy between containers, set metadata and tags, change tiers, delete—all with az storage blob subcommands.

The CLI handles authentication for you if you've run az login, but remember: for automation, use a service principal or connection string, not interactive login.

Hands-on walkthrough

Let's make this concrete. I'll assume you've installed the Azure CLI and logged in (az login). If not, pause and do that first—it takes two minutes.

Step 1: Set up a resource group and storage account

# Login (interactive)
az login

# Create a resource group (if you don't have one)
az group create --name rg-blob-tutorial --location eastus

# Create a storage account (name must be globally unique)
az storage account create \
  --name blobtutorialsa \
  --resource-group rg-blob-tutorial \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2

Expected output includes "provisioningState": "Succeeded" and your primaryEndpoints.blob URL.

Step 2: Get the connection string

az storage account show-connection-string \
  --name blobtutorialsa \
  --resource-group rg-blob-tutorial \
  --output tsv

This outputs a string like DefaultEndpointsProtocol=https;AccountName=blobtutorialsa;AccountKey=.... Save it as an environment variable for the next commands:

export AZURE_STORAGE_CONNECTION_STRING='<your-connection-string>'

You can also set it in the CLI config, but env var is cleaner for tutorials.

Step 3: Create a container

az storage container create \
  --name logs \
  --connection-string "$AZURE_STORAGE_CONNECTION_STRING"

Result: {"created": true}. The container is private by default—only you can read blobs.

Step 4: Upload a blob

Create a sample file and upload it:

echo "hello from CLI" > sample.txt

az storage blob upload \
  --container-name logs \
  --file sample.txt \
  --name sample.txt \
  --connection-string "$AZURE_STORAGE_CONNECTION_STRING"

Output shows "uploaded": true. Now list the blobs in the container:

az storage blob list \
  --container-name logs \
  --output table \
  --connection-string "$AZURE_STORAGE_CONNECTION_STRING"

You'll see sample.txt in the table with properties like Last Modified.

Step 5: Manage the blob

Download it back to a different filename to verify:

az storage blob download \
  --container-name logs \
  --name sample.txt \
  --file downloaded.txt \
  --connection-string "$AZURE_STORAGE_CONNECTION_STRING"

cat downloaded.txt  # prints "hello from CLI"

Set the access tier to Cool (if you don't need frequent access):

az storage blob set-tier \
  --container-name logs \
  --name sample.txt \
  --tier Cool \
  --connection-string "$AZURE_STORAGE_CONNECTION_STRING"

And finally, delete the blob when done:

az storage blob delete \
  --container-name logs \
  --name sample.txt \
  --connection-string "$AZURE_STORAGE_CONNECTION_STRING"

Pro tip: Always use --connection-string in these examples to avoid ambiguity. If you skip it, the CLI will try to use your Azure AD login, which works, but requires you to set --auth-mode login on some commands.

Compare options / when to choose what

You have three main ways to upload blobs in Azure: Azure CLI, Azure Portal, and Azure SDKs (Python, .NET, etc.). Here's a practical comparison:

When to choose CLI: You're doing one-off management, automating CI/CD, or writing a quick backup script. It's perfect for the checkpoint-style tasks in this track.

Variations: You can also use az storage blob upload-batch to upload multiple files at once, or azcopy for massive transfers—more on that in troubleshooting.

Troubleshooting & edge cases

• Error: "The specified container does not exist" — You forgot to create the container, or you're using the wrong container name. Double-check az storage container list.
• Error: "The specified resource name contains invalid characters" — Container names must be lowercase and only contain letters, numbers, and hyphens. MyContainer is invalid; mycontainer is valid.
• Error: "The specified signed identifier is empty" — You're trying to use a SAS token without proper permissions. For this lesson, use a connection string instead.
• Slow uploads for large files — The CLI's az storage blob upload uses a single connection by default. For files larger than a few hundred MB, use az storage blob upload --overwrite --tier Hot with the --max-connections parameter (--max-connections 4) or switch to azcopy, which is specifically built for high-speed transfers.
• Authentication issues in CI/CD — If you can't run az login in a pipeline, create a service principal with az ad sp create-for-rbac and use az login --service-principal -u <app-id> -p <password> --tenant <tenant>. Then use the connection string for blob operations.
• Private container access — If you try to curl a blob URL and get ResourceNotFound, that's correct—the container is private. Use az storage blob url --container-name logs --name test.txt --output tsv to get a SAS-signed URL.

What you learned & what's next

You now understand the three‑layer model of Azure Blob Storage—storage account, container, blob—and you've used the CLI to create each, upload a file, list it, download it, change its tier, and delete it. You've also learned when to reach for the CLI versus the portal or an SDK, and how to handle the most common authentication and transfer errors.

Your next lesson in this Azure path will likely cover automating blob lifecycle management (e.g., setting retention policies, moving blobs to archive tier automatically) or integrating blob storage with Key Vault for secure access. With the blob commands you just practiced, you're ready for those—the same az storage namespace will be your constant companion.

Key takeaway: The CLI turns every blob operation into a one‑liner you can copy into a script. Practice the full cycle once more on your own—create a container, upload two files, then remove one—and you'll have it memorized.