Production Cloud SQL running in a single zone
What does ZopNight detect here?
Production Cloud SQL instances with availabilityType ZONAL have no standby and no automatic failover. A zone outage takes the database down with it. ZopNight classifies production from names and env labels, fires only on a positively-recorded single-zone posture, and notes REGIONAL HA costs about 2x the compute by design.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1240 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | cloudsql_ha.go |
Where it applies
ZONAL means one zone, one failure domain
Cloud SQL’s availabilityType is binary: REGIONAL runs a synchronous standby in a second
zone with automatic failover in typically 60 seconds or so; ZONAL runs one instance in
one zone, and a zone-level incident means the database is down until the zone returns or
someone restores from backup. For a production system the second posture is an
availability decision someone should have made deliberately. This rule exists for the
many cases where it was simply the default nobody revisited.
How production is inferred
Two signals classify an instance as production: a name containing prod, production, or
live, or an env-style label (env, environment, stage, tier) carrying a production value.
The label is read from the nested labels object the GCP discoverer captures, the
authoritative sink for customer labels on GCP resources. The HA posture itself is read in
order of explicitness: the recorded multi-zone booleans first, then the raw
availabilityType enum, where any non-empty value other than REGIONAL counts as
single-zone.
The cost of the standby
Honesty about the trade: enabling HA runs a full standby, so compute cost roughly doubles (about 2x), and the change itself involves a brief restart. That is the correct spend for a database whose zone outage would page someone, and precisely the wrong spend for the dev instance that got HA by copy-paste; the inverse of this rule is real too, which is why the classification gate matters.
Read the availability type
gcloud sql instances describe my-instance \ --format="value(settings.availabilityType)"ZONAL on anything production-shaped reproduces this finding; enabling HA is Edit →
High Availability in the console, or gcloud sql instances patch --availability-type REGIONAL.
Unknown posture stays unflagged
The rule fails closed twice over. Instances that match neither the name pattern nor a production label are never evaluated, and instances whose availability metadata was never recorded produce nothing; an unknown HA posture is not treated as missing HA. As a compliance finding it carries no dollar figure; the remediation spends money rather than saving it, on purpose.