Azure waste

Zone redundancy on a non-production SQL database

A SQL database or elastic pool with zone redundancy switched on in a non-production environment, paying a separate per-vCore meter for an availability guarantee nobody there is going to invoke.
The agent reports this
Reversible
Why it happens

Azure bills zone redundancy on SQL as its own line rather than folding it into the compute rate: a Zone Redundancy vCore meter sits beside the plain vCore one and is charged for every vCore of the database or pool, so it scales with size. On a development or test database it buys a guarantee against the loss of an availability zone, which is a thing nobody is going to fail over to in that environment. The rule reports a database or pool whose zone redundancy flag is set, and nothing in the rule decides what non-production means: the environment scope filter does that from policy, and the environment tag travels on the finding only so a person reading the audit trail can see what it was. The figure is the zone redundancy meter for that exact size, which is what Azure charges for the option, and not an estimate of what an outage would cost, which is a different question this cannot answer. It reports rather than acts, because turning zone redundancy off is not a settings toggle on every tier and where it is available it is an operation with a service impact.

Paste this into Resource Graph Explorer in the Azure portal.

resources
| where type in~ ('microsoft.sql/servers/databases', 'microsoft.sql/servers/elasticpools')
// Scope below matches CloudFinOpsPro policy DEFAULTS: exclusions.protectTag, environment.tagKeys,
// environment.allowedTagValues, and allowUntagged false so an untagged resource counts as production.
// If your policy.yaml differs, edit the three lines below or this will disagree with your own agent.
| where tolower(tostring(coalesce(tags['cfop:protect'], ''))) !in ('true', 'yes', '1')
| extend cfopEnv = tolower(trim(' ', tostring(coalesce(tags['Environment'], tags['environment'], tags['env'], ''))))
| where cfopEnv in ('dev', 'development', 'test', 'qa', 'sandbox', 'nonprod', 'non-prod', 'staging')
| where properties.zoneRedundant == true
| extend scope = iff(type =~ 'microsoft.sql/servers/elasticpools', 'pool', 'single')
| project name, resourceGroup, location, scope,
          sku = tostring(sku.name), tier = tostring(sku.tier), environment = cfopEnv

Elastic pools are listed alongside single databases because the check scans both and labels each finding pool or single, which is why this query projects the same scope column. Zone redundancy is a single boolean and it bills a separate premium per vCore on top of the compute. The non-production half of this check is the environment scope above, the same filter the agent applies.

Applies to microsoft.sql/servers/databases
What the agent does about it

A SQL database or elastic pool with zone redundancy switched on in a non-production environment, paying a separate per-vCore meter for an availability guarantee nobody there is going to invoke.

It will not fix this one

It reports this and takes no action. A check only earns the right to change something once the action behind it can re-read live state before it fires and knows the way back.