Production MySQL Flexible Servers busy enough to justify a 1-year reserved capacity purchase

What MySQL reserved capacity covers

Reserved capacity for Azure Database for MySQL Flexible Server is a one- or three-year prepayment on compute. You buy a quantity of vCores for a region, deployment type and performance tier, and any running server that matches picks up the discounted rate automatically; nothing is assigned to a specific server. The reservation does not touch storage, networking or software charges, and it does not auto-renew: at the end of the term the server simply goes back to pay-as-you-go.

Microsoft quotes savings of up to 67% on compute and says the actual figure depends on tier and region. Because the reservation bills every hour of the term, the discount only pays off on a server that is actually on and actually used.

Listing MySQL servers and their compute tier

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

Then check that the server is genuinely busy over the last month:

az monitor metrics list --resource <server-resource-id> \
  --metric cpu_percent memory_percent --offset 30d --interval PT24H --aggregation Average

Group the results by region and tier and add up the vCores; that total is what a reservation is sized against. Portal: Reservations, then Add, then Azure Database for MySQL, shows the per-tier discount for your region.

Evidence ZopNight requires before suggesting a commitment

1. A production signal: the server name contains prod, production, prd or live, or an environment tag says so.
2. No existing reservation or savings plan covers it, and it has no reserved=true tag.
3. At least 60 days of cost history, so the recommendation is not based on a few weeks.
4. Measured uptime of at least 70%.
5. Measured utilization: the server’s CPU percent or memory percent metric averaging 30% or more. A server that is on but mostly idle should be downsized first, then reserved at the smaller size.

When a reservation would not pay off

Any of those signals missing means no finding; an unknown value is never read as a pass. ZopNight also compares the 1-year reserved rate, billed for all 730 hours of a month, with what the server costs today. If the reservation would cost as much or more, the server is skipped. A server whose uptime drops below the 70% line can also lose the finding, with a small grace band so one unusual month does not make it flicker on and off.

How the saving is estimated

discount = 1 - (1-year reserved hourly rate / pay-as-you-go hourly rate)
saving   = current monthly server cost x discount

When the published rates are missing or look inconsistent, for example a reserved rate above the pay-as-you-go rate, ZopNight raises no finding rather than fall back to a fixed discount. The saving is compute only, because storage is outside the reservation.

Buying the reservation

1. Confirm the server will keep running at this size for at least 12 months.
2. Total the vCores per region and tier across all matching servers.
3. In the portal, open Reservations, select Add and Azure Database for MySQL, and pick the General Purpose or Memory Optimized series compute that matches the servers.
4. Choose the scope (shared, one subscription or one resource group), the 1-year term and the vCore quantity. You need Owner or Reservation Purchaser rights on the subscription.