Azure Storage (Blob, Queue, Table, File)

Durable, massively scalable object and structured storage with four services: Blob (objects), Queue (messaging), Table (NoSQL key-value), and File (SMB shares).

AzureIntermediate

Why

Azure Storage provides a single account that hosts up to 500 TB of data across four services with 99.999999999% (11 nines) durability for LRS. It is the backbone for object storage, async messaging, and NoSQL in Azure, and is cheaper than Cosmos DB for simple key-value workloads.

When

Use Blob for static assets, backups, and unstructured files; Queue for decoupling producers/consumers; Table for simple partitioned key-value data; File for lift-and-shift apps needing SMB. Avoid Table when you need secondary indexes, rich queries, or multi-region writes — use Cosmos DB instead.

How

1. Create a storage account (chooses redundancy: LRS/GRS/ZRS/RAGRS). 2. Create a container (Blob) or queue/table. 3. Get connection string or generate a SAS token with scoped permissions and expiry. 4. Upload/download via Azure SDK (@azure/storage-blob) or AzCopy CLI. 5. Configure CORS for browser access. 6. Set lifecycle policy to tier blobs to Cool/Archive and delete old ones. ```bash az storage account create --name mystore --resource-group rg --sku Standard_LRS --kind StorageV2 az storage container create --name uploads --account-name mystore az storage blob upload --account-name mystore --container-name uploads --name photo.jpg --file ./photo.jpg ```

Example

Node.js upload with a SAS token and lifecycle rule auto-archiving blobs after 90 days: ```ts import { BlobServiceClient } from "@azure/storage-blob"; const conn = process.env.AZURE_STORAGE_CONNECTION_STRING!; const svc = BlobServiceClient.fromConnectionString(conn); const container = svc.getContainerClient("uploads"); const blob = container.getBlockBlobClient("photo.jpg"); await blob.uploadFile("./photo.jpg"); console.log("Uploaded:", blob.url); ``` ```json // lifecycle: archive after 90 days, delete after 365 { "rules": [{ "enabled": true, "name": "archive", "type": "Lifecycle", "definition": { "actions": { "baseBlob": { "tierToArchive": { "daysAfterModificationGreaterThan": 90 } } }, "filters": { "blobTypes": ["blockBlob"] } } }] } ```

Common Problems

⚠403 PublicAccess is not permitted — container access level is Private; generate a SAS token or set --public-access blob instead of relying on anonymous access.
⚠SAS token expired error in production — tokens have a fixed expiry; use stored access policies to roll expiry without reissuing, or use Managed Identity with RBAC.
⚠High egress cost when replicating GRS across regions — confirm you actually need geo-redundancy; LRS or ZRS is far cheaper for single-region workloads.

Best Practices

✓Prefer Managed Identity + RBAC over connection strings so no secret is stored in code or config, and access is revocable via role assignment.
✓Always set a lifecycle policy to tier infrequently accessed blobs to Cool/Archive — this alone can cut storage cost by 50%+.
✓Use block blobs for large uploads (resumable), append blobs for logs (concurrent appends), and page blobs only for VHD-backed disks.

FAQ

What is Azure Storage (Blob, Queue, Table, File) and what problem does it solve?

Durable, massively scalable object and structured storage with four services: Blob (objects), Queue (messaging), Table (NoSQL key-value), and File (SMB shares). It lets developers deploy, store, and scale without self-managing infrastructure — a core reference for cloud service selection.

How do I get started with Azure Storage (Blob, Queue, Table, File) in 5 minutes?

Two steps to run it: (1) Create a storage account (chooses redundancy: LRS/GRS/ZRS/RAGRS).; (2) Create a container (Blob) or queue/table.. Validate on the free tier first, then wire into production.

What is the #1 pitfall with Azure Storage (Blob, Queue, Table, File)?

The most frequent issue is: 403 PublicAccess is not permitted — container access level is Private; generate a SAS token or set --public-access blob instead of relying on anonymous access.. Run a pre-launch checklist item by item, and add policy/config scanning in CI.

What are the best practices for Azure Storage (Blob, Queue, Table, File)?

Best practices for Azure Storage (Blob, Queue, Table, File) include: Prefer Managed Identity + RBAC over connection strings so no secret is stored in code or config, and access is revocable via role assignment.; Always set a lifecycle policy to tier infrequently accessed blobs to Cool/Archive — this alone can cut storage cost by 50%+.; Use block blobs for large uploads (resumable), append blobs for logs (concurrent appends), and page blobs only for VHD-backed disks.. The first one — "Prefer Managed Identity + RBAC over connection strings so no secret is stored in code or config, and access is revocable via role assignment." — should be a team default baked into your IaC templates.

How do I control cost and avoid bill surprises with Azure Storage (Blob, Queue, Table, File)?

Three ways to prevent overspend: (1) tag every resource with env/team and enable billing alarms; (2) set budget thresholds to trigger Slack/email alerts; (3) review idle resources in Cost Explorer regularly and clean them up. Most Azure Storage (Blob, Queue, Table, File) options offer a free tier — validate within free quota before scaling.