Dev and test storage accounts paying for geo-redundant replication

A second region for data nobody needs twice

Microsoft’s redundancy overview describes the options. LRS keeps copies in a single datacenter in the primary region and is the lowest-cost option, with at least eleven nines of durability over a year. GRS keeps LRS copies in the primary region and then copies the data asynchronously to a secondary region; GZRS does the same after replicating across availability zones first. The same page suggests LRS when data can be easily reconstructed if it is lost, which describes most dev and test data.

Accounts get GRS when they are created from a production template or when geo-redundancy is simply the default someone picked. For scratch data, build artifacts and test fixtures, the second-region copy is a cost with no user.

Listing geo-redundant accounts

az storage account list \
  --query "[?contains(sku.name, 'GRS') || contains(sku.name, 'GZRS')].{name:name, group:resourceGroup, sku:sku.name}" \
  -o table

Check the names and owners in the list. The SKU suffix is the replication type: Standard_GRS, Standard_RAGRS, Standard_GZRS or Standard_RAGZRS.

Name and replication checks

1. The account name contains dev, test, qa, staging, sandbox or demo. Names that contain infrastructure words such as devops, runner, agent, bastion or jumpbox are not treated as dev or test. Only the name is used for this rule, not tags.
2. The replication type, read from the account’s SKU, is GRS, RA-GRS, GZRS or RA-GZRS. If it cannot be read, there is no finding.
3. The account has a price.
4. A real geo-replication premium can be computed for it: the gap between the geo-redundant rate and the base LRS rate for the data stored.

When the rule says nothing

Accounts already on LRS or ZRS are out of scope. A geo-redundant account without a dev or test name is not flagged, however little it is used. If the premium cannot be computed, because the geo-redundant rate is missing or not above the base rate, there is no finding; ZopNight never falls back to a flat share of the bill. For quiet accounts of any kind, see Idle Azure Storage Account.

Pricing the switch to LRS

saving = (geo-redundant rate - LRS rate) x stored GB x 730 hours, capped at the account's cost
cost after fix = current cost - saving

Switching a dev account to LRS

1. Confirm the account is non-production and that nothing reads from its secondary endpoint.
2. For GRS or RA-GRS, change it directly: az storage account update --resource-group <rg> --name <account> --sku Standard_LRS.
3. For GZRS or RA-GZRS, Microsoft’s redundancy change guide says any change that involves zone redundancy needs a separate conversion, done as a two-step process whose two steps (dropping geo-redundancy and converting from zone-redundant to locally redundant) can run in either order.