Stop Trying to "Lower the SKU" on Your Azure Storage Account

A common piece of bad advice from cloud cost tools: "Lower the pricing tier (SKU) on your storage account to save money." It sounds reasonable — and it is wrong. Azure Storage Account SKUs do not work the way a VM SKU does.

What the storage SKU actually controls

A Storage Account SKU is a combination of performance (Standard or Premium) and replication (LRS, ZRS, GRS, GZRS, RAGRS, RAGZRS). For example: `Standard_LRS, Premium_ZRS`.

• Performance tier (Standard vs Premium) is mostly immutable after creation — you cannot just downgrade.
• Replication tier (LRS, GRS, etc.) controls how many copies of your data Azure keeps and where. Going from GRS to LRS roughly halves the storage cost — but you lose cross-region redundancy. That is a real durability tradeoff, not a free win.

So if a tool says "lower the SKU to save money" without qualifying the redundancy tradeoff, you are being told to silently downgrade your disaster-recovery posture. That is not optimization. That is a future incident.

The actual cost lever: blob access tier per container

Storage Account billing has three big drivers:

• Data volume stored (GB-months) — this is usually most of the bill.
• Transactions (reads, writes, list operations) — varies wildly by workload.
• Egress (data leaving the region) — important if you are serving the data to external systems.

The lever that meaningfully changes the storage cost without changing your durability story is the blob access tier, set per container or per blob:

• Hot — default. Cheapest reads/writes, most expensive storage. Use for active data.
• Cool — storage ~50% cheaper than Hot, but per-GB read fees and a 30-day minimum retention. Use for backups accessed monthly.
• Cold — storage cheaper still, 90-day minimum retention, higher access fees. Good for compliance archives you might pull once a quarter.
• Archive — storage roughly 90% cheaper than Hot. But: data is offline and takes hours to rehydrate. Use for long-term retention you genuinely will not touch in normal operations.

Switching a container of rarely-accessed backups from Hot to Cold typically cuts that data's monthly storage cost in half. Moving truly cold compliance data to Archive cuts it by ~90%. The catch is access pattern: if you read it more than a few times a month, the access fees on Cool / Cold / Archive can wipe out the savings. The tier should match the workload, not just the number on the bill.

A quick decision flow

• Is the data read more than once a week? Hot.
• Is it read a couple of times a month? Cool.
• Is it read once a quarter at most, but might be needed in minutes? Cold.
• Is it long-term archive you accept waiting hours to rehydrate? Archive.

For the replication SKU: only consider GRS → LRS if your DR plan does NOT require automatic cross-region failover for this data. If you are not sure, leave it alone.

What CloudRift recommends instead

CloudRift's explainer for a Storage Account does not say "lower the SKU." It says: "Storage costs come from data volume × access frequency, not the account SKU. If the data is rarely accessed, change the blob access tier per container to Cool or Cold (or Archive for long-term retention). The account replication SKU controls redundancy; switching it reduces cost but lowers durability guarantees, so only do it if you do not need cross-region replication."

That is the difference between a recommendation an MSP can confidently apply to a client and one they have to throw away.