Hot, cool, archive: the six questions before you move anything

Tiering looks like the easiest win in Azure. Most of a storage account hasn't been read in a year, the archive tier is a fraction of the hot rate, and the portal will let you change the default with one dropdown. The saving is real. It's also the one cost lever where the mistakes are billed forward — you find out you were wrong 45 days later, on an invoice line that says you owe for 135 days you didn't use.

These are the six questions worth answering first, in the order they tend to bite.

Isn't archive just the cheapest tier?

Archive has the lowest storage cost and the highest everything-else cost, and the everything-else is where the surprise lives. A blob that lands in a cool, cold or archive tier owes that tier a minimum retention period — 30 days for cool, 90 for cold, 180 for archive. Delete it early, move it to another tier early, or simply overwrite it with a Put Blob, and you're charged the remaining days anyway, prorated at that tier's rate.

Microsoft's own example is blunt about it: a blob archived and then deleted on day 45 incurs a fee equivalent to 135 days of archive storage. The diagram below is the same blob under all three floors.

One useful escape hatch: Copy Blob leaves the source untouched, so copying an archived blob into an online tier avoids the early deletion fee entirely. You pay for two copies of the data instead. For a temporary analysis job that is usually the cheaper trade.

How long does "hours" actually mean?

Standard priority might take up to 15 hours for objects under 10 GB. High priority might complete in under an hour for the same size, costs more, and shows up as its own line on the bill. There's a fairness clause worth knowing: if a high-priority request for a blob under 10 GB takes more than five hours, Azure doesn't charge the high-priority rate.

The number that ruins restore plans is different. A maximum of 10 GiB per hour per storage account can be rehydrated with priority retrieval, and Microsoft states plainly that the "up to 15 hours" figure applies to individual blobs under ideal conditions and does not scale linearly for bulk. Two terabytes of archived backup is not a 15-hour restore. It's a multi-day one, shared across every other blob you asked for in the same account.

Cost, meanwhile, is dominated by a single per-GB meter. In Microsoft's own worked example, pulling 4 TB back out of archive costs about $88 in retrieval fees — against roughly 22 cents in transactions. The operations are noise; the gigabytes are the bill.

Why did my lifecycle policy re-archive what I just restored?

Because rehydrating a blob by changing its tier doesn't update its last modified time. Your policy says "archive anything not modified in 90 days", the restored blob's last modified time is still from last year, and the next policy run puts it straight back where it came from — after you paid the retrieval fee.

Two fixes, both documented. Add daysAfterLastTierChangeGreaterThan to the tierToArchive action, which is the condition that exists specifically for this; or rehydrate by copying instead, since a copy creates a new blob with a fresh last modified time that the policy won't match.

Can I tier on last access rather than last modified?

Yes, and it's the condition most people actually want — a file written once in 2023 and read every week is not cold data. Enable access time tracking and use daysAfterLastAccessTimeGreaterThan. Three caveats come with it.

Only Get Blob and Put Blob count as access. Get Blob Properties, Get Blob Metadata and Get Blob Tags do not — so an inventory scan or a monitoring agent walking the account won't keep anything warm. Only the first read in any 24-hour window updates the timestamp, to keep read latency down, which also caps what you're billed for the tracking. And the trap: when LastAccessTime is null — which is true of every blob that hasn't been read since you switched tracking on — the policy falls back to the date tracking was enabled. Turn it on today and nothing qualifies as 90-days-untouched until roughly 90 days from now.

Should I just turn on smart tier and stop thinking?

Smart tier is the "I don't know my access patterns" answer: data lands in hot, drops to cool after 30 days without access, drops to cold after 60 more, and jumps straight back to hot the moment something reads it. Crucially, objects in smart tier are not charged for tier transitions, early deletion fees, or data retrieval — the three costs that make manual tiering risky. What you pay instead is a monthly monitoring fee per object over 128 KiB.

Read the bottom two rows together. Smart tier bills per object, so an account of a hundred million small files is a different proposition from one holding a few thousand large ones — and blobs at or below 128 KiB never tier down at all, they just sit in hot. It's the right default for unpredictable data and the wrong one for a cold archive you already understand.

How do I even know what's in which tier?

This is the question that should come first and almost never does. Two answers, both cheap. Blob inventory produces a scheduled CSV or Parquet report, daily or weekly, and the schema includes AccessTier, AccessTierChangeTime, Content-Length and LastAccessTime — everything needed to size the decision before making it. Billing is per million objects scanned. For a faster look, storage account metrics split Blob Capacity by blob tier at no extra cost.

Neither of those crosses account boundaries, which is the actual problem once you're past one subscription. Tier distribution lives per storage account, spend lives in Cost Management, and nothing joins them — so "which accounts are carrying cold data at hot rates" stays a question you answer by opening tabs. Right-sizing comes first regardless: tiering reduces the rate on data you're keeping, never the cost of data nobody should be keeping, so the orphaned resource sweep belongs before this, not after.

GraphPaaS breaks Azure spend down by resource, type and resource group across every tenant you manage, with the month-by-month drill-down beside it — so storage that keeps climbing shows up as a line going the wrong way, before someone decides to fix it with a dropdown.