Cost

Tier blob data automatically with lifecycle management

One capability across every storage account: stop paying hot-tier prices for data nobody reads, by letting a lifecycle policy move blobs to cool, cold and archive on a schedule, and delete what has aged out, instead of leaving it all on the most expensive tier by default.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Blob lifecycle tiering: the basics

Why is so much storage spend sitting on the wrong access tier?

Azure Blob storage has four access tiers, and the price you pay per gigabyte differs sharply between them. Hot is built for data read and written constantly and carries the highest storage price. Cool is for data accessed roughly monthly, with a lower storage price but higher read costs and a 30-day minimum. Cold is for data touched a few times a year, cheaper still to store, with a 90-day minimum. Archive is an offline tier for data you almost never read, with the lowest storage price of all, a 180-day minimum and a rehydration step measured in hours. The default for a new account is hot, so unless someone changes it, every backup, log, export and old asset keeps paying the top rate forever.

Azure Advisor turns this into a specific cost recommendation, 'Use lifecycle management', and surfaces it in the Cost Optimization workbook on the Storage tab. The point it is making is simple: most of the data in a typical account is written once and read rarely, yet it sits on hot. A lifecycle management policy is a rule-based engine on the account that automatically transitions blobs to a cooler tier as they age or go unread, and deletes them once they pass a retention threshold. You write the rules once and Azure runs them every day.

Almost all of this overspend is drift, not intent. An account created with the hot default, a logging pipeline that never set a tier, an export job that piles up files nobody deletes. The work is to find the accounts where cold data is sitting hot, decide the right tiering and retention for each data type, and let a policy move it automatically, so you are paying hot prices only for the data that is genuinely hot.

In this lesson you will learn how Azure Blob access tiers are priced, how to find the accounts paying hot rates for cold data, and how to write a lifecycle management policy that tiers and expires data automatically without putting frequently read data behind a slow tier. The keep-learning section links the Microsoft references for the policy structure, the access tiers and last-access tracking.

Fun fact

The tier nobody chose

When you create a blob and never set an access tier, Azure puts it on hot, the most expensive tier to store, and there it stays for the life of the object unless something moves it. That default is sensible for active data and quietly wasteful for everything else, which is why a years-old account is often a sediment of logs and exports all paying the top rate. The catch that trips people up runs the other way: cool, cold and archive each have a minimum retention period, 30, 90 and 180 days. Move a blob down too soon, or delete it before the minimum, and Azure bills an early-deletion charge as if it had stayed. The art of a good lifecycle policy is matching the transition days to how the data is actually read, so you bank the storage saving without paying penalties to get there.

Finding hot data that should be cold

Priya runs the platform team at a growing SaaS company. The monthly Azure bill has crept up and the Cost Optimization workbook shows the 'Use lifecycle management' recommendation against several storage accounts, with the storage line dominated by a single logs-and-exports account.

Rather than guess at retention rules, Priya starts by listing the accounts and their default access tier, so she can see which ones are defaulting everything to hot before deciding what a sensible lifecycle policy looks like for each.

Start by listing storage accounts and the default access tier set on each. Accounts defaulting to Hot are where cold data is most likely sitting on the expensive tier.

$ az storage account list --query "[].{name:name, kind:kind, tier:accessTier}" -o table

Name Kind Tier

------------------ --------- -----

applogsprod StorageV2 Hot

exportsarchive StorageV2 Hot

activeappdata StorageV2 Hot

# applogsprod and exportsarchive hold write-once data on Hot. Tier them down first.

An account full of write-once logs or exports sitting on Hot is the highest-value target: the storage saving from tiering it down is recurring and the data is rarely read.

How a lifecycle policy decides what to tier and whendeep dive

A lifecycle management policy is a JSON document of rules attached to the account. Each rule has a filter that selects which blobs it applies to, typically 'blobTypes' set to 'blockBlob' and an optional 'prefixMatch' to scope it to a container or path, and a set of actions on the 'baseBlob'. The actions are the transitions: 'tierToCool', 'tierToCold' and 'tierToArchive', each gated by a condition, and 'delete' to expire data. The condition is either 'daysAfterModificationGreaterThan', counting from when the blob was last written, or 'daysAfterLastAccessTimeGreaterThan', counting from when it was last read. Last-access conditions require last-access tracking to be enabled on the account first.

Azure evaluates the policy once per day. After you create or change a policy it can take up to 24 hours for the first run, and large backlogs can take another cycle or two to finish moving, so the saving appears on the bill gradually rather than instantly. This is why you set the rules and then watch the next billing period, rather than expecting the line to drop overnight.

The conditions interact with each tier's minimum retention, and that is where cost discipline lives. Cool has a 30-day minimum, cold 90 and archive 180. If a rule moves a blob to cool and another moves it to archive a week later, or a delete fires before the minimum, Azure charges an early-deletion fee as though the blob had stayed for the full minimum. Last-access tiering with 'enableAutoTierToHotFromCool' set guards the other failure mode: if a blob you tiered down is read again, it is promoted back to hot automatically, so an occasional read does not get stranded paying cool read prices.

What is the impact of leaving everything on the hot tier?

The direct impact is recurring overspend. Every gigabyte of write-once data sitting on hot is billed at the premium storage rate every month, when the same data on cool, cold or archive would cost a fraction of that to store. Because storage only ever accumulates, the gap widens over time: each month adds more cold data to the hot tier and the wasted spend grows with it. This is exactly the pattern Azure Advisor's 'Use lifecycle management' recommendation is built to catch.

The second-order impact is that the saving is left on the table indefinitely. Without a policy, tiering is a manual job nobody does, so even data the team knows is cold keeps paying hot prices. A lifecycle policy converts a one-time decision into an ongoing saving: once the rules are set, every new log, export and backup is tiered automatically as it ages, so the optimisation compounds without further effort.

There is a trade-off to respect, which is why this is not a blanket 'tier everything down' move. The cooler tiers have higher per-read costs and minimum retention periods, so tiering data that turns out to be read often, or moving it down faster than the minimums allow, can cost more than it saves through read charges and early-deletion fees. The impact of getting the policy right is a lower bill with no loss of availability; the impact of getting it wrong is read costs and penalties that erode the saving. The discipline is to match the tiering schedule to how each data type is actually read.

How do you tier blob data down safely?

Work the capability as one loop rather than tiering account by account on instinct. The order matters: classify data by how it is read before you write any rule, so you do not put frequently read data behind a slow, expensive-to-read tier.

1. Inventory accounts and their data profile

List the storage accounts, their default access tier and what each one holds. Separate the write-once, rarely read data, logs, backups, exports and old assets, from the genuinely active data. The Advisor 'Use lifecycle management' recommendation and the Cost Optimization workbook Storage tab point you at the accounts with the most to gain.

2. Decide the tiering schedule per data type

For each rarely read data type, choose transition days that respect the tier minimums: cool after 30 days or more, cold after 90 or more, archive after 180 or more, and a delete action once data passes its retention requirement. Match the days to how the data is read, not to the most aggressive possible discount, so you avoid early-deletion fees and surprise read costs.

3. Handle uncertain read patterns with last-access tiering

Where you are unsure how often data is read, enable last-access tracking and tier on 'daysAfterLastAccessTimeGreaterThan' with auto-rehydration from cool to hot. Data that goes quiet tiers down and saves money; data that is read again is promoted back to hot automatically, so an occasional read does not strand a blob paying cool read prices.

4. Apply the policy and let it run

Attach the lifecycle policy to the account and let Azure run it daily. The backlog tiers down over the first day or two and the saving appears on the next billing period; from then on every new blob is tiered automatically. Codify the policy in Bicep so the same rules apply to every account by default and the saving is enforced rather than remembered.

# 1. (Optional) Enable last-access tracking so you can tier on read time, not just write time.
az storage account blob-service-properties update \
  --account-name applogsprod \
  --resource-group rg-platform \
  --enable-last-access-tracking true

# 2. Define the lifecycle policy. Transition days respect each tier's minimum
#    (cool 30, cold 90, archive 180) so no early-deletion fees are incurred.
cat > lifecycle-policy.json <<'JSON'
{
  "rules": [
    {
      "name": "tier-down-write-once-data",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool":    { "daysAfterModificationGreaterThan": 30 },
            "tierToCold":    { "daysAfterModificationGreaterThan": 90 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
            "delete":        { "daysAfterModificationGreaterThan": 2555 }
          }
        },
        "filters": {
          "blobTypes": [ "blockBlob" ]
        }
      }
    }
  ]
}
JSON

# 3. Apply the policy to the account. Azure runs it daily; the backlog tiers
#    down over the first 24-48 hours and the saving lands on the next bill.
az storage account management-policy create \
  --account-name applogsprod \
  --resource-group rg-platform \
  --policy @lifecycle-policy.json

Quick quiz

Question 1 of 5

Azure Advisor shows the 'Use lifecycle management' recommendation against several storage accounts. What is the most efficient way to think about it?

Keep learning

Go deeper on how Azure Blob access tiers are priced and how to express the right tiering and retention rules in a lifecycle policy.

You can now treat blob storage cost as one capability rather than a line that only rises: inventory which accounts hold cold data on the hot tier, classify each by how it is read, set lifecycle policies that tier write-once data to cool, cold and archive on a schedule and expire it past retention, and leave the active data on hot. With the policy attached, Azure captures the saving on new data automatically, so the bill tracks how data is used rather than the full history of what was written.

Back to the library

Blob lifecycle tiering: the savings view

A near-zero-effort change that takes a recurring line off the Azure bill

Storage is one of the few line items where the saving is recurring and the change is essentially free to make. Moving cold data off the hot tier lowers the per-gigabyte storage rate every month it stays there, and a lifecycle policy keeps doing it automatically as new data ages, so the saving compounds rather than being a one-off. There is no licence to buy and no new resource to run: the policy is a property of the account.

Frame the Advisor 'Use lifecycle management' recommendation as a savings opportunity with a clear payback rather than a chore. The only costs to net off are the per-gigabyte transition charges Azure bills when a blob moves down a tier, and the higher read costs and early-deletion minimums on the cooler tiers if data is moved too aggressively or read more than expected. For genuinely cold data the storage saving dwarfs those, so the payback is fast and the decision is close to risk-free. For data with an uncertain read pattern, last-access-based tiering with auto-rehydration keeps it from being a trap.

The arithmetic is one-sided for the right data. The cost of acting is some engineering time to design retention rules and a small, one-time transition charge as the backlog moves down. The cost of not acting is paying the hot rate, month after month, on data nobody reads.

This lesson is for the finance partner who sees a storage line that only ever rises and wants to know whether it can be cut without a trade-off. It covers why lifecycle tiering is a recurring, compounding saving, what the transition and read costs are that you net off, and how to tell the risk-free moves from the ones that need a read-pattern check first.

Fun fact

The tier nobody chose

How a finance partner frames the tiering decision

Priya is the finance partner working with the platform team on a cost review. The Advisor 'Use lifecycle management' recommendation lands against several accounts, and the storage line is dominated by one logs-and-exports account sitting entirely on hot. The instinct is not to wave it through as a routine cleanup; it is to ask what the saving actually is and what it costs to capture. Tiering write-once data down to cool, cold or archive lowers its per-gigabyte storage rate every month, and a lifecycle policy keeps doing it automatically, so this is a recurring, compounding saving rather than a one-off.

Priya asks the team to classify each account by how its data is read. The logs account is write-once and queried only during incidents, so it tiers to cool quickly and to cold or archive as it ages, with the bulk of the saving banked against a small one-time transition charge. The exports archive is read once a quarter at most and goes to archive, the deepest discount. The active application data account stays hot, because tiering it would raise read costs more than it saves. The finance pack reads: 'Two accounts carry a recurring storage saving that pays back almost immediately against a one-time transition charge; one account is correctly left hot; the policy then keeps capturing the saving on new data with no further work.'

Why tiering belongs on the cost review

The savings model here is unusually attractive because it is recurring and self-sustaining. Tiering cold data down lowers its storage rate every month it stays there, and a lifecycle policy keeps applying the saving to new data automatically, so a single design decision pays back month after month rather than once. For genuinely cold data, the storage saving dwarfs the one-time transition charge to move it, so the payback is measured in weeks, not years.

The costs to net off are real but bounded and predictable: a per-gigabyte transition charge when blobs move down a tier, higher per-read costs on the cooler tiers, and early-deletion fees if data is moved or deleted before its tier minimum. The finance role is to make sure the team classifies data by read pattern before tiering it, so the recurring storage saving is captured on the data that is genuinely cold and the active data is correctly left on hot, where tiering it would cost more in reads than it saves in storage.

What finance can do about the storage saving

Finance cannot write a lifecycle rule, but it owns the framing that turns the Advisor recommendation into a captured, recurring saving with a clear payback and a bounded set of costs to net off. Three levers.

1. Treat the saving as recurring, not one-off

Make explicit that tiering cold data down lowers its storage rate every month it stays there, and that the lifecycle policy keeps applying the saving to new data automatically. The right way to book it is as a recurring reduction to the storage run-rate with a one-time transition charge netted off, not as a single cleanup. That framing is what justifies the small amount of engineering time to design the rules.

2. Require a read-pattern classification before tiering

The saving only holds for data that is genuinely rarely read. Ask the team to classify each account by access pattern before any rule is written, so write-once data tiers down and active data stays hot. This is what keeps the cooler-tier read costs and early-deletion minimums from quietly eroding the saving. Where the read pattern is uncertain, last-access tiering with auto-rehydration is the safe default.

3. Track the storage run-rate, not just the headline bill

The metric that belongs on the cost review is the storage run-rate broken down by access tier, so you can see the proportion of data sitting on hot that could be cooler. A rising hot-tier proportion is the early warning that new accounts are defaulting to hot without a policy. Tracking the mix, rather than only the total, is what keeps the saving from quietly leaking back as the estate grows.

Quick quiz

Question 1 of 5

As the finance partner, how should you book the saving from a lifecycle tiering policy on a write-once logs account?

Keep learning

Go deeper on how Azure Blob access tiers are priced and how to express the right tiering and retention rules in a lifecycle policy.

You have finished the finance view of blob lifecycle tiering. You know the saving is recurring and compounding: tiering cold data down lowers its storage rate every month and the policy keeps applying it to new data, against a one-time transition charge and bounded cooler-tier read and early-deletion costs you net off. Next time the Advisor 'Use lifecycle management' recommendation appears, you will ask the team to classify data by read pattern, book the saving against the run-rate, and track the tier mix so it does not leak back as the estate grows.

Back to the library

Blob lifecycle tiering: the headline

Whether the estate pays premium storage prices for data it never reads

Storage tends to grow quietly and never shrink. Logs, backups, exports and old assets accumulate on the default hot tier and keep billing at the premium rate long after anyone reads them. Azure Advisor flags this directly as a cost recommendation, yet it is easy to leave unactioned because no single account looks expensive on its own.

The leadership question is not 'how much storage do we have?' It is 'are we paying hot-tier prices for cold data, and is that fixed by design or only when someone remembers to check?' The defensible end state is that every account with meaningful cold data has a lifecycle policy moving it down automatically, so the bill tracks how the data is actually used rather than how it was first written.

This is a savings decision with a fast payback and low risk for the right data, not a trade-off between cost and capability. The data stays exactly as available as its access pattern requires; you simply stop overpaying to keep rarely read data on the fastest tier.

A short read for the leader who needs to know why storage spend drifts upward, why automated tiering is a fast-payback savings move rather than a capability trade-off, and what a defensible end state looks like: the bill tracking how data is used, not how it was first written.

Fun fact

The tier nobody chose

What it looks like when the storage bill tracks usage, not history

The storage line on the Azure bill had grown every quarter for two years, and at a cost review the CFO asked the obvious question: is it growing because we are doing more, or because we never clean up? The honest answer was that nobody knew, because every account defaulted new data to the hot tier and nothing ever moved it down, so the bill reflected the entire history of data written rather than how any of it was actually used.

The team's response was to stop treating storage cost as fixed and start treating it as managed. They identified the accounts holding write-once logs and exports, set lifecycle policies that tier that data to cool, cold and archive on a schedule and expire it past its retention window, and left the genuinely active accounts on hot. The recurring storage saving showed up on the next bill, and because the policies run every day, new data is tiered automatically without anyone touching it. The next time the CFO asked, the answer had changed from 'it just grows' to 'it tracks how the data is used: active data is hot, everything else tiers down on its own, and we stopped overpaying for data nobody reads.' That shift, from a bill that only rises to one that reflects real usage, is the payoff this capability delivers.

Why this is a standing efficiency win

Storage spend that only ever rises is a sign the bill reflects the history of data written rather than how it is used. Automated tiering fixes the root cause: it makes the cost of each piece of data track its actual access pattern, so active data pays hot prices and rarely read data does not. Because the policy runs every day, the saving is captured on new data automatically, which makes this a standing efficiency win rather than a one-off cleanup.

The payback is fast and the risk is low for the right data, because tiering changes nothing about availability, only the price of storage and retrieval. The leadership trade is therefore straightforward: a recurring saving with a quick return, as long as the team matches the tiering schedule to how the data is read so the cooler-tier read costs and retention minimums do not erode it.

The leadership move on storage cost

The executive handle is not to approve each tiering rule; it is to require that automated tiering is the default for any account holding meaningful cold data, so the bill tracks usage by design rather than by anyone remembering to optimise.

1. Set the expectation that cold data tiers down by default

Ask for lifecycle policies on every account with write-once or rarely read data, and for new accounts to inherit a sensible default policy through your infrastructure templates. A policy that applies automatically is the difference between capturing the saving once and capturing it on every gigabyte written from now on.

2. Ask for the saving on the bill, not in a slide

The proof this is working is a lower storage run-rate on the next billing period and a falling proportion of data sitting on the hot tier, not a one-off report that a policy was applied. Because Azure runs the policy daily and the backlog tiers over a day or two, ask to see the effect on the following bill and then as a standing line on the cost review.

3. Keep the active data on its tier deliberately

The goal is not to tier everything down to the cheapest possible store; it is to match each data type to how it is read. Frequently read data belongs on hot, and forcing it cooler would raise read costs more than it saves. The leadership requirement is that tiering decisions are driven by access pattern, so the saving is real and no service is slowed to chase a discount that the read costs would cancel out.

Quick quiz

Question 1 of 5

At a cost review you ask why the storage line only ever rises. What end state should you be looking for as the answer?

Keep learning

Go deeper on how Azure Blob access tiers are priced and how to express the right tiering and retention rules in a lifecycle policy.

Two takeaways. Automated tiering is a fast-payback savings move with low risk for the right data, because it changes the price of storage, not its availability, so it is a trade you can approve quickly. And the defensible end state is not 'we cleaned up storage once'; it is a lifecycle policy on every account with cold data, running daily, so the bill tracks how data is used by design and the active data stays deliberately on its tier.

Back to the library

Part of the learning path Cut your Azure storage bill

Tier blob data automatically with lifecycle management

Blob lifecycle tiering: the basics

The tier nobody chose

Finding hot data that should be cold

How a lifecycle policy decides what to tier and whendeep dive

What is the impact of leaving everything on the hot tier?

How do you tier blob data down safely?

1. Inventory accounts and their data profile

2. Decide the tiering schedule per data type

3. Handle uncertain read patterns with last-access tiering

4. Apply the policy and let it run

Quick quiz

Keep learning

Blob lifecycle tiering: the savings view

The tier nobody chose

How a finance partner frames the tiering decision

Why tiering belongs on the cost review

What finance can do about the storage saving

1. Treat the saving as recurring, not one-off

2. Require a read-pattern classification before tiering

3. Track the storage run-rate, not just the headline bill

Quick quiz

Keep learning

Blob lifecycle tiering: the headline

The tier nobody chose

What it looks like when the storage bill tracks usage, not history

Why this is a standing efficiency win

The leadership move on storage cost

1. Set the expectation that cold data tiers down by default

2. Ask for the saving on the bill, not in a slide

3. Keep the active data on its tier deliberately

Quick quiz

Keep learning

Related cost lessons