Azure Blob Storage offers four access tiers priced for different patterns. The hot tier carries the highest storage rate and the lowest access charges, for data read often. The cool tier lowers the storage rate and raises access charges for data read occasionally, with a 30 day minimum retention. The cold tier lowers storage further for data read rarely, with a longer minimum retention. The archive tier carries by far the lowest storage rate, a small fraction of hot, but the blob is offline and must be rehydrated over hours before it can be read, with a 180 day minimum retention and a rehydration charge. The storage rate falls steeply as you move down, but cost shifts to access charges, early deletion fees against the minimum retention, and rehydration, so the right tier depends entirely on how often each blob is actually read. The lever that turns this into money is lifecycle management: a policy that moves blobs to a cooler tier after a set number of days since last modification or last access, and deletes them when retention ends, all without an engineer touching the workload. Set those rules from real access data rather than a guess and the saving accrues every month.
Here is how each tier is priced, where the hidden charges sit, and how to write lifecycle rules that hold up in production.
Which Blob tier fits which access pattern?
Choose the tier from how often the blob is read. Hot suits data read daily or weekly, where the low access charge outweighs the higher storage rate. Cool suits data read a few times a month and carries a 30 day minimum retention plus higher per operation and per gigabyte read charges. Cold suits data read only a few times a year, with a longer minimum retention and lower storage still. Archive suits data you almost never read and can wait hours to restore: the storage rate is the lowest by far, but the blob is offline, rehydration takes up to several hours or can be expedited at a premium, and a 180 day minimum retention applies. The wrong tier is expensive in both directions, a hot blob nobody reads wastes storage rate, and a cool or archive blob read weekly racks up access and rehydration charges.
How does Azure lifecycle management cut the bill?
Lifecycle management is a rule set on a storage account that acts on blobs by prefix or blob index tag. Each rule can move a blob to cool after a number of days since last modification or last access, move it to cold or archive after a longer period, and delete it once retention ends. A common pattern moves logs and backups to cool after 30 days, to archive after 90 or 180 days, and deletes them at the compliance limit, entirely automatically. Two details decide whether the policy saves or costs money. First, respect the minimum retention: moving a blob to cool and deleting it a week later still bills the 30 day minimum as an early deletion charge. Second, base the move on last access where the pattern is uncertain, since moving by age alone can demote a blob that is still being read.
What hidden charges undo a tiering plan?
Three charges erode the saving if ignored. Access and transaction charges rise as you go colder, so a dataset that turns out to be read often becomes expensive in cool or cold and should stay hot. Early deletion fees bill the full minimum retention, 30 days for cool, longer for cold, and 180 days for archive, even if you delete sooner, which punishes premature transitions. Rehydration from archive costs both a per gigabyte fee and a wait of up to several hours, so archive is wrong for anything you might need quickly. Model all three against your access data before committing. The right tier for a container is the one with the lowest total of storage plus expected access plus any rehydration over the blob lifetime, not simply the lowest storage rate.
How do you set the rules from evidence?
Turn on last access time tracking so lifecycle rules can act on real reads rather than modification age, and use storage metrics and the cost export to see which containers hold cold data. Tag containers and blobs by owner and workload so each rule has an accountable home and is revisited when the workload changes. Write narrow rules per container or prefix rather than one blunt rule across the account, because a single rule across mixed data either leaves hot blobs in cold tiers or strands cold blobs in hot. Start the archive transition conservatively, since the 180 day minimum and the rehydration wait make archive the least forgiving tier to get wrong.
How does this fit the wider Azure storage picture?
Tiering is one lever among several. Pair it with deleting orphaned blobs and old snapshots, with choosing the right redundancy level since geo redundant storage costs more than locally redundant, and with watching egress, which the sibling note on bandwidth and egress on Azure covers. Read the amortised cost export to see the storage and transaction meters as the source of truth rather than a console summary. Tiering plus cleanup plus the right redundancy together turn the storage line from a slow drift upward into a managed, predictable cost.
A worked example
A Fortune 500 retailer held a large Blob estate of application logs, image derivatives, and database backups, nearly all of it in the hot tier by default. Enabling last access tracking showed most blobs went untouched after the first two weeks. A lifecycle policy moved them to cool at 30 days and to archive at 120 days, deleting at the retention limit, while modelling the early deletion and rehydration charges first kept a frequently restored backup set in cool rather than archive. The storage line fell sharply within two billing cycles with no application change and no impact on the rare restores. Figures are verified against billing data and anonymised.
Frequently asked questions
What is the cheapest Azure Blob storage tier?
Does Azure lifecycle management cost anything?
Should lifecycle rules move blobs by last modified or last accessed?
Put your Azure Blob estate on the right tiers
We help Azure teams enable last access tracking, model access and rehydration charges, and write lifecycle rules that cut the storage line without slowing a single restore, across AWS, Azure, GCP, and OCI. We take zero provider commissions and answer only to you, on a Fixed Fee or a no risk Gainshare basis, with a plain guarantee: we reduce your cloud spend or we reimburse our service fee. Download the storage playbook, and read the full Azure method below.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.