Azure Blob Storage
Azure Fundamentals
Chapter 4 · Azure Blob Storage
AWS Fundamentals Chapter 4 covered S3's own single, fixed 11-nines durability figure. Azure Blob Storage genuinely offers something S3 doesn't: a real, explicit choice of durability level, traded directly against cost and real geographic protection.
Storage Accounts & Containers
Blob data lives inside a real storage account — a top-level Azure resource (belonging to one Resource Group, Chapter 1) — which holds one or more real containers, Azure's own direct equivalent of an S3 bucket. Individual files (blobs) live inside a container, addressed by a real key, just as an S3 object is.
Real Access Tiers
| Tier | Real Availability | Min. Retention | Use Case |
|---|---|---|---|
| Hot | 99.9% | None | Frequently accessed data — the real default |
| Cool | 99% | 30 days | Infrequently accessed, still needs millisecond retrieval |
| Cold | 99% | 90 days | Rarely accessed, still needs fast (millisecond) retrieval |
| Archive | Offline | 180 days | Long-term retention; retrieval takes up to 15 real hours |
| Smart Tier | Varies | N/A | Automatically moves data between Hot/Cool/Cold based on real usage — Azure's own version of S3 Intelligent-Tiering |
Moving a blob out of the Cool, Cold, or Archive tier before its own real minimum retention period elapses triggers a genuine, prorated early-deletion charge — a real, easy-to-miss cost trap when experimenting with tier changes.
A Real Choice of Durability
| Redundancy | Real Durability | What It Protects Against |
|---|---|---|
| LRS | 11 nines | Drive/server/rack failure — one single datacenter only |
| ZRS | 12 nines | An entire datacenter/zone outage — requires a region that supports Availability Zones (Chapter 1's own real gotcha) |
| GRS / RA-GRS | 16 nines | A full regional outage — asynchronously replicated to a paired secondary region |
| GZRS / RA-GZRS | 16 nines | Both a zone outage AND a regional outage together |
A genuinely direct, real consequence of Chapter 1's own AZ-support gotcha: ZRS and GZRS can only be used in Azure regions that actually support Availability Zones. In a region without AZ support, LRS or GRS/RA-GRS are the only real options available.
SAS Tokens
A Shared Access Signature (SAS) is a real, genuinely distinctive Azure Storage concept: a signed URL granting scoped, time-limited access to specific storage resources, without the requester needing an Entra ID identity (Chapter 2) at all. A SAS token can be scoped down to one specific blob, a whole container, or an entire storage account, with real, independently configurable permissions (read, write, delete) and a real expiration time.
A Real, Recent Case Study: The 2023 Microsoft AI Research Leak
This is a real, genuinely distinctive case study compared to Chapter 2 (AWS's Capital One breach) and AWS Fundamentals Chapter 4 (Deep Root Analytics) — the root cause here wasn't a public bucket left open, but a real, overscoped SAS token: correctly using SAS tokens means scoping each one narrowly to exactly the resource it needs, setting a genuinely real expiration date, and monitoring for their creation and use.
Lifecycle Management
A real, rule-based lifecycle management policy automatically moves blobs between access tiers, or deletes them entirely, based on real, defined conditions — for example, "move to Cool after 30 days, Archive after 180, delete after 3 years" — the same real automation concept as an S3 lifecycle policy (AWS Fundamentals Chapter 4).
Static Website Hosting
A storage account can serve its own blobs directly as a real static website — index.html, CSS, and JavaScript served straight from Blob Storage, with no web server to manage — the same real capability S3 offers.
S3 vs. Azure Blob Storage
| Property | AWS S3 | Azure Blob Storage |
|---|---|---|
| Container equivalent | Bucket | Container (inside a Storage Account) |
| Durability | Fixed at 11 nines (Standard) | A real choice — 11, 12, or 16 nines, by redundancy configuration |
| Scoped, time-limited access | Pre-signed URLs / IAM policies | SAS tokens |
| Coldest real tier | Glacier Deep Archive | Archive (up to 15-hour retrieval) |
Hands-On Exercises
A company needs to protect a dataset against both a single zone outage AND a full regional disaster, and the target region does support Availability Zones. Recommend a real redundancy configuration, and explain why the alternatives fall short.
📄 View solutionExplain, in your own words, the specific real mistake that caused the 2023 Microsoft AI research leak - not simply "a token leaked," but what was actually misconfigured about the token itself.
📄 View solutionA blob is moved from the Cool tier to the Hot tier after only 12 days. Explain, in your own words, whether this triggers a real, documented cost consequence, and why.
📄 View solutionChapter 4 Quick Reference
- Storage Account → Container → Blob — Azure's real equivalent of S3's account/bucket/object structure
- Access tiers — Hot, Cool (30-day min), Cold (90-day min), Archive (180-day min, up to 15hr retrieval), Smart Tier
- Real redundancy choice — LRS (11 nines), ZRS (12 nines, needs AZ-supporting region), GRS/RA-GRS & GZRS/RA-GZRS (16 nines)
- SAS tokens — scoped, time-limited access without a full Entra ID identity; scope and expiration matter enormously
- Real case study: the 2023 Microsoft AI research leak (38TB exposed) — an overscoped, effectively-never-expiring SAS token, not a public bucket
- Lifecycle management and static website hosting — the same real capabilities as S3