LinkedIn

Cloud  /  Azure

Microsoft Azure 26 guides · updated 2026

Practical guides to Azure compute, networking, storage, and data services — built for engineers running production workloads on Microsoft's cloud.

Azure Blob Storage: Object Storage Across Hot, Cool, Cold, and Archive Tiers

Blob Storage is Azure’s object storage service for unstructured data: images, videos, log files, database backups, ML training datasets, web assets, and anything else that does not fit neatly into a database row or file share directory. It scales to exabytes with no configuration, charges per gigabyte stored, and handles redundancy automatically based on the replication option you select.

Every object lives inside a container, inside a storage account. The storage account is the billing and access-control boundary. Containers are flat namespaces — there are no real folders, but the / character in blob names creates the illusion of a directory tree in the portal and most SDKs.

Real-World Scenario

A news media company publishes 500 articles per day, each with several images. Recent articles (last 30 days) are served directly to readers and must load quickly — Hot tier. Articles from the past year are occasionally accessed for references — Cool tier. Articles older than a year are kept for legal compliance but rarely read — Archive tier. A lifecycle management policy handles the transitions automatically, cutting storage costs by over 60% compared to keeping everything on Hot.

Blob Types

Blob Type       | Description                          | Typical Use
----------------|--------------------------------------|------------------------------
Block Blob      | Optimised for sequential upload      | Images, video, backups, docs
                | Up to 190.7 TB per blob              |
                | Uploaded in blocks, committed at end |
----------------|--------------------------------------|------------------------------
Append Blob     | Only append operations allowed       | Log files, audit trails
                | Each append is atomic                | Cannot overwrite existing data
----------------|--------------------------------------|------------------------------
Page Blob       | Random read/write, 512-byte pages    | Azure VM OS and data disks
                | Up to 8 TB                           | IaaS disk backing

Page blobs underpin Azure managed disks. If you are building an application, you will almost always use block blobs. Append blobs are niche but perfect for scenarios where you need to write log entries from multiple concurrent writers without locking.

Access Tiers

Tiers control the cost trade-off between storage price and access price. Frequently read data should stay Hot; rarely read data should move to cooler tiers:

Tier       | Storage Cost | Access Cost | Min Storage Duration | Retrieval Latency
-----------|--------------|-------------|----------------------|------------------
Hot        | Highest      | Lowest      | None                 | Milliseconds
Cool       | Lower        | Higher      | 30 days              | Milliseconds
Cold       | Lower still  | Higher      | 90 days              | Milliseconds
Archive    | Lowest       | Highest     | 180 days             | Hours (rehydrate first)

Archive tier is offline — blobs cannot be read until rehydrated to Hot or Cool, which takes 1–15 hours depending on the rehydration priority (High priority: up to 1 hour; Standard: up to 15 hours).

Tiers are set at the individual blob level (not the container or account level), giving fine-grained control.

Lifecycle Management Policy

Lifecycle policies run daily and move or delete blobs based on age and last-access time:

{
  "rules": [
    {
      "name": "media-tiering",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["media/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 365 },
            "delete": { "daysAfterModificationGreaterThan": 2555 }
          },
          "snapshot": {
            "delete": { "daysAfterCreationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

Lifecycle policies apply to containers, blob prefixes, or blob index tags. Combining prefix filters with tag filters lets you apply different retention rules to different content categories stored in the same container.

SAS Tokens

A Shared Access Signature (SAS) grants time-limited, scoped access to a storage resource without sharing the account key. There are three types:

SAS Type           | Scope           | Best For
-------------------|-----------------|------------------------------------------
Account SAS        | Entire account  | Service-level operations (rarely used)
Service SAS        | One service     | Delegate read/write on one container
User Delegation SAS| One service     | Same as Service SAS but signed with
                                      Azure AD credentials (preferred)

User Delegation SAS is the most secure option — it does not expose the account key and can be revoked by revoking the user’s Azure AD token or the delegation key.

from azure.storage.blob import (
    BlobServiceClient,
    generate_blob_sas,
    BlobSasPermissions,
)
from datetime import datetime, timedelta, timezone


sas_token = generate_blob_sas(
    account_name="mystorageacct",
    container_name="media",
    blob_name="video/welcome.mp4",
    account_key="<account_key>",          # or use user delegation key
    permission=BlobSasPermissions(read=True),
    expiry=datetime.now(timezone.utc) + timedelta(hours=2),
)
url = f"https://mystorageacct.blob.core.windows.net/media/video/welcome.mp4?{sas_token}"

Versioning and Soft Delete

Enabling versioning creates an immutable snapshot of a blob every time it is overwritten or deleted. The current version is the live blob; previous versions are stored at a small additional cost and can be restored with a single API call.

Soft delete keeps deleted blobs for a retention period (1–365 days) before permanent removal. Versioning and soft delete together provide a strong safety net against accidental deletion and ransomware-style overwrites.

Blob History With Versioning
-----------------------------
v1  (2024-01-10) <- overwritten
v2  (2024-03-15) <- overwritten
v3  (2024-06-01) <- CURRENT


After delete:
v3 moved to soft-deleted state (retained 30 days)
Restore: az storage blob undelete

Storage Redundancy Options

Redundancy  | Copies | Failure Protection          | Notes
------------|--------|-----------------------------|------------------------
LRS         | 3      | Single rack failure          | Cheapest
ZRS         | 3      | Data centre failure          | Recommended for prod
GRS         | 6      | Regional outage (read-only)  | RA-GRS adds read access
GZRS        | 6      | Zone + regional outage       | Best resilience

Key Interview Points

Best Practices