Azure Blob Access Tiers: Hot, Cool, Cold, and Archive
Access tiers are Blob Storage's main cost lever: the same data, stored at a different price, with a different price for reading it back. The trade is simple enough, the colder the tier, the less you pay per gigabyte per month and the more you pay per read. But the details that actually cost money are the minimum retention periods, the early deletion charges, and one redundancy constraint that can invalidate an entire design.
Tiers apply to block blobs only. You can't set a tier on an append or page blob. Azure Files has its own tiering model that works differently.
The four tiers
| Hot | Cool | Cold | Archive | |
|---|---|---|---|---|
| Availability | 99.9% | 99% | 99% | 99% |
| Availability (RA-GRS reads) | 99.99% | 99.9% | 99.9% | 99.9% |
| Latency (time to first byte) | Milliseconds | Milliseconds | Milliseconds | Hours |
| Minimum retention | — | 30 days | 90 days | 180 days |
| Supported redundancy | All | All | All | LRS, GRS, RA-GRS only |
Hot is optimised for data in active use: frequent reads and writes, data actively being processed. It has the highest storage cost and the lowest access cost. New storage accounts default to it.
Cool is for large amounts of infrequently used data intended to stay put for at least 30 days: short-term backup and disaster recovery sets, older media content. It's immediately available, but reads cost more than in Hot.
Cold is the same idea one step further down, for data staying at least 90 days that still needs fast retrieval.
Archive is an offline tier. Data in it can't be read or modified at all. Storage is the cheapest available and retrieval is the most expensive and the slowest — rehydrating a blob to an online tier takes up to 15 hours, depending on the priority chosen. It suits secondary backups, original raw data, and compliance archives.
The two Archive constraints
Archive isn't simply "one tier colder", and two of its restrictions have architectural consequences:
It's supported only on LRS, GRS, and RA-GRS accounts — not ZRS, GZRS, or RA-GZRS. If a workload needs zone redundancy and archival storage, those requirements conflict at the account level and one of them has to give. Changing the redundancy configuration of an account containing archived blobs means rehydrating all of them first, which is slow and expensive enough that Microsoft recommends avoiding it entirely.
It can't be an account's default access tier. The default can be Hot, Cool, or Cold only.
While a blob is in Archive, its metadata stays readable. You can list the blob and read its properties, metadata, and index tags. Metadata is read-only, index tags can still be written, and metadata storage is billed at Cool rates. Snapshots aren't supported for archived blobs.
Minimum retention and early deletion
Cool, Cold, and Archive carry minimum storage durations of 30, 90, and 180 days. Deleting, overwriting, or re-tiering a blob before that period elapses triggers an early deletion charge and the charge is prorated for the remainder of the period, not a flat penalty.
- A blob moved to Cool and deleted after 21 days is charged the equivalent of 9 days' Cool storage.
- An archived blob deleted after 120 days is billed as though it were stored for 180.
Early deletion charges also apply when the entire object is rewritten by Put Blob, Put Block List, or Copy Blob within the window, not just on an explicit delete.
Where soft delete is enabled, a deleted blob is only soft-deleted until its retention expires, and isn't subject to the early deletion penalty until then.
Smart tier
Azure also offers a Smart tier, which moves data between Hot, Cool, and Cold automatically based on observed usage patterns rather than rules you write. It's worth evaluating as an alternative to hand-maintaining lifecycle policies, particularly where access patterns are genuinely unpredictable and any rule you write would be a guess.
The default account access tier
Storage accounts have a default access tier setting that determines which online tier a new blob lands in. A blob without an explicitly assigned tier inherits it, and the portal shows this as Hot (inferred), Cool (inferred), or Cold (inferred).
Changing that default has a billing consequence that's easy to trip over. Toggling to a cooler tier charges write operations for every blob whose tier is inferred. Toggling to a warmer tier charges both read operations and data retrieval per GB. On an account with a lot of inferred blobs, flipping the default is not a free administrative change.
Moving a blob between tiers
Two mechanisms:
Set Blob Tier, directly or via a lifecycle management policy. Best when moving from a warmer tier to a cooler one.Copy Blob, recommended for rehydrating out of Archive or moving from Cool or Cold to Hot. Copying avoids the early deletion penalty when the source blob's minimum interval hasn't elapsed — at the cost of paying capacity charges for two blobs until the source is removed.
Moving to a cooler tier is instantaneous, as is moving from Cool or Cold to Hot. Only rehydration from Archive takes hours.
Two limits to plan around:
- A blob using an encryption scope can't be archived with
Set Blob Tier, only moved between online tiers. - Data in a premium block blob account can't be tiered at all. Moving it means synchronously copying the blobs to the Hot tier of a different account using the
Put Block From URLAPI, or a version of AzCopy that supports it.
Automating movement between tiers on a schedule is the job of lifecycle management rules, which have enough mechanics of their own to warrant a separate treatment. This is covered in the post on blob lifecycle management.