Azure Backup Cost Trap: Why You Overpay 2x on Storage Redundancy (and How to Fix It)

Every few months I sit down with a customer's Azure Cost Management export and go hunting for the line items nobody watches. Compute gets reviewed. Networking gets questioned. But backup storage quietly grows month after month, because it was configured exactly once — on day one, by whoever stood up the landing zone — and never touched again.

The most common finding is boring and expensive: most vaults I audit are still running on Geo-Redundant Storage (GRS), the default. That one checkbox the team never changed is doubling their backup storage bill, and in most cases buying them protection they cannot even use.

This is the most repeatable cost optimization I know of in Azure Backup. It requires no architecture change, no new tooling, and no migration project — just an audit and a handful of deliberate decisions. Here is how the trap works and how to fix it.

The GRS Default Trap

When you create a Recovery Services vault and start protecting workloads, Azure sets the vault's storage redundancy to GRS unless you explicitly choose otherwise. GRS replicates every byte of backup data three times within the primary region and three more times in a secondary location hundreds of kilometers away.

That sounds like exactly what backup should do. The problem is the price, and the fact that the geographic copy is largely decorative for most tenants.

What you are actually paying for

Azure Backup storage is billed per GB-month at rates that depend on the redundancy option. The figures below are verified against the Azure Retail Prices API for Southeast Asia in August 2026 (GRS is only offered in paired regions — more on that below):

GRS costs exactly 2x LRS. At 10 TB that is roughly $2,750 a year of pure overhead. At 100 TB — a typical number once VM backups, SQL backups, and file shares accumulate — the overpayment is around $27,500 a year. Every year. For a copy of the data that most organizations will never restore from.

Why GRS is wrong for most backup vaults

The pitch for GRS is geographic survival: if the entire primary region fails, your backups exist somewhere else. Analyze that claim before paying for it:

1. Azure region-wide outages are exceptionally rare. Regions fail over individual services occasionally; total region loss is a once-in-a-blue-moon event. The failure modes you actually experience — disk failure, datacenter failure, accidental deletion, ransomware — happen inside the region.
2. Cross-region restore is not a failover. Restoring from the secondary copy is a manual, slow operation: items can take up to 48 hours to become available in the secondary region, and you restore into a region where your production network, identity configuration, and dependent services do not exist.
3. Your production is probably not cross-region either. If your workloads run in one region and only the backups replicate elsewhere, a regional disaster leaves you with restored VMs in a region that has nothing to connect to. Real cross-region DR is a workload replication decision (Site Recovery, traffic manager, multi-region design) — not a backup storage decision.
4. Within-region redundancy is where the real protection lives. LRS keeps three synchronous copies in one datacenter. ZRS spreads copies across availability zones in the region. For the failures that actually occur, ZRS at 1.25x the LRS price is usually the sensible middle ground — not GRS at 2x.

The Malaysia West twist

Here is the detail that changes the story for Malaysian tenants. Cross-region restore — the feature that justifies paying for GRS — restores into your region's Azure paired region. But Malaysia West is a nonpaired region: Microsoft's official region list shows Malaysia West with no paired region at all.

It goes further than that. I checked the Azure Retail Prices API (August 2026), and there is no GRS backup storage meter for Malaysia West at all — the backup storage SKUs offered there are LRS, ZRS, and archive. GRS backup storage is simply not sold in nonpaired regions, because there is no pair to replicate to.

So Malaysia West tenants are protected from this trap by the platform itself: you could not pay the GRS premium on a Malaysia West vault even if you wanted to. The trap reappears the moment your organization runs vaults in paired regions — and most Malaysian enterprises do, because Southeast Asia (Singapore) and East Asia (Hong Kong) were the default landing zones for years before Malaysia West opened. In those regions GRS is available at exactly the 2x price, and cross-region restore genuinely works — restoring into the pair (Southeast Asia ↔ East Asia). If your production sits in Southeast Asia and your vault is still on GRS, you are paying double for a copy that restores into a region where your network, identity, and applications do not live.

The audit to run: list every vault, note its region, and check whether the region is paired. Nonpaired-region vaults can only be LRS or ZRS — the question there is whether you need zone redundancy. Paired-region vaults are where the GRS decision actually applies.

When GRS is actually right

To be fair, GRS has legitimate use cases:

• Regulatory or contractual requirements that mandate geographically separated backup copies.
• Paired-region DR designs where you already run cross-region infrastructure and cross-region restore genuinely slots into your recovery plan.
• Irreplaceable data with no other protection — the last copy of something that must survive a regional event at any cost.

If none of those apply to a given workload, LRS or ZRS protects it at half the price.

The Fix: A Six-Lever Backup Cost Audit

Storage redundancy is the biggest lever, but it is not the only one. When I audit a tenant's backup estate, I work through six.

1. Set vault redundancy deliberately

First, find out what you have. This bash sweep lists every Recovery Services vault in the subscription with its redundancy and cross-region restore state:

#!/bin/bash
# Sweep: every Recovery Services vault and its storage redundancy
az backup vault list --query "[].{name:name, rg:resourceGroup}" -o tsv |
while read -r name rg; do
  az backup vault show --name "$name" --resource-group "$rg" \
    --query "properties" -o json | python3 -c "
import sys, json
p = json.load(sys.stdin)
rd = p.get('redundancyDetails') or p.get('redundancySettings') or {}
print('$name | $rg | redundancy=%s | crossRegionRestore=%s' % (
    rd.get('redundancy', 'unknown'), rd.get('crossRegionRestore', 'n/a')))
"
done

For vaults that do not yet protect anything, you can set the redundancy directly:

az backup vault update \
  --name rsv-backup-prod-myw \
  --resource-group rg-backup \
  --backup-storage-redundancy LRS \
  --cross-region-restore Disabled

(Flags evolve — run az backup vault update -h against your CLI version. The constraint that matters is constant: this only works before items are protected. See the pitfalls section.)

If you deploy vaults as code, make the decision explicit so nobody inherits the default by accident. Terraform:

resource "azurerm_recovery_services_vault" "backup" {
  name                = "rsv-backup-prod-myw"
  resource_group_name = azurerm_resource_group.core.name
  location            = "malaysiawest"
  sku                 = "Standard"

  # Deliberate choice, not the GRS default
  storage_mode_type            = "LocallyRedundant"
  cross_region_restore_enabled = false
}

Or Bicep:

resource backupVault 'Microsoft.RecoveryServices/vaults@2024-04-01' = {
  name: 'rsv-backup-prod-myw'
  location: 'malaysiawest'
  sku: { name: 'Standard' }
  properties: {
    redundancySettings: {
      redundancy: 'LocallyRedundant'
      crossRegionRestore: 'Disabled'
    }
  }
}

2. Tier retention by workload criticality

One-size-fits-all retention is the second silent cost. The default Azure VM policy keeps daily recovery points for 30 days and weekly points for 4 weeks, and many teams layer on monthly and yearly schedules at maximum retention for every workload — including dev/test VMs nobody would ever restore.

A simple three-tier model usually cuts retained data by a third or more:

The practical workflow: export the policy, edit retention, reapply.

# Export, edit, reapply a backup policy
az backup policy show \
  --vault-name rsv-backup-prod-myw \
  --resource-group rg-backup \
  --name StandardVMs > policy.json

# Edit policy.json: reduce daily retentionDuration,
# trim or remove yearly schedule for this tier

az backup policy set \
  --vault-name rsv-backup-prod-myw \
  --resource-group rg-backup \
  --name StandardVMs \
  --policy @policy.json

3. Archive long-term recovery points

For the yearly and compliance copies you must keep but will almost never touch, the archive tier is the biggest price drop in Azure Backup: roughly $0.0027 per GB-month versus $0.0224 for standard LRS — about an 8x reduction. The trade-offs are a 180-day minimum retention and rehydration time measured in hours when you do restore, which makes it exactly right for regulatory long-term copies and exactly wrong for operational recovery points.

One interaction to plan for: archive tier is not supported on vaults configured with ZRS — it requires LRS or GRS. Redundancy and archive decisions are not independent knobs; make them together per vault. A vault you already moved to ZRS cannot use archive tier, and a vault you plan to archive heavily may be better kept on LRS than pushed to ZRS.

4. Trim instant-restore retention

Instant restore keeps local snapshots alongside vaulted backups so recent restores are fast. The retention window is 1 to 5 days and defaults to 2. Every extra day is extra snapshot storage billed for every protected VM. For non-critical workloads, 1 day is usually enough; keep the longer window only for the systems where same-day restore speed genuinely matters.

5. Right-size Site Recovery scope

Azure Site Recovery (ASR) is DR replication, not backup — and it is billed per protected instance (around $25 per month each, plus the storage the replicas consume). The trap is enabling it for every VM because "DR" appeared in a requirements document. Replicate only the workloads with a real cross-region RPO/RTO commitment. A dev/test VM with a backup and no replica is not a DR gap — it is correct scoping.

6. Make backup cost visible

Costs you cannot see do not get managed. Pull backup spend per resource with the Cost Management API so it shows up in your regular reporting:

from azure.identity import DefaultAzureCredential
from azure.mgmt.costmanagement import CostManagementClient

cred = DefaultAzureCredential()
client = CostManagementClient(cred)

query = client.query.usage(
    "/subscriptions/<subscription-id>",
    {
        "type": "Usage",
        "timeframe": "MonthToDate",
        "dataset": {
            "granularity": "None",
            "aggregation": {"totalCost": {"name": "Cost", "function": "Sum"}},
            "grouping": [{"type": "Dimension", "name": "ResourceName"}],
            "filter": {
                "dimension": {
                    "name": "ServiceName",
                    "operator": "In",
                    "values": ["Backup"],
                }
            },
        },
    },
)

for row in sorted(query.rows, key=lambda r: r[1], reverse=True):
    print(f"{row[2]:>10.2f} USD  {row[0]}")

Pair this with a monthly budget alert on the backup cost line so growth gets noticed when it is 5 percent, not 50.

Pitfalls That Bite During the Cleanup

• Redundancy is locked once items are protected. You cannot switch a vault from GRS to LRS after backup items exist. The fix is a new vault with the correct redundancy and a cutover of protection — plan it as a small migration, not a setting change.
• Cross-region restore cannot be reverted. Once enabled, CRR stays enabled. Treat it as a one-way decision and get sign-off before flipping it on.
• Nonpaired regions have no GRS at all. Malaysia West is nonpaired, and the Retail Prices API confirms no GRS backup storage meter exists there — only LRS, ZRS, and archive. The GRS trap applies to vaults in paired regions (for Malaysian organizations, typically Southeast Asia ↔ East Asia), where CRR restores into the pair.
• Archive tier and ZRS are mutually exclusive. Archive requires an LRS or GRS vault; it is unavailable on ZRS vaults. Decide redundancy and archive together per vault.
• Archive tier is not for operational recovery. The 180-day minimum retention and hours-long rehydration mean archiving the wrong tier of recovery points can hurt you during a real incident.
• Do not double-pay for protection. Backup plus ASR on the same VM is correct only when the workload needs both point-in-time recovery and cross-region failover. Everywhere else it is duplicate billing.
• Prices vary by region. The rates above are verified against the Azure Retail Prices API for Southeast Asia in August 2026. Confirm your region's rates in the Azure Pricing Calculator before quoting savings to your CFO.

Key Takeaways

1. The GRS default doubles backup storage cost. If nobody has ever touched your vault settings, you are likely paying it. LRS or ZRS covers the failure modes that actually happen at half the price.
2. Malaysia West tenants are protected by the platform — their paired-region vaults are not. GRS backup storage is not even offered in nonpaired Malaysia West. The trap lives in the paired-region vaults (Southeast Asia, East Asia) that most Malaysian enterprises have been running for years.
3. Cross-region restore is not disaster recovery. Real DR replicates workloads and networking; a geo-redundant backup copy restored into an empty region is a migration, not a failover.
4. Retention tiering plus archive tier cuts another 30-50%. Match retention to workload criticality, and push compliance-only yearly copies to the archive tier at roughly 8x less than standard storage — on LRS/GRS vaults, since archive and ZRS do not mix.
5. Audit quarterly and govern by policy. Backup data only grows. Enforce redundancy and retention decisions in Terraform or Bicep, and put backup cost on a monthly alert before it becomes another surprise line item.

None of this is architecturally exciting. That is precisely why it works: the savings come from reversing a default, not from a project. Find your vaults, make the redundancy decision deliberately, tier the retention, and put a number on it. Most tenants I have walked through this audit cut backup storage spend roughly in half — and the whole exercise takes less time than one incident review.