Complete guide to Azure Blob Storage: block/append/page blobs, the 4-tier model (Cold tier included), cost traps, Archive rehydration, and security best practices.
Azure Blob Storage Explained: Complete Beginner-to-Advanced Guide
Most explanations of Blob Storage stop at "Hot, Cool, and Archive" — a three-tier model that's been out of date since 2023. A fourth tier sits between Cool and Archive, and the actual cost traps that catch teams aren't in choosing the wrong tier — they're in the specific minimum-duration and minimum-billable-size rules almost nobody reads until the bill arrives.
Azure Blob Storage is genuinely simple at its core — massively scalable object storage for unstructured data, the same category of service as Amazon S3 — and genuinely easy to get wrong in the specific details that determine your actual bill and your actual security posture. This guide starts from the fundamentals (what a blob actually is, the three distinct blob types, how storage accounts and performance tiers relate) and builds toward the details that separate a functioning storage account from a well-run one: the real, current structure of access tiers, the specific cost rules that catch people who tier data without reading the fine print, why Archive isn't simply "the slow tier," and the security defaults worth confirming rather than assuming.
Blob Storage is Azure's object storage service for unstructured data — images, video, log files, backups, documents, and any data that doesn't fit a structured database model. Underneath that single service name, there are three distinct blob types, each optimized for a different write pattern.
| Blob type | Optimized for |
|---|---|
| Block blob | Uploading large amounts of data efficiently — composed of individually-managed blocks, the default and by far most common type for general file storage |
| Append blob | Append-only operations — data can only be added to the end, never modified or removed from the middle — the natural fit for logging scenarios |
| Page blob | Random read/write access to fixed-size pages — the foundation underlying Azure VM disks specifically |
Unless building a logging pipeline that specifically needs append-only writes, or working directly with VM disk infrastructure, block blobs are the correct default and cover the overwhelming majority of real-world Blob Storage use cases — uploading files, serving static assets, storing backups, and general application data all use block blobs without needing to think about the other two types at all.
Every blob lives inside a storage account, and the account's performance tier is a separate decision from the access tier covered in Section 3 — worth keeping these two concepts distinct.
| Performance tier | Detail |
|---|---|
| Standard | HDD-based, the correct default for the vast majority of workloads, supports all four access tiers |
| Premium Block Blob | SSD-based, 1-3ms latency, several to 10x the cost of Standard, Hot tier only — no Cool, Cold, or Archive support at all |
Premium Block Blob genuinely earns its cost premium for high-volume small-file read/write patterns — machine learning datasets with heavy random access, log aggregation pipelines, high-frequency API-based access patterns, and high-performance AKS persistent volume requirements. Outside of a workload with a clear, measured low-latency requirement, Standard performance tier is the correct, cost-appropriate choice, and reaching for Premium by default is a common, avoidable cost inflation.
Restating Figure 1's point with the operational detail behind it — the tier structure directly shapes how data should actually be classified and managed.
| Tier | Best suited for |
|---|---|
| Hot | Data accessed multiple times per month — active application data, current working files |
| Cool | Data accessed infrequently, retained at least 30 days — short-term backups, recent but inactive data |
| Cold | Data accessed rarely, retained at least 90 days — the gap between "occasional backup" and "long-term archive" |
| Archive | Data essentially never accessed, retained at least 180 days — long-term compliance retention, raw source data kept for provenance |
These two rules together are the single most common source of unexpected Blob Storage cost surprises — worth understanding precisely before designing a tiering strategy.
| Rule | Detail |
|---|---|
| Minimum storage duration | Cool (30 days), Cold (90 days), Archive (180 days) — moving, deleting, or overwriting a blob before this period elapses triggers a prorated early-deletion fee for the remaining days |
| Minimum billable object size | 128 KiB applies to every object in Cool, Cold, and Archive — a file smaller than 128 KiB is still billed as if it were exactly that size |
| Hot tier exception | Neither rule applies to Hot — no minimum duration, no minimum billable size floor |
A lifecycle policy that aggressively moves large numbers of small files (log fragments, thumbnails, small JSON documents) into Cool, Cold, or Archive can end up costing more than leaving them in Hot, specifically because each individual small file is billed at the 128 KiB floor regardless of its actual size — the storage cost savings per byte in a colder tier can be entirely offset, or worse, by billing many small files as if each one were 128 KiB. Before applying an aggressive tiering policy, check the actual size distribution of the target data, not just its access frequency.
The early-deletion fee isn't limited to literally deleting a blob before its tier's minimum duration — rewriting the entire object through any operation (a new upload, a Put Block List, or a Copy Blob) within that window triggers the same prorated charge, since the platform treats a full overwrite the same as an early deletion of the original object. This is worth knowing for any workflow that periodically replaces files in place rather than genuinely appending or versioning them.
Restating Figure 2's core point directly, since it's a genuinely common source of confusion for anyone new to the Archive tier.
| Constraint | Detail |
|---|---|
| Cannot set an entire account to Archive | Archive is only ever set at the individual blob level, never as an account-wide default |
| No direct read operations | Any attempt to read an Archive-tier blob without first rehydrating it fails outright |
| Rehydration is itself a tier change | The blob moves to Hot, Cool, or Cold — it doesn't get "temporarily unlocked" while staying in Archive |
If Archive tier is part of a compliance retention strategy or a disaster-recovery plan, the realistic retrieval time — hours, not seconds or minutes — needs to be an explicit, documented part of that plan's recovery time objective. A DR runbook that assumes archived backup data is available within minutes will fail its own assumptions the first time it's actually exercised against real Archive-tier data.
Redundancy options and access tiers interact in a way that's easy to overlook until it becomes a real operational blocker.
| Redundancy option | Protects against |
|---|---|
| LRS (Locally Redundant Storage) | A single datacenter failure — lowest cost, no geographic protection |
| ZRS (Zone-Redundant Storage) | A single availability zone failure within a region |
| GRS (Geo-Redundant Storage) | An entire region failure — data replicated to a paired region |
| RA-GRS / GZRS / RA-GZRS | Region failure plus, for the RA variants, read access to the secondary region directly |
To change a storage account's redundancy configuration — moving from LRS to GRS, for instance — while that account contains any blobs in the Archive tier, every one of those archived blobs must be rehydrated first. Microsoft's own guidance explicitly recommends avoiding redundancy configuration changes on accounts containing archived data specifically because this rehydration requirement can be genuinely costly and time-consuming at scale. Plan redundancy configuration deliberately before archiving large volumes of data, since changing course later carries real cost.
Migrating a storage account from LRS to GRS is supported specifically as long as no blobs were ever moved to the Archive tier while the account was configured for LRS — if any blob was archived during the LRS period, this straightforward migration path isn't available, and the redundancy change requires the full rehydrate-first process described above. Worth checking this history before assuming a simple redundancy upgrade is possible on an account with any archival activity in its past.
A concrete set of current, recommended security controls for a production storage account.
| Control | Recommendation |
|---|---|
| Public blob access | Disable at the storage account level (Allow Blob Anonymous Access = false) — access only via authenticated methods or Private Endpoint |
| Primary authentication method | Microsoft Entra ID with Azure RBAC roles like Storage Blob Data Contributor — reserve storage account keys for genuine emergencies only |
| SAS tokens, when needed | Prefer User Delegation SAS (backed by Entra ID) over Account SAS or Service SAS, which rely on the storage account key directly — always set an explicit expiration |
| Network access | Restrict to selected networks plus Private Endpoint rather than allowing all networks by default |
| Data protection | Enable versioning and soft delete as protection against both accidental and malicious deletion |
A User Delegation SAS token is secured with Entra ID credentials rather than the storage account key, meaning it can be scoped to a specific security principal's actual permissions and revoked by removing that principal's access — an Account SAS or Service SAS, by contrast, is tied directly to the account key itself, meaning anyone holding that token has whatever access the token grants until it expires, with no way to revoke it individually short of rotating the entire account key. For any SAS token generation in a production system, User Delegation SAS is the correct default, not just a nice-to-have upgrade.
Lifecycle management policies automate tier transitions and deletion based on blob age, removing the need to manually manage tiering at scale.
| Detail | Value |
|---|---|
| Policy format | JSON, applied at the storage account level or scoped to a specific blob prefix |
| Execution schedule | Runs once daily, processing blobs asynchronously |
| Time to take effect | 24-48 hours after a blob first meets the policy's condition — not instant |
| Trigger basis | Days since last modification by default, or days since last access if Last Accessed Tracking is enabled |
A lifecycle policy that moves data through tiers faster than each tier's minimum storage duration effectively guarantees early-deletion fees on every transition — setting Cool-to-Cold at 45 days after the Cool transition, for instance, comfortably clears Cool's 30-day minimum, while a more aggressive 20-day transition would not. Design lifecycle thresholds with the minimum duration rules in mind explicitly, not as a separate, unrelated consideration.
-
Create a Standard general-purpose v2 storage account, unless a confirmed low-latency requirement justifies Premium Block Blob
Standard is the correct default for the large majority of workloads, per Section 2.
-
Disable anonymous public blob access at the account level
Set Allow Blob Anonymous Access to false explicitly — don't rely on it defaulting correctly without verification.
-
Configure Microsoft Entra ID authentication with appropriately scoped RBAC roles
Assign roles like Storage Blob Data Contributor or Storage Blob Data Reader based on actual need, per Section 7.
-
Restrict network access to selected networks plus a Private Endpoint
Avoid leaving the account open to all networks by default.
-
Enable versioning and soft delete
Protects against both accidental overwrites and deletions, and malicious deletion attempts.
-
Classify data by actual access pattern before designing a tiering strategy
Check the size distribution of data being considered for Cool/Cold/Archive against the 128 KiB minimum billable size from Section 4 before committing to an aggressive tiering policy.
-
Design and apply a lifecycle management policy with thresholds that respect each tier's minimum duration
Cross-check transition timing against Section 4's minimum duration rules, per Section 8's guidance.
-
Choose a redundancy configuration deliberately before any data reaches the Archive tier
Changing redundancy later on an account with archived data requires rehydrating everything first, per Section 6 — get this decision right upfront where possible.
-
If SAS tokens are needed for any workflow, default to User Delegation SAS with an explicit expiration
Avoid Account SAS or Service SAS tokens tied to the account key unless there's a specific reason they're required.
| Anti-pattern | Why it feels right | Why it isn't |
|---|---|---|
| Designing a tiering strategy around only Hot, Cool, and Archive | "That's the model everyone talks about" | Cold tier, added in 2023, often fits the gap between infrequent-but-soon and long-term-archive better than either neighbor |
| Aggressively tiering large volumes of small files to save on storage cost | "Colder tier, lower cost per GB" | The 128 KiB minimum billable size can make tiering many small files a net loss, not a savings — check size distribution first |
| Assuming Archive data is retrievable within minutes for a DR plan | "It's still in Azure, should be fast" | Archive requires explicit rehydration, typically hours even at high priority — build this delay into any real recovery time objective |
| Changing a storage account's redundancy configuration without checking for archived blobs first | "Redundancy and access tier are unrelated settings" | Any archived blob must be rehydrated before a redundancy change can proceed — a real, often-costly prerequisite |
| Using Account SAS or Service SAS tokens as the default for application access | "SAS tokens are SAS tokens" | User Delegation SAS, backed by Entra ID, is individually revocable and more securely scoped — the correct default for production systems |
| Leaving anonymous public blob access enabled because it was the historical default | "Never had a reason to change it" | Disabling public access explicitly is a current, standard security control worth confirming directly rather than assuming |
Key Takeaways
Frequently Asked Questions
Related FAVORZENITH Articles
- Design the Best Azure Shared File System for Multiple VMs: Azure Files, Azure NetApp Files, and Storage Options
- Understand Azure RBAC Roles and How to Assign Them to Users
- Azure Storage Queues vs Azure Service Bus Queues: Messaging Differences, Patterns, and Use Cases
- Reduce Azure Cost by Implementing Automated Shutdown and Start of VMs