Bulk Change Azure Blob Tiers: Hot, Cool, Cold, Archive
· 7 min read · Updated
To change the tier of many blobs at once, Azure gives you the portal, a script (Azure CLI or PowerShell), or a lifecycle management policy that moves blobs on a schedule. This guide covers those, plus a desktop option where you select the blobs and set the tier without writing a script.
Azure Blob Storage offers four generally available access tiers for block blob data: Hot, Cool, Cold, and Archive. Each tier has different storage and retrieval costs. The plan is to keep frequently accessed data on Hot, move older data to Cool or Cold, and put rarely needed files on Archive for the lowest per-GB rate[1].
Doing that by hand takes work. The Azure portal is fine for occasional manual changes, but repeatable bulk work usually means PowerShell, Azure CLI, direct API calls, or lifecycle management policies. To move 500 blobs from Hot to Archive right now, you either click through the portal or write and test a script.
Lifecycle policies handle automated transitions by rules and schedules. They aren't designed for the moment you look at a set of files and decide that these particular blobs need a different tier today.
The colder the tier, the less you pay to store data and the more you pay, in both money and time, to read it back.
| Tier | Storage cost | Read cost | Minimum retention | Time to first byte | Best for |
|---|---|---|---|---|---|
| Hot | Highest | Lowest | None | Milliseconds | Data in active use |
| Cool | Lower | Higher | 30 days | Milliseconds | Backups, data read about monthly |
| Cold | Lower still | Higher still | 90 days | Milliseconds | Rarely touched data you still want instantly |
| Archive | Lowest | Highest | 180 days | Hours (rehydration) | Long-term archive and compliance copies |
Two things catch people out:
- Archive is offline. You cannot read an archived blob directly. You first rehydrate it to Hot, Cool, or Cold, which can take up to 15 hours. Plan for that latency before you archive anything you might need quickly.
- Early deletion penalty. If you delete, overwrite, or move a blob out of Cool (30 days), Cold (90 days), or Archive (180 days) before its minimum retention elapses, Azure charges a prorated early deletion fee. Moving a blob to Archive and pulling it back two weeks later triggers that fee.
Moving an online blob to another online tier, or down to Archive, is an immediate tier operation. Only the reverse, rehydrating from Archive to an online tier, is a pending restore that can take hours[2].
Blober is a desktop app, and Azure Blob Storage is one of its supported providers. Besides the usual read, write, list, and delete operations, it supports mutations for Azure Blob: a workflow action that changes properties of existing blobs without transferring any data.
Blober currently supports two Azure mutations.
Select any number of blobs in the Blober file browser, choose a target tier (Hot, Cool, Cold, or Archive) under Change Storage Tier, and run the mutation. Every selected blob moves to the new tier without a re-upload, a script, or waiting for a lifecycle policy to kick in.
Use it when a project is finished and its assets should move to Archive, or when you need to bring archived files back to Cool for a review cycle.
Azure containers can be set to Private, Blob-level public access, or Container-level public access. Changing access levels usually means opening each container in the portal and updating the setting. In Blober, you select the containers you want to change, pick the level under Container Access Level, and apply it.
Say you run a media production company. A container called project-alpine-2025 holds 800 GB of raw footage on Hot storage. The project wrapped three months ago, no one is opening those files, and you are paying Hot rates for data that should be on Archive.
With Azure CLI, you would write something like:
az storage blob list --container-name project-alpine-2025 --output tsv | \
while read line; do
az storage blob set-tier --container-name project-alpine-2025 --name "$line" --tier Archive
done
This works, but you need to set up authentication, handle pagination for large containers, deal with blobs that are already archived, and test the script before running it on production data.
In Blober, you open your Azure Blob connection, go to the container, select all files, choose Archive as the target tier, and run it.
Tier changes and access levels are the first mutations Blober supports for Azure. The design lets mutations extend to other providers and other kinds of change. Later ones could include metadata updates, blob tagging, or replication settings, with the same point-and-click control over blob properties that you already have for transfers.
Connecting Azure to Blober takes less than a minute:
- Open Blober and add a new provider
- Select Azure Blob Storage
- Paste your connection string (the same one you would use with Azure Storage Explorer or the SDK)
- Blober verifies the connection and lists your containers
From there, you can browse blobs, transfer files to or from Azure, and run mutations on existing blobs.
When Azure is the destination, two settings apply. Storage Tier chooses the tier for new uploads (Hot, Cool, Cold, or Archive). Deduplication either skips a blob that already exists or overwrites it, and archived blobs are always skipped whichever policy is selected.
Both are set per workflow, so one workflow can upload to Hot while another uploads directly to Archive.
Bulk tier changes help DevOps teams managing storage costs across many containers and projects, media companies archiving completed project assets, backup administrators moving cold data to cheaper tiers, and anyone who has outgrown the Azure portal's one-blob-at-a-time tier management.
Does changing a blob's access tier create a new version? No. When versioning is enabled, the operations that create a version are writes: Put Blob, Put Block List, Copy Blob, and Set Blob Metadata. Set Blob Tier is not on that list; Azure documents tiering as an access-tier operation that can be applied to a blob version[3][4]. If you already keep multiple versions, each version holds its own tier. Explicitly tiering a version changes how that version is billed, and no new version is generated.
Is this different from changing an Amazon S3 storage class?
Yes. Azure has a Set Blob Tier operation for changing the tier of a blob or version. In S3, an immediate manual storage-class change is copy-based: AWS documents changing an existing object's storage class with a copy to the same object URI, and CopyObject returns the version ID of the newly created copy when versioning is enabled[5]. S3 Lifecycle transitions work differently again: they transition the current or noncurrent object version that the rule selects, and do not create a new current version[6]. See Azure Blob Tiers vs AWS S3 Storage Classes for the full comparison.
Can I set the tier per file share or only per storage account? File shares belong to Azure Files, which is separate from Azure Blob Storage. In Azure Blob, the tier is a property of each blob, so you set it per blob, and Blober changes many at once. In Azure Files, pay-as-you-go classic file shares have access tiers such as transaction optimized, hot, and cool, while the SSD/HDD media tier is a choice you make when planning the file share. Microsoft documents that once you create a file share in a storage account, you cannot move it directly to a different media tier; to move from HDD to SSD, for example, you create a new share and copy the data[7]. Blober's bulk tier change applies to blobs in Azure Blob Storage.
How long does a tier change take? Moving from a warmer tier to a cooler one, such as Hot to Cool or Cool to Archive, is immediate. Bringing a blob back from Archive to an online tier is a rehydration that can take up to 15 hours, depending on the priority you choose.
Can I move blobs to Archive in bulk without PowerShell? Yes. Select the blobs in Blober, choose Archive as the target tier, and run the mutation, with no script, lifecycle policy, or Azure CLI involved. The same works in reverse to rehydrate selected blobs to Hot, Cool, or Cold.
Will changing tiers re-upload my data? No. A tier change is an access-tier operation that Azure performs on the blob itself, so Blober downloads and uploads nothing for the change. Azure still bills the Set Blob Tier request as a write operation for tier-down and a read operation for tier-up[8].