Underutilized MySQL Flexible Servers that could run on the Burstable tier
What does ZopNight detect here?
RC-244 identifies MySQL Flexible Servers averaging under 30% CPU and under 50% memory over 30 days as Burstable-tier candidates, mapping D-family SKUs to same-vCPU targets like Standard_B2s. Today the rule always abstains: the aggregator's SKU-rate lookup would price the switch against unrelated Virtual Machines rates, so no recommendation is emitted.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-244 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Source | flexserver_burstable.go |
Where it applies
A rule that currently emits nothing, on purpose
Be clear about the present state: RC-244 always abstains today. Its savings function is permanently disabled because the pricing lookup it needs is unsafe: the SKU tokens involved (“Standard_D2ds_v4” as source, “Standard_B2s” as target) are VM-style strings, and the aggregator’s rate table resolves them by string match with no service dimension. The only rows matching those tokens come from the Virtual Machines price sheet, not from Azure Database for MySQL. Any dollar figure computed from them would be a cross-service price collision: plausible-looking, wrong basis. Under ZopNight’s concrete-or-abstain principle, the rule stays registered but silent until the aggregator ingests properly-scoped Flexible Server rates.
The detection logic is still worth knowing
When the pricing gap closes, here is what fires. Utilization is the only path: average CPU
under 30% and average memory under 50% over a 30-day Azure Monitor window
(MySQLCpuPercent and MySQLMemoryPercent, read via Monitoring Reader). A name-based
“looks like dev/test” shortcut used to exist and was removed after it once put a fabricated 40%
saving on a production-named server with no evidence.
Same-vCPU targets, never a downsize in disguise
Only general-purpose D-family SKUs map to a concrete Burstable target: 2 vCPU → Standard_B2s, 4 → B4ms, 8 → B8ms, 16 → B16ms, 20 → B20ms. Memory-optimized E-family servers are excluded because a same-vCPU Burstable target carries a fraction of their RAM (16 GiB → 4 GiB at 2 vCPU) and no relative-utilization gate can prove that safe. A further absolute-memory floor requires the target’s fixed RAM to cover observed used memory with a 1.25× headroom factor. One-vCPU servers, unknown families, servers already on Burstable, and servers with High Availability enabled (the Burstable tier cannot run HA) all abstain.
Estimate the fit yourself while the rule sleeps
az monitor metrics list --resource <flexible-server-id> \ --metric cpu_percent memory_percent \ --aggregation Average --interval PT1H --offset 30d \ --query "value[].{metric:name.value, avg:avg(timeseries[0].data[].average)}" -o tableIf CPU sits under 30% and memory under 50%, compare your SKU against the same-vCPU B-series price in the Azure pricing calculator. That comparison, done by hand against the correct MySQL price sheet, is exactly what the rule refuses to automate with wrong-product rates.
Why keep a silent rule published
The gating logic (HA exclusion, same-size mapping, OOM headroom) was audited and is correct. Deleting the rule would discard that; keeping it registered means one function change re-enables it the day trustworthy rates exist.