# Idle Azure SQL Managed Instance

> SQL Managed Instance carries one of the highest baseline costs in Azure, so ZopNight flags instances averaging under 5% CPU over 30 days and prices the saving as a real rate delta to the next-smaller vCore rung (8 to 4, for example), abstaining whenever a peak reached 80% or no target rate exists.

Source: https://zop.dev/integrations/azure/recommendations/idle-azure-sql-managed-instance
Updated: 2026-08-19

---

## High floor, high stakes

A SQL Managed Instance bills for its full vCore allocation continuously, one of the
steepest baselines in Azure. When the `avg_cpu_percent` series averages below 5% across a
30-day window, the instance is doing a fraction of the work it is provisioned for. But
unlike a VM, deleting an MI is a heavyweight, behavioral act: databases must be exported,
failover groups and geo-replicas dissolved. So ZopNight's default lever here is not delete
but a one-rung vCore downsize, priced honestly.

## The 80% peak veto

A low average hides spiky reality. An instance that idles all day and spikes toward
saturation at nightly batch time would be throttled on fewer vCores, turning a cost fix
into timeouts. When the trusted peak of the full CPU series reaches the 80% safety
ceiling, the rule suppresses the recommendation entirely. The headroom is being used, just
rarely.

## Savings from real rungs, not fractions

The downsize target comes from the vCore ladder the pricing pipeline actually quotes: 4, 8,
16, 32, 64, 80, 128 (a GP_Gen5_8 steps to GP_Gen5_4). The dollar figure is the genuine
source-to-target rate delta for the region. Both rates must exist; a bottom-rung instance, an
unparseable SKU, or a missing rate means the rule abstains rather than print an estimated
fraction. Storage metrics ride along as evidence but never gate the decision.

## Watch the CPU curve yourself

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

Average under 5 with a maximum well below 80 is the firing shape.

## Downsizing without drama

A vCore change on an MI is an online scaling operation, but it can take hours and
terminates in a brief failover, so schedule it in a maintenance window. Recheck the peak
after a month at the smaller size. If connections and CPU are both flat and the data is
stale, the delete conversation starts, with exports first.

## Minimum access

Reader for discovery, Monitoring Reader for the CPU and storage series, Cost Management Reader
for the billed baseline. High severity reflects the dollars at stake, not risk to the
workload.
