Azure Blob Storage — Complete Guide

What Is Azure Blob Storage?#

Azure Blob Storage is a massively scalable object storage service for unstructured data — documents, images, videos, logs, backups, and VM disk files. It lives inside an Azure Storage Account and is accessible over HTTP/HTTPS via REST APIs, SDKs, and the Azure portal.

---

Architecture Overview#

Blob Storage is structured in four layers:

Storage Account
└── Blob Service (internal engine)
    └── Containers  (logical buckets — like folders at the top level)
        └── Blobs   (the actual data objects)

---

The Flat Namespace#

Unlike a traditional file system, Blob Storage has no real folders or directory hierarchy. It uses a flat namespace.

What look like folders are simply prefixes embedded in the blob's name:

Container: my-container
Blob name:  images/2026/march/photo1.jpg
                ↑ this is NOT a folder — it is part of the blob name

The Azure portal and Storage Explorer display these prefixes as folders, but the underlying structure is flat — every blob is just a named object inside a container.

---

Types of Blobs#

Azure supports three blob types. Choosing the wrong type is a common mistake.

---

Access Tiers and Cost Optimisation#

Tiers let you balance storage cost against access cost. Higher storage cost = lower access cost, and vice versa.

Tier flexibility#

• Tiers can be set at the storage account level (default) or per blob (overrides the account default)
• You can automate tier transitions with Lifecycle Management (see below)
• Early deletion fees apply if you delete or move a blob before its minimum retention period

---

Data Protection#

Blob Versioning#

When enabled, Azure automatically saves a new version every time a blob is written or overwritten. Each version has a unique version ID.

• Protects against accidental overwrites and deletions
• Old versions can be listed, restored, or deleted individually
• Restoring an old version creates a new copy — it does not revert the current blob in place

Lifecycle Management#

Lifecycle Management lets you define rules that automatically:

• Transition blobs between tiers (e.g., move to Cool after 30 days)
• Delete blobs or old versions after a defined period

// Example: move to Cool after 30 days, Archive after 90 days, delete after 365 days
{
  "rules": [{
    "name": "cost-optimise",
    "enabled": true,
    "definition": {
      "actions": {
        "baseBlob": {
          "tierToCool":    { "daysAfterModificationGreaterThan": 30  },
          "tierToArchive": { "daysAfterModificationGreaterThan": 90  },
          "delete":        { "daysAfterModificationGreaterThan": 365 }
        }
      },
      "filters": { "blobTypes": ["blockBlob"] }
    }
  }]
}

---

Security and Access#

Authentication Options#

Blob Endpoint Format#

Every blob has a predictable, publicly routable URL:

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

Example:
https://mystorageaccount.blob.core.windows.net/images/photos/beach.jpg

Access to this URL is controlled by the container's access level and/or a SAS token appended to the URL.

---

Common Interview Questions#

Q: What is the difference between Block, Append, and Page blobs? Block blobs are for general-purpose file storage (images, videos, backups). Append blobs only allow writes to the end — ideal for logs. Page blobs support random read/write and are used internally by Azure VM disks.

Q: A blob in Archive tier needs to be read urgently. What do you do? You must rehydrate it — copy or move it to Hot or Cool tier first. This can take up to 15 hours for standard priority, or a few hours for high priority rehydration. There is no way to read directly from Archive.

Q: What happens if you delete a blob before its minimum retention period ends? Early deletion charges apply. For example, deleting a Cool tier blob after 10 days still incurs the 30-day minimum storage charge.

Q: How do you give a third-party vendor read access to a specific container for 24 hours without exposing your Access Keys? Generate a Shared Access Signature (SAS) scoped to the container with read permissions and an expiry set to 24 hours from now. Share only the SAS URL.

---

Common Mistakes#

• Storing VM disks as Block Blobs — VM disks must be Page Blobs (or use Azure Managed Disks)
• Assuming Archive tier is immediately accessible — it requires rehydration, which takes hours
• Setting tier at account level and not per-blob — per-blob tier overrides the account default; mixing tiers in one account is valid and common
• Treating the flat namespace as a file system — you cannot apply RBAC or SAS permissions to a "virtual folder" prefix
• Restoring an old version and expecting it to replace the current — promotion creates a new version, not an in-place revert
• Leaving Access Keys long-lived without rotation — use Entra ID + Managed Identity where possible; rotate keys on a schedule if keys must be used

---

What to Learn Next#

1. Configuring Blob Lifecycle Management — automate tier transitions and deletions with policy rules
2. Configuring Object Replication — geo-replicate blobs across storage accounts
3. Securing Storage Accounts — network rules, private endpoints, SAS best practices
4. Azure Files — SMB/NFS file shares as an alternative to blob for file-system workloads