MySQL Flexible Servers on General Purpose compute that barely use CPU or memory

Paying for sustained CPU a quiet server never uses

Azure Database for MySQL Flexible Server runs on three compute tiers, and the service tiers page maps them to VM families: Burstable on B-series, General Purpose on D-series, and Memory Optimized on E-series. General Purpose and Memory Optimized give you the full vCores all the time. Burstable gives a baseline share of CPU and a credit balance that builds up while the server is below baseline and is spent when it bursts.

A development or reporting database that idles most of the day is exactly the workload Burstable is priced for. Keeping it on a D- or E-series SKU means paying for sustained CPU that the metrics show it never uses.

Reading utilization and SKU for your Flexible Servers

List servers with their current tier and SKU, then pull 30 days of CPU and memory for a candidate:

az mysql flexible-server list \
  --query "[].{name:name, rg:resourceGroup, tier:sku.tier, sku:sku.name}" -o table

az monitor metrics list \
  --resource /subscriptions/<sub>/resourceGroups/my-rg/providers/Microsoft.DBforMySQL/flexibleServers/my-server \
  --metric cpu_percent memory_percent --aggregation Average Maximum \
  --interval PT24H --offset 30d

Look at the daily maximum as well as the average. A server with a low average and a high daily peak is burning through bursts that Burstable may not be able to fund.

Utilization gates and the same-size target

ZopNight raises this recommendation when all of the following hold:

1. Azure Monitor has CPU and memory data for the server; without it there is no finding.
2. Average CPU over 30 days is below 30% and average memory is below 50%. This applies to any server, not only ones with dev or test in the name.
3. The current SKU is a General Purpose D-series size with a clean Burstable equivalent at the same vCPU count: 2 vCores map to Standard_B2s, 4 to Standard_B4ms, 8 to Standard_B8ms, 16 to Standard_B16ms and 20 to Standard_B20ms.
4. High availability is off, because the Burstable tier does not support it.
5. The memory the server actually uses, worked out from its average memory percentage, still fits in the Burstable target’s smaller RAM with headroom to spare.

Naming a specific target matters. The recommendation never says “move to Burstable” in the abstract and never proposes a smaller vCPU count.

Servers this check passes over

One-vCore servers and SKUs outside the D family have no clean same-size Burstable target, so they are skipped. Memory Optimized E-series servers are skipped too: a same-vCPU Burstable size has far less memory, so a low memory percentage on the source does not prove the target is safe. The rule also needs a trustworthy price for the source SKU and the Burstable target under Azure Database for MySQL itself. Virtual machine rates for similarly named SKUs are a different product and are never substituted; if the Flexible Server rates cannot be resolved, or the target is not cheaper, ZopNight raises no finding at all. Those Flexible Server rates are not yet available to the check, so today it stays silent rather than show a figure priced against the wrong product.

Working out the saving from two compute rates

monthly saving = current monthly cost x (1 - Burstable rate / current SKU rate)

Both rates are hourly compute rates for the same region. There is no flat percentage fallback: if either rate is missing, or the Burstable rate is not lower, there is no recommendation.

Moving a server to Burstable safely

1. Confirm the workload’s peaks, not just its averages, in Azure Monitor.
2. Read the credit caveats. Microsoft notes that Burstable is designed for nonproduction work, does not qualify for 24/7 support or root cause analysis, and that a server that exhausts its credits is held to baseline CPU and can become unreachable.
3. Change the compute tier in a maintenance window: az mysql flexible-server update --resource-group my-rg --name my-server --tier Burstable --sku-name Standard_B2s.
4. Watch CPU and connection errors for a week.