Storage: Blob, Table, and Queue

Storage: Blob, Table, and Queue

An Azure storage account can expose multiple data services. Blob Storage stores unstructured objects; Table Storage provides a schemaless key-attribute store; Queue Storage decouples components with durable messages. Each has independent semantics despite sharing account-level configuration.

Core ideas

• Blob containers group objects; access tiers trade storage price against access and retrieval characteristics.
• Table entities use partition and row keys, making key choice central to distribution and efficient queries.
• Queue messages are delivered at least once and become invisible temporarily during processing.
• Redundancy options determine how storage copies are distributed within or across Regions.

Design and operating model

Choose an account type and redundancy from durability, availability, residency, recovery, and cost requirements. Disable public access unless intentional, use Microsoft Entra authorization, rotate or avoid account keys, and add lifecycle management. Make queue consumers idempotent and move repeatedly failing messages to an application-defined poison path.

Example

az storage account create \
  --name replaceuniquetrainingstore \
  --resource-group learning-rg \
  --location centralindia \
  --sku Standard_ZRS \
  --allow-blob-public-access false

az storage container create \
  --name lessons \
  --account-name replaceuniquetrainingstore \
  --auth-mode login

Run examples in a disposable training subscription. Replace names, Regions, identifiers, scopes, sizes, and policies with reviewed values, and confirm current Azure CLI and service requirements before production use.

Production guidance

• Use private endpoints and network rules when public service endpoints violate the threat model.
• Define retention, versioning, soft delete, immutability, and backup according to data class.
• Model storage transaction, retrieval, replication, and egress cost—not only capacity.

The chapter quiz follows the lesson and checks both service vocabulary and architecture decisions.