Explanation
Why the waste happens and who it affects.
Geo-redundant options (GRS, RA-GRS, GZRS and RA-GZRS) replicate the account to a secondary region, so capacity is priced higher than LRS or ZRS and every write also incurs geo-replication bandwidth charges. Microsoft lists the options from least to most expensive as LRS, ZRS, GRS, RA-GRS, GZRS and RA-GZRS.
Geo-redundancy is often applied by default in templates to accounts that do not need regional disaster recovery: development and test accounts, scratch and staging data, logs, build artifacts, data that can be regenerated from a source system, and data that is already protected by a separate backup or replication process. The read-access variants add cost again even when no application ever reads from the secondary endpoint. Microsoft's redundancy documentation says LRS is a good choice when data can be easily reconstructed, and the Well-Architected guidance for Blob Storage notes that GRS and GZRS cost significantly more than LRS and that LRS might provide sufficient protection for applications that can tolerate some data loss or have alternative backup strategies.
Billing model
The pricing dimensions that drive this cost.
Redundancy affects several storage meters.
- Capacity by redundancy
- Stored data is billed per GB-month at a rate that depends on the redundancy option, rising from LRS to ZRS, GRS, RA-GRS, GZRS and RA-GZRS
- Geo-replication data transfer
- Accounts with geo-redundancy pay a per-GB egress charge to replicate writes to the secondary region
- Read-access premium
- RA-GRS and RA-GZRS cost more than their non-read-access equivalents
- RA removal billing
- After removing read access (RA-GRS to GRS or LRS), the account is billed as RA-GRS for an additional 30 days
How to detect
5 checks to find it in your estate.
- Query Azure Resource Graph for microsoft.storage/storageaccounts where sku.name is Standard_GRS, Standard_RAGRS, Standard_GZRS or Standard_RAGZRS, and join with subscription, resource group and tags to flag non-production and scratch accounts
- For RA-GRS and RA-GZRS accounts, check whether any application is configured to read from the secondary endpoint; if none is, the read-access premium buys nothing
- Review Cost Management by meter for geo-replication data transfer charges on accounts that hold non-critical or reproducible data
- Identify accounts whose data is already protected elsewhere, for example by Azure Backup vaulted backup, object replication or an upstream system of record
- Use Azure Storage Discovery or Storage insights to review redundancy configuration across the estate, as suggested in the Well-Architected Blob Storage guidance
How to fix
5 ways to remove the waste.
- Change the redundancy of accounts that do not need regional recovery from GRS or RA-GRS to LRS in the portal (Data management, Redundancy), with az storage account update --sku, or with Set-AzStorageAccount -SkuName; removing geo-redundancy has no conversion cost but deletes the secondary copy
- Where zone resilience is still required, move to ZRS; from GRS this is a two-step change (switch to LRS, then run a conversion to ZRS), and from GZRS it is a switch to ZRS
- Drop the read-access variant (RA-GRS to GRS, RA-GZRS to GZRS) where the secondary endpoint is unused, allowing for the 30 days of continued RA-GRS billing
- Check limitations before converting: conversions to zone-redundant options are not supported for archive-tier blobs, some account types and NFS-enabled accounts, and a zone conversion has no completion SLA
- Set template defaults and an Azure Policy that restricts geo-redundant SKUs to accounts with a documented recovery requirement
Documentation
Vendor references for pricing and configuration.