Production vCore SQL databases paying on-demand instead of reserved rates
What does ZopNight detect here?
Production vCore Azure SQL databases running pay-as-you-go are flagged by RC-231 once they prove 60+ days of history, at least 70% uptime, and measured SQLCpuPercent of 30% or more. Savings come from a break-even comparison at 730 hours/month, falling back to a conservative 20% fraction; DTU and serverless tiers are excluded.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-231 |
| Category | discount |
| Severity | low |
| Metric | none — pure configuration read |
| Source | sql_reserved.go |
Where it applies
Reserved capacity is a vCore-only product
Azure sells SQL Database reserved capacity only for the vCore purchasing model. A DTU-tier
database (Basic, Standard, Premium) cannot buy a reservation at all, so recommending one
would be un-purchasable advice. RC-231 reads the discoverer-stamped sku_tier and abstains
on any known DTU tier; serverless databases (SKU containing _S_) are also skipped, since
reserved capacity does not apply to them. Even the utilization evidence respects this split:
only the vCore meter SQLCpuPercent counts, so a database showing only DTUPercentage
fails the utilization axis on purpose.
What a database must prove before a 12-month lock-in
A reservation is irreversible spend, so the rule demands evidence on three axes, all
fail-closed: at least 60 days of observed history, uptime of 70% or higher, and a measured
SQLCpuPercent average of 30% or more over the 30-day metric window. Unknown history,
unknown uptime, or an unmeasured CPU series each mean abstain. A present-but-empty metric
series (a stopped or unmonitored database) is treated as unverified, never as a measured
0%. An underutilized database is told, implicitly, to rightsize first and commit smaller
later. On top of that, the database must look like production: a prod name pattern (prod,
production, prd, live) or an authoritative environment tag.
The percentage is derived, not advertised
When tier rates are available, the rule prices the reservation at 730 hours/month against on-demand billed on measured running hours. A part-time database therefore never draws the full 24/7 discount. Its saving is capped at the real break-even net, and if the reservation would cost more than current spend, the rule returns nothing. Only when break-even inputs are missing does it fall back to a fraction of monthly cost, using a deliberately conservative 20%, which sits inside Microsoft’s published ~16–33% band for 1-year SQL reserved capacity. The headline percentage is always recomputed from the emitted dollar figure, so the two can never disagree.
Databases already covered are skipped
Existing Reservation or SavingsPlan coverage on the resource, or a reserved=true tag,
suppresses the finding. Cost inputs come through ZopNight’s pricing pipeline
(Cost Management Reader); metrics come via Monitoring Reader.
List candidate databases yourself
az sql db list --resource-group <rg> --server <server> \ --query "[].{name:name, tier:sku.tier, capacity:sku.capacity}" -o tableDatabases showing GeneralPurpose, BusinessCritical, or Hyperscale are vCore and
reservation-eligible; Basic/Standard/Premium rows are DTU and out of scope.