Blob Storage Explained: Objects, Containers, and Accounts

The three-level hierarchy

Think of it like a filing system:

• Storage account — the top-level resource. Provides the namespace and URL endpoint. Billing and access control start here.
• Container — a logical grouping inside an account. Similar to a bucket in S3 or a top-level folder. Each account can have unlimited containers.
• Blob — the actual file or object. Lives inside a container. Each blob has a name, content, and metadata.

A blob’s full address combines all three levels:

https://<account>.blob.core.windows.net/<container>/<blob-name>

For example: https://mycompany.blob.core.windows.net/assets/images/logo.png

That URL tells you the account (mycompany), the container (assets), and the blob name (images/logo.png).

Working with containers

Containers are the main organizational unit you control day-to-day. You create them with a name, and optionally set a public access level.

# List existing containers in a storage account
az storage container list \
  --account-name mystorageaccount123 \
  --auth-mode login \
  --output table

# Create a new private container
az storage container create \
  --name assets \
  --account-name mystorageaccount123 \
  --auth-mode login

# Create a container with blob-level public read access
az storage container create \
  --name public-images \
  --account-name mystorageaccount123 \
  --public-access blob \
  --auth-mode login

The —public-access flag controls anonymous access to the container’s contents:

• off (default) — no anonymous access; callers must authenticate
• blob — anyone with the URL can read individual blobs
• container — anyone can list and read all blobs in the container

The three blob types

Azure Blob Storage has three distinct blob types. You choose the type when you upload a blob, and you cannot change it afterward.

Block blobs

Block blobs are the default and the most common type. They store data as a sequence of blocks, each up to 4,000 MB. Azure assembles the blocks into the final blob when you commit them. This block-based design is what enables efficient uploads of very large files — you can upload blocks in parallel and retry failed blocks individually.

Use block blobs for: images, documents, videos, backups, log archives, static website files — essentially anything you’d normally think of as a “file.”

Append blobs

Append blobs are optimized for write operations that only add data to the end. You cannot update or delete individual blocks. This makes them ideal for logging: each write call appends new log lines without overwriting existing data, and concurrent writers don’t conflict with each other.

Use append blobs for: application logs, audit trails, diagnostic data, or any data stream where you write continuously and read less frequently.

Page blobs

Page blobs store data in 512-byte pages and support random read and write access to any page. They underpin Azure VM disks — when you create a virtual machine with unmanaged disks (legacy), the VHD file is stored as a page blob. Azure Managed Disks use the same underlying mechanism but abstract it away from you.

Most developers never create page blobs directly. If you’re building applications (rather than managing VMs), you’ll use block blobs almost exclusively.

Uploading and listing blobs

The Azure CLI makes blob operations straightforward. Here’s a typical workflow:

# Upload a single file as a block blob
az storage blob upload \
  --account-name mystorageaccount123 \
  --container-name assets \
  --name images/logo.png \
  --file ./logo.png \
  --auth-mode login

# Upload an entire local folder recursively
az storage blob upload-batch \
  --account-name mystorageaccount123 \
  --destination assets \
  --source ./my-local-folder \
  --auth-mode login

# List all blobs in a container
az storage blob list \
  --account-name mystorageaccount123 \
  --container-name assets \
  --auth-mode login \
  --output table

# List blobs with a specific prefix (simulating a "folder")
az storage blob list \
  --account-name mystorageaccount123 \
  --container-name assets \
  --prefix images/ \
  --auth-mode login \
  --output table

# Download a blob to a local file
az storage blob download \
  --account-name mystorageaccount123 \
  --container-name assets \
  --name images/logo.png \
  --file ./downloaded-logo.png \
  --auth-mode login

Blob properties and metadata

Every blob has system properties set automatically by Azure (content type, length, ETag, last modified date) and custom metadata you define as key-value pairs.

Setting the correct content type matters when blobs are served directly to browsers. If you upload a JPEG without setting the content type, some clients may not render it correctly.

# Upload with explicit content type
az storage blob upload \
  --account-name mystorageaccount123 \
  --container-name assets \
  --name images/banner.jpg \
  --file ./banner.jpg \
  --content-type image/jpeg \
  --auth-mode login

# Set custom metadata on an existing blob
az storage blob metadata update \
  --account-name mystorageaccount123 \
  --container-name assets \
  --name images/banner.jpg \
  --metadata campaign=spring2026 uploaded-by=ci-pipeline \
  --auth-mode login

# Read blob properties
az storage blob show \
  --account-name mystorageaccount123 \
  --container-name assets \
  --name images/banner.jpg \
  --auth-mode login \
  --output json

Custom metadata is useful for tagging blobs with information your application needs — like the user who uploaded a file, the processing status, or the source system that created the object.

Naming conventions that save you pain later

Blob names can be up to 1,024 characters and support Unicode. However, a few characters cause problems in URLs: # and ? break URL parsing, and leading or trailing spaces cause confusion. Stick to alphanumeric characters, hyphens, underscores, and forward slashes.

Design your naming scheme around your access patterns. If you’ll frequently list blobs by date, put the date first: 2026/03/19/error.log rather than error-2026-03-19.log. Prefix-based listing only works efficiently on the left side of the name.

For high-throughput scenarios, avoid using sequential prefixes like incrementing numbers or dates at the very start of every blob name. Azure Blob Storage partitions data by name prefix, so if all your blobs start with the same prefix, writes hit the same partition and performance degrades. Add a hash or random prefix before the date to spread load across partitions.