3.1.2.2. Design for Azure Blob Storage
3.1.2.2. Design for Azure Blob Storage
💡 First Principle: A massively scalable, highly durable, and cost-effective object storage service is the foundational platform for storing and managing vast amounts of unstructured data in the cloud.
Access tiers as a cost-versus-latency spectrum:
Storage cost falls left to right while access cost and latency rise — so the tier follows the read pattern, not the age of the data. Two properties decide most exam items: each cooler tier carries an early deletion penalty if you move data out before its minimum, and Archive is offline, so a blob must be rehydrated over hours before it can be read at all. Any requirement mentioning immediate access rules Archive out no matter how cold the data is.
Scenario: You are designing a data storage solution for a content management system. It will store user-uploaded images and videos that are frequently accessed initially but become less popular over time. You also need to retain these files for 10 years for compliance reasons at the lowest possible cost, and ensure they are resilient to regional disasters.
Azure Blob Storage is Microsoft’s object storage solution for storing large amounts of unstructured data.
Key Design Considerations:
- Access Tiers:
- Data Redundancy:
- LRS (Locally Redundant Storage): Replicates data within a single datacenter.
- ZRS (Zone-Redundant Storage): Replicates across 3 datacenters in a region.
- GRS (Geo-Redundant Storage): Replicates to a secondary Region for disaster recovery.
- RA-GRS (Read-Access GRS): Adds read access to the secondary Region for GRS.
- Security:
- Use Shared Access Signatures (SAS) for scoped, time-limited access.
- Integrate with Microsoft Entra ID for identity-based controls.
- Data is encrypted at rest by default.
Design decisions in practice:
| Decision | Guidance |
|---|---|
| Access tier | Follows the READ pattern, not the age of the data: Hot for frequent, Cool (30-day minimum), Cold (90-day minimum), Archive (180-day minimum, and OFFLINE) |
| Redundancy | LRS within one datacenter, ZRS across zones in one region, GRS/GZRS to a paired region. The RA- prefix is what makes the secondary readable before a failover |
| Immutability | A time-based retention policy, once locked, binds even a subscription owner. This is the control a regulator means, as distinct from soft delete which only aids recovery |
| Protection against mistakes | Soft delete restores within a window, versioning preserves prior states, and a lock stops the account being deleted. None of them prevents the change happening |
Two costs bite in scenarios and are easy to miss. Each cooler tier carries an early deletion penalty if data leaves before its minimum, so aggressive tiering on data that turns out to be read can cost more than leaving it Hot. And Archive is offline — rehydration takes hours, so any requirement mentioning immediate or millisecond access eliminates it regardless of how cold the data is.
⚠️ Exam Trap: lifecycle management moves blobs between tiers on age. It is not a backup, it is not replication, and it cannot move data between accounts — that is object replication, a different feature entirely.
⚠️ Common Pitfall: Ignoring retrieval costs. Moving data to a cheaper storage tier like Archive saves on storage costs, but frequent retrieval can make it more expensive overall than keeping it in the Cool tier due to higher per-GB retrieval fees.
Key Trade-Offs:
- Storage Cost vs. Retrieval Cost/Time: Lower storage costs (e.g., Archive tier) come with higher retrieval costs and longer retrieval times (hours).
Reflection Question: How does designing for Azure Blob Storage, by leveraging its access tiers (Hot, Cool, Archive) and data redundancy options (e.g., GRS), fundamentally enable highly available, durable, and massively scalable object storage for unstructured data, optimizing for cost and compliance across diverse workloads?
