Azure storage redundancy cost: LRS vs ZRS vs GRS explained

Quick answer

Azure storage redundancy sets how many copies of your data are kept and where. LRS (locally redundant) keeps three copies in one datacenter and is the cheapest, around $0.018 per GB per month for hot blob. ZRS (zone-redundant) spreads copies across availability zones for roughly 25 percent more. GRS (geo-redundant) replicates to a second region and roughly doubles the LRS price, and RA-GRS adds read access to the secondary for a little more. The rule: use LRS unless you specifically need zone or regional durability, and never pay for GRS on data you can regenerate.

Every Azure storage account has a redundancy setting, and it is one of the most overlooked cost multipliers on the platform. The same gigabyte of blob data can cost anywhere from the LRS baseline to double that under GRS, depending purely on how many copies Azure keeps and how far apart. Choosing redundancy by durability need rather than by default saves real money on large accounts.

What each option keeps

Option	Copies / location	Relative cost
LRS	3 copies, one datacenter	Baseline (~$0.018/GB hot)
ZRS	3 copies across zones	~25% more than LRS
GRS	LRS plus a second region	~2x LRS
RA-GRS	GRS with readable secondary	Slightly above GRS

LRS keeps three synchronous copies within a single datacenter, protecting against disk and node failure. ZRS spreads three copies across separate availability zones in the region, surviving a full datacenter outage. GRS layers geo-replication to a paired region hundreds of miles away, protecting against a regional disaster, and RA-GRS makes that secondary copy readable. Each step up buys more resilience and costs more.

The cost multiplier in practice

On 10 TB of hot blob data, LRS costs roughly $180 per month. ZRS pushes that to about $225, and GRS to about $360, double the LRS figure, because you are storing and replicating a full second copy in another region. RA-GRS adds a little more for read access to the secondary. Multiply across a large account or many accounts and the redundancy choice becomes a four or five figure monthly decision.

Matching redundancy to the data

The mistake is applying GRS everywhere out of caution. Ask what happens if the data is lost. Logs, caches, temporary artifacts, and anything you can regenerate need only LRS, since regional durability adds cost without adding value you would ever use. Business-critical data that must survive a regional outage justifies GRS. Data that needs to survive a zone failure but not a regional one fits ZRS. Set redundancy per storage account by the value of what it holds, the same tiering discipline as the blob access tiers guide.

Redundancy and access tiers combine

Redundancy multiplies whatever access tier you are on. Cool and archive tiers cost less per GB than hot, and the redundancy multiplier applies on top, so moving cold data to a cheaper tier and keeping it on LRS compounds the savings. Egress from a GRS secondary and geo-replication traffic also add data-transfer cost, one of the charges covered in the egress bandwidth guide. Lifecycle policies can move data down tiers automatically, as the lifecycle cost guide explains.

Choosing redundancy on cost

Default to LRS, upgrade to ZRS only where zone resilience is required, and reserve GRS for data whose loss in a regional disaster would genuinely hurt the business. Review existing accounts, since many carry GRS set long ago and never revisited. Price the redundancy option against the resource catalog before you deploy so the doubling from LRS to GRS is a deliberate choice, not an inherited default.

FAQ

What is the difference between LRS, ZRS, and GRS?

LRS keeps three copies in one datacenter, protecting against disk and node failure, and is cheapest. ZRS spreads three copies across availability zones, surviving a datacenter outage, for roughly 25 percent more. GRS replicates to a paired region hundreds of miles away, protecting against regional disaster, and roughly doubles the LRS cost. RA-GRS adds read access to the secondary for a little more.

How much more does GRS cost than LRS?

Roughly double. On 10 TB of hot blob, LRS costs about $180 per month while GRS costs about $360, because GRS stores and replicates a full second copy in another region. ZRS sits in between at about $225. Across large accounts the redundancy choice becomes a four or five figure monthly decision, so it is worth matching to actual durability needs.

When should I use LRS instead of GRS?

Whenever the data does not need to survive a regional disaster. Logs, caches, temporary artifacts, and anything you can regenerate need only LRS, so paying the GRS premium on them wastes money without adding value you would ever use. Reserve GRS for business-critical data whose loss in a regional outage would genuinely hurt, and use ZRS where only zone resilience is required.

Does redundancy cost combine with access tiers?

Yes. The redundancy multiplier applies on top of whatever access tier you use, so cool and archive data on LRS is much cheaper than hot data on GRS. Moving cold data to a cheaper tier and keeping it on LRS compounds the savings. Geo-replication and reads from a GRS secondary also add data-transfer charges beyond the storage cost itself.

How does C3X help with storage redundancy cost?

C3X prices Azure storage accounts from Terraform before you deploy, including the redundancy setting, so the difference between LRS, ZRS, and GRS is visible in the pull request. That lets you match redundancy to the value of the data at design time and avoid inheriting an expensive GRS default on data that only needs local redundancy.

What to do next

Choose storage redundancy deliberately before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.