High availability on a non-production PostgreSQL server

Paste this into Resource Graph Explorer in the Azure portal.

resources
| where type =~ 'microsoft.dbforpostgresql/flexibleservers'
// 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')
// mode is Disabled, ZoneRedundant or SameZone and DEFAULTS to Disabled, so an absent value means
// off. BOTH non-disabled modes provision a standby, so both are matched: the ARM spec says the
// standby is "created when high availability is set to SameZone or ZoneRedundant".
| extend haMode = tostring(properties.highAvailability.mode)
| where haMode in~ ('ZoneRedundant', 'SameZone')
// Deliberately no dollar arithmetic. The compute rate is read live by the agent so it cannot go
// stale here, and the standby costs one server's compute.
| project name, resourceGroup, location, haMode,
          sku = tostring(sku.name), tier = tostring(sku.tier),
          haState = tostring(properties.highAvailability.state), environment = cfopEnv

Enabling high availability provisions a warm standby, and Microsoft states it is deployed in the same VM configuration as the primary server, including vCores, storage and network settings. Verified against the retail API, there is no high-availability meter at all: 120 flexible-server items in East US across 20 products, none of them naming HA. So the standby is not a surcharge, it is a second server billing the same compute meter as the first, and turning HA on doubles the compute line. Both modes are matched, not just ZoneRedundant, because the ARM specification says the standby is created when high availability is set to SameZone or ZoneRedundant; SameZone buys less resilience for the same money. This query deliberately returns the setting rather than a dollar figure, because a rate written into a published query goes stale the day Azure reprices. Unlike some redundancy settings the remedy here is a switch: Microsoft documents enabling and disabling high availability on an existing server. This is a structural test, so what it returns is what the check reports.