AZ-104 · Implement and manage storage · Updated August 7, 2026
Azure Blob Storage Access Tiers Compared: Hot, Cool, Cold, and Archive
Azure Blob Storage doesn’t charge one flat rate for every byte you store. It offers four access tiers, Hot, Cool, Cold, and Archive, and each trades storage price against access price and retrieval speed. Data you touch constantly belongs in a different tier than a compliance archive you must keep for seven years and will probably never open. Picking the wrong tier doesn’t just waste money, it can trigger early deletion penalties or leave you waiting hours for data a support ticket needed in minutes. Knowing what each tier assumes about your access pattern, and how automation keeps blobs moving between tiers without manual work, is core to the AZ-104 storage domain.
What each tier optimizes for
Hot is the default tier for a new general-purpose v2 storage account. It carries the highest per-gigabyte storage cost but the lowest cost to read and write, which makes it the right home for data in active use: application data being read and written constantly, or content staged for processing before it moves somewhere cooler.
Cool targets data that’s accessed infrequently but still needs to be online and readable immediately. Storage costs drop compared to Hot, but access and transaction charges rise. Microsoft recommends storing data in Cool for a minimum of 30 days. Short-term backups and older datasets that still need occasional, immediate access are typical Cool workloads.
Cold sits a step below Cool. It costs less to store than Cool but more to access, and Microsoft recommends a minimum retention of 90 days. Cold is for data you rarely touch but that still must come back in milliseconds when you do, which is the detail that separates it from Archive.
Archive is the only offline tier. It has the lowest storage cost of the four by a wide margin, but the highest access cost, and retrieval isn’t instant, it’s measured in hours. Microsoft recommends a minimum retention of 180 days. Archive fits long-term backups, raw source data kept after processing, and compliance records that are almost never opened.
All four tiers deliver the same durability regardless of which one you pick; only availability, access cost, and retrieval latency change as you move down the list. Access tiers apply to block blobs, not to Azure Files shares, which use a separate tiering model.
Minimum retention periods and early deletion charges
Deleting, overwriting, or moving a blob to a different tier before its minimum retention period elapses triggers a prorated early deletion charge, billed as if the blob had stayed in that tier for the rest of the minimum window. For example, a blob moved to Cool and deleted after 21 days is billed for the remaining 9 days of the 30-day minimum. A blob archived and then deleted after 45 days is billed for the remaining 135 days of the 180-day minimum.
| Tier | Minimum recommended retention | Early deletion charge applies if moved/deleted before |
|---|---|---|
| Hot | N/A | N/A |
| Cool | 30 days | 30 days elapse |
| Cold | 90 days | 90 days elapse |
| Archive | 180 days | 180 days elapse |
Note that in general-purpose v2 accounts these minimums are enforced with a fee; in legacy Blob Storage accounts, the Cool and Cold minimums don’t apply. Soft-deleted blobs don’t accrue the early deletion penalty until the soft-delete retention period itself expires.
Rehydrating a blob out of the Archive tier
Archive is offline, which means a blob sitting there can’t be read, downloaded, or modified until it’s rehydrated back to an online tier (Hot, Cool, or Cold). You choose the rehydration priority when you initiate the operation:
- Standard priority processes requests in the order received and can take up to 15 hours for a blob under 10 GB.
- High priority jumps the standard queue and can complete in under an hour for a blob under 10 GB, though it costs more and isn’t guaranteed if demand is high.
Both figures assume a single blob under 10 GB. The account-level throughput cap for priority rehydration is 10 GiB per hour, shared across every blob being rehydrated in the account at once, not per blob. Bulk rehydration doesn’t scale linearly with the per-blob estimates: restoring hundreds of gigabytes takes proportionally longer no matter which priority you choose, so batch requests and monitor account-level activity for any large-scale restore.
You can rehydrate two ways: call Set Blob Tier to change the archived blob’s tier directly, or call Copy Blob to copy it into a new blob in an online tier while leaving the archived original untouched. Copying avoids the early deletion fee if the 180-day minimum hasn’t elapsed, and it sidesteps a trap: if a lifecycle policy is still active and the blob’s last-modified timestamp is old enough, the policy can archive the rehydrated blob right back down unless you’ve added a daysAfterLastTierChangeGreaterThan condition to the rule.
Automating tiering with lifecycle management policies
Manually moving thousands of blobs between tiers as they age isn’t realistic, which is why Blob Storage lifecycle management exists. A policy is a JSON document made of rules, and each rule combines:
- Filters that scope the rule to a subset of blobs, using up to 10 name prefixes and up to 10 blob index tag conditions per rule (filters can only include blobs, never exclude them).
- Conditions based on Creation Time, Last Modified Time, or Last Accessed Time (if access-time tracking is enabled).
- Actions, such as moving a blob to Cool, Cold, or Archive, or deleting it once it meets the condition.
A newly created or edited policy can take up to 24 hours before its first run starts, then runs periodically after that. The policy itself is free; you’re only billed for the standard Set Blob Tier operations it triggers, and delete actions are free. Remember for the exam: a lifecycle policy can move a blob into Archive, but it can never rehydrate one back out. Bringing an archived blob back online always requires an explicit Set Blob Tier or Copy Blob call.
Summary of the four tiers
| Hot | Cool | Cold | Archive | |
|---|---|---|---|---|
| Availability | 99.9% | 99% | 99% | 99% |
| Storage cost | Highest | Lower | Lower still | Lowest |
| Access/transaction cost | Lowest | Higher | Higher | Highest |
| Minimum retention | N/A | 30 days | 90 days | 180 days |
| Retrieval latency | Milliseconds | Milliseconds | Milliseconds | Hours |
| Redundancy support | All options | All options | All options | LRS, GRS, RA-GRS only |
That last row matters: Archive isn’t supported on zone-redundant configurations (ZRS, GZRS, RA-GZRS), only on LRS, GRS, and RA-GRS. A scenario asking for both zone redundancy and archival cost is describing an unsupported combination, so know the redundancy options cold before layering access tiers on top.
How the AZ-104 exam tests this
- Matching a described access pattern to a tier. “Data is read constantly,” “data is backed up but rarely opened, still needs to be available immediately,” and “data must be retained for compliance and is almost never accessed” map to Hot, Cool or Cold, and Archive respectively. “Rarely accessed but needs fast retrieval” is the specific signal for Cold over Archive.
- Rehydration timing and priority questions. A scenario needing an archived blob restored urgently points to high-priority rehydration, while a bulk restore of a large dataset tests whether you know the 10 GiB/hour account-level cap and non-linear scaling for bulk jobs.
- Early deletion fee calculations. A stem gives you a tier, a day count, and asks what happens if the blob is deleted or moved early. Know the proration logic: you’re billed for the remaining days of the tier’s minimum retention window.
- Lifecycle management rule structure. Questions may ask which combination of filters, conditions, and actions a policy needs, or point out that a policy can tier a blob into Archive but can never be the mechanism that brings it back out.
- Redundancy and archive tier conflicts. A scenario that requires both zone-redundant storage and the Archive tier on the same account is testing whether you know that combination is unsupported.
Once you can rank all four tiers by cost, latency, and minimum retention without hesitating, you’re ready to combine this with related storage and governance topics covered in the AZ-104 study guide.