# Azure MySQL Flexible Server Burstable Tier Opportunity > 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. Source: https://zop.dev/integrations/azure/recommendations/azure-mysql-flexible-server-burstable-tier-opportunity Updated: 2026-08-19 --- ## 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 ```bash az monitor metrics list --resource \ --metric cpu_percent memory_percent \ --aggregation Average --interval PT1H --offset 30d \ --query "value[].{metric:name.value, avg:avg(timeseries[0].data[].average)}" -o table ``` If 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.