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 recommendations highlight rightsizing and reserved-capacity opportunities.
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 pause, no serverless equivalent at the instance level, and no way to schedule the meter off. The reservation runs until the instance is deleted or resized. 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 recommendations highlight rightsizing and reserved-capacity opportunities. Because the type cannot be stopped, the platform’s role is cost visibility: showing which instances run far below their reservation and where a smaller vCore count or a reservation purchase 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.