Azure SQL Managed Instance
Does ZopNight manage Azure SQL Managed Instance?
Azure SQL Managed Instance reserves vCores, memory, and storage continuously as one of the most expensive Azure database SKUs, and ZopNight treats it as discovery and cost visibility only. Resource Graph finds each instance, 60 days of Azure Monitor utilization inform review, and RC-271 flags idle instances with a smaller vCore target.
Rules that fire on Azure SQL Managed Instance
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only. |
SQL Managed Instance offers near-full SQL Server compatibility as a managed service inside a virtual network. It is one of the most expensive Azure database SKUs, so idle or oversized instances have an outsized cost impact.
vCores reserved at the top of the database price list
A managed instance reserves vCores and memory as a unit and bills for the full reservation every hour, with instance storage metered on top. There is no serverless equivalent at the instance level. Azure can stop and start General Purpose managed instances, which halts vCore billing, but ZopNight does not schedule SQL Managed Instance today, so here the reservation runs until the instance is deleted, resized or stopped by hand. Combined with a price point above nearly every other Azure database SKU, this means a managed instance that is idle overnight costs exactly what a busy one does, and an oversized one compounds that hourly.
Utilization review across a 60-day window
ZopNight discovers managed instances via Azure Resource Graph. Azure Monitor metrics with a 60-day lookback inform utilization review, Cost Management billing attributes spend, and RC-271 flags idle instances (CPU under 5 percent over 30 days) with a one-step smaller vCore target. Because ZopNight does not schedule the type, the platform’s role is cost visibility: showing which instances run far below their reservation and where a smaller vCore count would close the gap between what is paid for and what is used.
Oversizing patterns unique to Managed Instance
Lift-and-shift migrations are the classic source: an on-premises SQL Server’s core count gets copied into the vCore slider, importing years of on-prem overprovisioning into an hourly cloud meter. Non-production instances cloned from production sizing are a second pattern, since a staging environment rarely needs production’s reservation. Third, instances that run steady, predictable loads for months without reserved capacity leave the standing discount for committed use unclaimed.
Portal route for Managed Instance
Azure portal → Azure SQL → SQL managed instances lists every instance with its vCore count and storage. The instance’s Overview blade shows the provisioned reservation, the number to compare against the 60-day utilization picture before the next resize decision.