Azure Storage Account Costs: Access Tiers, Not SKU

An Azure Storage Account SKU is a combination of performance and replication — Standard_LRS, Premium_ZRS — not a price tier you lower the way you downsize a VM. That is why "lower the pricing tier (SKU) on your storage account" is such a common piece of bad advice from cloud cost tools. It sounds reasonable, and it is wrong in a way that can quietly damage your disaster-recovery posture.

What does the storage account SKU actually control?

• Performance tier (Standard vs Premium) is mostly immutable after creation — you cannot simply downgrade an account in place.
• Replication tier (LRS, ZRS, GRS, GZRS, RAGRS, RAGZRS) controls how many copies of your data Azure keeps and where. Going from GRS to LRS roughly halves the storage rate — and removes cross-region redundancy. That is a durability trade, not a free win.

So when a tool says "lower the SKU to save money" without qualifying the redundancy tradeoff, it is telling you to silently downgrade disaster recovery. That is not optimization; that is a future incident. It is a sibling of the false-positive problem covered in why cost tools flag active resources: advice generated without understanding what the knob does.

What actually drives a storage bill?

Three meters, in descending order for most accounts:

• Data volume stored (GB-months) — usually most of the bill.
• Transactions (reads, writes, list operations) — varies wildly by workload.
• Egress (data leaving the region) — matters when external systems consume the data.

The lever that meaningfully changes the first meter without touching durability is the blob access tier, set per container or per blob.

How do you choose a blob access tier?

• Hot — default. Cheapest transactions, most expensive storage. For data read more than once a week.
• Cool — storage roughly half the Hot rate, per-GB read fees, 30-day minimum retention. For backups touched a couple of times a month.
• Cold — cheaper storage still, 90-day minimum retention, higher access fees. For data read once a quarter at most but needed within minutes.
• Archive — storage roughly 90% cheaper than Hot, but offline: rehydration takes hours. For long-term retention you genuinely will not touch in normal operations.

The arithmetic: switching a container of rarely-read backups from Hot to Cool roughly halves that data's monthly storage cost; moving truly cold compliance data to Archive cuts it by about 90%. The catch is access pattern. Read Cool, Cold, or Archive data more than a few times a month and the per-read fees can wipe out the savings — and early deletion inside the minimum retention window incurs a charge. The tier must match the workload, not just shrink the storage line.

How do you change tiers in practice?

For a one-off move, az storage blob set-tier changes a blob, and the portal can change a container default. For anything recurring, use lifecycle management (Storage account, then Data management, then Lifecycle management): a rule like "move blobs to Cool 30 days after last modification, to Archive after 180, delete after 2,555" runs automatically and keeps the account tiered forever without anyone remembering to do it. One rule per data class — logs, backups, compliance — is usually enough. Test a new rule on one container first; a misaimed rule that archives hot data creates rehydration delays and access fees in the other direction. Lifecycle rules are also the cleanest answer to snapshot sprawl, the same hygiene problem behind orphaned Azure resources.

When is changing replication worth it?

Only when the DR requirement genuinely is not there. GRS to LRS halves the storage rate, so for a large account it is real money — but only consider it when your disaster-recovery plan does not require automatic cross-region failover for that data, and the owner of that plan signs off. Non-production data that can be regenerated is a fair candidate. Production backups almost never are. If you are not sure, leave it alone; the savings never justify discovering the gap during a regional outage.

What does CloudRift recommend instead?

CloudRift's explainer for a Storage Account does not say "lower the SKU." It says: storage cost comes from data volume times access frequency, so if the data is rarely accessed, change the blob access tier per container — and the replication SKU controls redundancy, so switch it only if you do not need cross-region replication. Each recommendation carries the evidence behind it and a confidence grade, which is the difference between advice an MSP can apply to a client and advice they have to throw away. Run a free Waste Check to see which of your accounts are carrying Hot-tier data nothing reads.

What is the bottom line?

The SKU is a durability decision; the access tier is the cost decision. Tier containers to match how often the data is read, automate it with lifecycle rules, and touch replication only with the DR owner in the room.