Why this matters
On Azure, the access tier is a property of each blob. One storage account can hold weekly campaign assets in Hot and seven-year audit exports in Archive, and both are billed correctly. That granularity is useful, but it also means the default setting decides your bill until someone changes it. Most accounts sit on Hot because that is where they started.
The cost curve bends in a way people don't expect. Colder tiers lower the price of stored bytes and raise the price of reading them. They also add a minimum storage duration: 30 days for Cool, 90 for Cold, 180 for Archive. Move or delete a blob before that window closes and you pay an early deletion charge for the remainder. A tier that looks cheaper per gigabyte can cost more once a daily job scans the data.
Behavior changes too. Hot, Cool, Cold and Smart are online and serve reads in milliseconds. Archive is offline: you set a rehydration priority and wait, usually hours, before the data is readable. Tiering is a decision about access latency as much as price.
Two failures show up again and again. Everything stays in Hot because nobody wrote a lifecycle rule, or a blanket rule archives data a team still opens every Monday. Both are fixed by mapping read patterns to prefixes before anyone touches policy.
Before you start
Gather four facts per container or prefix: total size, object count, average object size and read frequency. Object count matters as much as bytes. Per-operation charges dominate for small blobs, so a million tiny files can cost more to serve from Cool than to store in Hot.
Check the account kind. Access tiers need a general-purpose v2 or Blob Storage account. Premium block blob accounts trade tiering for throughput. Only block blobs support the colder tiers, so page blobs behind virtual machines and append blobs used for logs stay where they are.
Decide who sets the tier. You can set it at write time with the x-ms-access-tier header, in AzCopy with --block-blob-tier, or through the SDK. You can change it later with Set Blob Tier on a blob or a container. Or you can let lifecycle management move blobs on a schedule. Only lifecycle scales to thousands of containers; the manual calls are for corrections and one-off exceptions.
If your rules will use last access time, enable last access time tracking on the storage account first. It is off by default, tracks at day granularity, and adds a small charge per tracked blob. Without it, lifecycle rules can only use modification time, which is a poor signal for a dataset written once and read for years.
How to do it
Write the tier map before you write policy. Daily or weekly reads stay Hot. Monthly reads go to Cool. A few reads a year, still needed within hours, go to Cold. Data kept for compliance or rare restore goes to Archive. If access is genuinely unpredictable, the Smart tier moves blobs between Hot, Cool and Cold on its own and charges no early deletion fee, but it never archives.
Then encode the map as lifecycle rules. Rules run about once a day, take a prefix or blob index tag filter, and act separately on base blobs, snapshots and versions. A rule without a filter applies to the whole account, which is rarely what you want.
- Inventory the account. Export a blob inventory report or browse each container in Storage Explorer. Record bytes, object count and average object size per prefix, because small objects change the math.
- Write the tier map. Put one line per prefix with a target tier and a reason. Include the fastest acceptable restore time and the team that owns the data.
- Set the account default tier. Pick Hot or Cool as the default for new blobs. This is the safety net for data written by tools nobody remembered to configure.
- Enable last access tracking. Turn it on for the account if any rule will use daysAfterLastAccessTimeGreaterThan. Expect a small per-blob charge and day-level accuracy.
- Scope rules with prefix filters. Use prefixMatch so each rule touches one container or folder. Add separate actions for base blobs, snapshots and versions, and test the day values in a non-production account first.
- Pilot one large prefix. Move a single high-volume prefix, then watch transactions and retrieval charges for two weeks. Scale to other prefixes only after the numbers match the map.
- Plan rehydration. For archives that get requested regularly, rehydrate to a new Hot blob with Copy Blob and read the copy. Use high priority only when someone is waiting on the data.
- Add exclusions. Exclude containers under legal hold, immutability policy or an active restore. Keep that exclusion list in the same repository as the policy JSON so it gets reviewed.
- Review every month. Rerun inventory, compare tier counts to the map, and check the retrieval and early deletion lines in Cost Management. Adjust day values before the next quarter.
How to check it worked
Turn on blob inventory for the account and compare two reports: one before the change and one a few weeks after. The report lists every blob with its access tier, size and last access time when tracking is enabled. Count bytes per tier and confirm that the big prefixes landed where your map said they would.
Then read the invoice, not just the portal estimate. In Cost Management, split storage cost into capacity, transactions, data retrieval and early deletion. Retrieval charges on Cool or Cold mean something reads that data more often than you assumed. Early deletion charges in the first month mean a rule moved blobs too soon or fired on a prefix you did not intend.
Test one restore end to end. Pick a real archived blob, rehydrate it at standard priority, and record how long it takes and what it adds in retrieval and read operations. Do that on a quiet Tuesday, not during an audit or an incident.
Mistakes to avoid
Treating last modified as last read. A nightly export overwrites the same path forever, so modification time always looks fresh while reads may be rare. Use last access tracking or your own request logs before you tier that prefix down.
Tiering tiny objects. Storage savings on a small blob are trivial; the per-read charge is not. Keep small blobs in Hot and tier the large ones.
Archiving without a rehydration plan. Archive has no instant read, and even high priority takes time on large blobs. Remember that snapshots and versions carry their own tier, so a rule on base blobs alone leaves copies sitting in Hot.
If the storage line on the bill is the part nobody can explain, an outside review can help. The Cloud cost audit from Cloudverg is a two-week, fixed price $4,500 read-only review of up to three subscriptions that ranks storage tier findings next to idle resources and commitment options. You can also do the same work in house with inventory exports and Cost Management.
Frequently asked questions
Can I change a blob's access tier after it is uploaded?
Yes. Use Set Blob Tier on the blob or container, or let a lifecycle rule move it on a schedule. Moving to a colder tier starts a new minimum storage duration, so leaving Cool before 30 days triggers an early deletion charge for the remaining period.
How long does it take to read a blob from the Archive tier?
It depends on the rehydration priority and the blob size. Standard priority usually completes within hours, and high priority is faster and costs more. The request is asynchronous, so build a job that starts the rehydration, waits, then copies the blob to a warmer tier.
What is the difference between the account default tier and a blob's tier?
The account default tier, Hot or Cool, applies only to new blobs that arrive without an explicit tier. Each blob then keeps its own tier until a person, a script or a lifecycle rule changes it. Treat the account setting as a starting point, not as your policy.