A new project is choosing between Blob Storage's Hot, Cool, Cold, and Archive tiers for its data. How would you actually decide, and what's the risk of getting it wrong?
Short Answer
Choose based on how often the data is actually accessed and how quickly it needs to be available, not just on which tier is cheapest to store in — Hot suits frequently-accessed data, Cool and Cold suit infrequently-accessed data with progressively longer minimum retention expectations, and Archive suits data that's rarely if ever accessed and can tolerate a multi-hour retrieval delay. Picking a colder tier than the access pattern actually warrants trades a lower storage price for real retrieval and early-deletion costs that can end up more expensive overall.
Detailed Explanation
Each tier has a genuinely different combination of storage cost, access/transaction cost, and — for Cool, Cold, and Archive — an early-deletion penalty if data is removed or moved before a minimum retention period. The mistake isn't picking a cold tier; it's picking one without accounting for those other costs.
Hot tier is priced for frequent access: low access cost, higher storage cost. It's the right default for actively-used data — application assets, logs still being queried, anything read or written regularly.
Cool and Cold tiers trade lower storage cost for higher per-access cost and a minimum retention period (30 days for Cool, 90 days for Cold) — moving or deleting data before that window ends incurs an early-deletion charge as if it had been stored for the full minimum period. These fit data accessed occasionally but not routinely, like older logs kept for compliance or infrequently-viewed media.
Archive tier is the cheapest to store in by far, but data isn't immediately readable — it must be explicitly rehydrated first, which can take hours depending on the rehydration priority chosen, and it carries the longest minimum retention period (180 days). It fits data that's genuinely rarely accessed and where an access delay of hours is acceptable — not data someone might need back "soon" without a clear plan for that.
Lifecycle management policies can automate tier transitions based on age or last-access time, which is usually a better fit than manually choosing a tier upfront for data whose access pattern will predictably cool over time — but the same early-deletion and rehydration costs apply regardless of whether the transition was manual or automated.
Interview Follow-Up Questions
- How would you design a lifecycle policy that avoids accidentally archiving data someone still needs occasional access to?
- What would you monitor to catch a lifecycle policy that's moving data to a colder tier faster than the actual access pattern supports?
- How would you communicate the rehydration delay trade-off to a team that wants to use Archive tier for "just in case we need it" data?
Key Takeaways
- Tier choice should follow actual access frequency and acceptable retrieval latency, not storage price alone — Cool/Cold/Archive all have real costs beyond storage that only show up on access or early deletion.
- Cool, Cold, and Archive each carry a minimum retention period; deleting or moving data out early triggers an early-deletion charge equivalent to the full minimum period.
- Archive tier requires an explicit, hours-long rehydration before data is readable again — it's not simply "slower to open," it's genuinely unavailable until rehydrated.
- Lifecycle management policies are usually the right way to apply tiering as data ages, rather than committing to a single tier at upload time.
References
Last updated August 25, 2026 · Last reviewed August 25, 2026