Academmia

Azure Blob Storage access tiers: Hot, Cool, Cold, and Archive

az-900•mixed•

Azure architecture and services

Azure Blob Storage access tiers: Hot, Cool, Cold, and Archive

Short Summary

Access tiers in Azure Blob Storage help me control cost by matching storage to how often I read the data. Hot, Cool, and Cold are “online” tiers (immediate access), while Archive is “offline” and typically requires rehydration before I can read the data. The key is balancing storage price with transaction, retrieval, and early deletion costs.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define what an Azure Blob Storage access tier is and what it optimizes for.
  • Compare Hot, Cool, Cold, and Archive using access frequency and retrieval expectations.
  • Explain what “online vs. offline” means and what rehydration is for Archive.
  • Anticipate cost gotchas such as retrieval charges and minimum retention / early deletion penalties.
  • Distinguish access tiers from redundancy options like Locally Redundant Storage (LRS) and Geo-Redundant Storage (GRS).

Core Concepts

An access tier in Azure Blob Storage is a billing and behavior setting that optimizes for a specific access pattern. As a rule of thumb:

  • Warmer tier (Hot) → higher storage cost, lower access/transaction cost.
  • Cooler tier (Cool/Cold) → lower storage cost, higher access/transaction cost.
  • Archive → lowest storage cost, but “offline” behavior and the highest retrieval considerations.

Online tiers vs. Archive (offline)

Online tiers (Hot, Cool, Cold) are designed for immediate access. The time to first byte is typically in milliseconds for online tiers.

Archive is an offline tier. In practice, that means:

  • I can list metadata and see the blob exists, but I can’t read the blob’s content until it’s brought back online.
  • Bringing it back online is called rehydration, and it can take time (often measured in hours). Faster rehydration options exist but cost more.

The “total cost” is more than storage per GB

When I pick a tier, I’m not only choosing “storage per GB per month.” I’m also choosing a cost profile for:

  • Read/write transactions (operations)
  • Data retrieval charges (especially for cooler tiers)
  • Rehydration / retrieval behavior (Archive)
  • Early deletion penalties if I delete, overwrite, or move a blob out of certain tiers before their minimum period

A useful mental model (borrowed from Martin Fowler’s “optimize for humans” mindset) is: I pick a tier that my future self can explain during a cost review, not the one that only looks cheap on paper.

Minimum retention and early deletion charges

For many common setups (for example, general-purpose v2 storage accounts), Microsoft lists early deletion periods such as:

  • Cool: 30 days
  • Cold: 90 days
  • Archive: 180 days

If I delete, overwrite, or move the blob to another tier before that window ends, I may get an early deletion charge. Details can vary by account type and should be confirmed with the current pricing page for my scenario.

Access tiers vs. redundancy (LRS/GRS)

Access tiers answer: “How often do I touch this data, and what should it cost when I do?”

Redundancy answers: “How many copies exist and where are they stored for durability/availability?”

So:

  • Hot/Cool/Cold/Archive = cost + access pattern
  • LRS/GRS = copy placement for resiliency

Practical Understanding

Practical Situation 1: Daily logs that must open instantly

I store application logs that my team reads every day for troubleshooting. The logs must be available immediately.

How to think about it: Frequent reads are a Hot pattern. Hot usually keeps access and transaction costs down for active data.

Common misunderstanding: “Cool is cheaper, so it must be better.” Lower storage per GB can backfire if I read the data often, because access and transaction costs can dominate.

Practical Situation 2: Backups I restore a few times per month

I store backups that I retrieve a few times per month for restore tests. I need immediate availability, but I don’t want Hot pricing.

How to think about it: This is “infrequent but online,” which is what Cool is designed for.

Common misunderstanding: “Archive is for backups.” Archive can be great for long-term backup retention, but it’s a poor match for “I need it right now” restore tests.

Practical Situation 3: Compliance data kept for years, accessed once a year

I keep compliance data for 7 years. Access is rare, and waiting hours for retrieval is acceptable. I want the lowest storage cost.

How to think about it: This is a classic Archive use case: long retention + very rare access + flexible retrieval time. If I need quicker access for “recent history,” I might keep the newest slice in an online tier and transition older data to Archive.

Common misunderstanding: “Archive is just slower Cold.” Archive is offline behavior, which is a bigger shift than “slower.”

Practical Situation 4: I moved data to Cool, then realized I need it frequently again

I moved a dataset to Cool to reduce storage cost, but a month later the application started reading it often.

How to think about it: Frequent reads typically push me back toward Hot. I also remember that moving too soon can trigger early deletion penalties (depending on account type and timing).

Common misunderstanding: “Tiers are only about where data lives.” Tiers are primarily about billing and retrieval behavior; changing tiers is a cost decision as much as a technical one.

Common Pitfalls

  • Mistake: Picking a tier based only on “storage per GB” and ignoring reads/writes. Correction: Compare the total cost (storage + transactions + retrieval + rehydration behavior).

  • Mistake: Using Archive for active workloads. Correction: Archive is for rarely accessed data with hours-level retrieval expectations; use an online tier when you need immediate reads.

  • Mistake: Ignoring minimum retention / early deletion penalties on cooler tiers. Correction: Plan tier transitions with minimum periods in mind to avoid surprise charges.

  • Mistake: Confusing access tiers with redundancy options (for example, “Hot vs. LRS”). Correction: Use tiers for access pattern and cost; use redundancy for durability/availability via copy placement.

  • Mistake: Treating “Cold” as “offline.” Correction: Cold is still an online tier (immediate access); Archive is the offline tier that typically requires rehydration to read.

  • Mistake: Assuming the same tier behavior applies everywhere without checking account specifics. Correction: Confirm the current documentation and pricing notes for your storage account type and region.

Check Your Understanding

  1. Take three datasets: one accessed daily, one accessed monthly, one accessed yearly. Which tier would you pick for each, and what is the main reason?
  2. Explain in your own words the difference between an access tier and a redundancy option like Locally Redundant Storage (LRS).
  3. What does “online tier” mean in terms of user expectations and retrieval steps?
  4. What questions should I ask before picking a tier (think: frequency, urgency, and how long it stays in that tier)?
  5. If an audit request arrives and the data is in Archive, what should I communicate about expected retrieval behavior and time?

Further Reading