Azure Database for MySQL (Single Server)
Does ZopNight manage Azure Database for MySQL (Single Server)?
Azure Database for MySQL Single Server bills for provisioned compute 24/7 and has no stop capability, since Microsoft retired the SKU on 16 September 2024 in favor of Flexible Server. ZopNight discovers lingering instances via Resource Graph and attributes their billed cost, so each one can be queued for migration to Flexible Server, which can be scheduled.
Rules that fire on Azure Database for MySQL (Single Server)
No active rule family targets Azure Database for MySQL (Single Server) today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only; Single Server does not support stop/start. |
Azure Database for MySQL Single Server is the legacy managed MySQL offering, billed for provisioned compute around the clock. Microsoft retired this SKU on 16 September 2024 in favor of Flexible Server, and remaining servers are subject to automatic migration, so any instance still listed is both a cost and an overdue migration flag.
A retired SKU that still bills around the clock
Single Server charges for its provisioned compute tier every hour of every day, with a separate meter for provisioned storage and backup retention beyond the included amount. There is no stop operation on this generation of the service, because the platform simply never exposed one, so the only ways to reduce the compute line are to shrink the tier or to leave the SKU behind entirely. That is exactly why these servers matter: each one represents spend that cannot be paused no matter how idle the workload is.
How ZopNight treats Single Server MySQL
Discovered via Azure Resource Graph, with Cost Management billing showing spend. ZopNight reads no utilization metrics for Single Server, and no recommendation rule targets it yet. Because the type is not schedulable, ZopNight surfaces it primarily so teams can plan migration to Flexible Server, which is schedulable. Utilization evidence for a migration case comes from the server’s own Azure Monitor charts.
Why migration is the real saving here
Rightsizing a Single Server trims the meter; migrating replaces it with one that can be switched off. A non-production MySQL server needed only during working hours spends most of the week idle, and on Flexible Server that idle time stops billing for compute. On Single Server it never does. Teams that treat these instances as ordinary databases rather than migration debt keep paying the full 168-hour week indefinitely, and they also stay on a product line Microsoft has already retired.
Common leaks on legacy MySQL servers
Watch for three things: forgotten dev and test servers created years ago and never revisited; tiers sized for a launch that traffic never justified, visible immediately in the server’s Azure Monitor utilization charts; and servers whose only remaining consumer is a report or cron job that could run against a far smaller, or stoppable, target.
Locating Single Server instances in the portal
Azure portal → Azure Database for MySQL servers lists both generations side by side; the Deployment type column distinguishes Single Server rows from Flexible Server ones, which makes it the quickest inventory of what still needs migrating.