SQL Managed Instances averaging under 5% CPU for 30 days that can drop a vCore size

Why an idle managed instance is one of the costliest leftovers

A managed instance reserves a fixed number of vCores and bills them every hour, along with the SQL license unless Azure Hybrid Benefit applies. Unlike a serverless database it does not pause on its own. In the General Purpose tier you can stop it: Microsoft’s stop and start guide says a stopped instance is not billed for vCores and the SQL license, only for data and backup storage, and that vCore and license billing applies to every started hour. Stop and start is only available in the General Purpose tier, and a start takes about 20 minutes.

Because instances reserve many vCores at a time, one oversized, quiet instance can outweigh dozens of small idle databases. This rule is rated high severity for that reason.

Checking an instance’s CPU over a month

az sql mi list \
  --query "[].{name:name, group:resourceGroup, sku:sku.name}" -o table

az monitor metrics list \
  --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Sql/managedInstances/<mi> \
  --metric avg_cpu_percent storage_space_used_mb \
  --aggregation Average Maximum --interval PT1H --offset 30d

What must hold before a downsize is proposed

1. Average CPU over the last 30 days is below 5%.
2. The trusted CPU peak stays under a safe ceiling, so an instance that idles all month but spikes hard during a monthly load is not squeezed onto fewer vCores.
3. A next-smaller vCore size can be named for the instance’s tier and hardware generation, for example General Purpose Gen5 at 8 vCores stepping down to 4.
4. Rates exist for both the current and the smaller size, and the instance has a positive price.

Cases that produce no recommendation

When the current vCore count or the smaller size cannot be determined, or either rate is missing, the rule stays silent rather than invent a figure. The finding’s steps mention exporting the databases and deleting the instance as an option, but the saving is never priced on deletion, because dropping a managed instance means exporting databases and dissolving any failover groups or geo-replicas, which is not a cost change you can make on a metric alone.

Single databases on logical servers are handled separately by Idle Azure SQL Database.

A rate-delta saving, not the whole bill

saving = (current vCore size rate - next smaller vCore size rate) per month
cost after fix = current cost - saving

ZopNight treats the per-vCore rate as linear, so halving the count roughly halves the compute line, while storage stays the same.

Reducing or retiring the instance

1. Review CPU, IO and connection activity in Azure Monitor, and ask the owning team which applications still connect.
2. If it is lightly used, lower the vCores: az sql mi update --resource-group <rg> --name <mi> --capacity <smaller-vcores>.
3. If it is only needed part of the time and runs in General Purpose, stop it with az sql mi stop and start it with az sql mi start, or create a stop and start schedule.
4. If it is not needed at all, export each database and delete the instance.