Explanation
Why the waste happens and who it affects.
Azure SQL Database bills each hour at the highest service tier and compute size that applied during that hour. When a database changes tiers mid-hour (e.g., S4 to S7 and back), the entire hour is billed at the higher tier, even if the database ran at that tier for only a few minutes.
This behavior is opaque to most users because cost reports usually aggregate usage by day, so a database that scales several times a day simply shows more higher-tier hours than its schedule would suggest. While technically aligned with Azure's billing design, this creates inefficiencies when tier switches are frequent, mid-hour, or uncoordinated. The documented model does not bill two tiers for the same hour, so a database showing more than 24 billed hours in a single day should be treated as a billing anomaly and raised with Azure support.
Billing model
The pricing dimensions that drive this cost.
In the DTU-based pricing model, customers select a predefined service tier (e.g., S3, S6, S7), and are billed per hour of provisioned capacity, regardless of actual usage. Each hour is billed at the highest service tier and compute size in effect during that hour, and a database that exists for less than an hour is still billed for the full hour. A brief scale-up in the middle of an hour therefore costs a full hour at the higher tier, and frequent scale-up and scale-down cycles can pay peak-tier rates for far more hours than the workload actually needs.
How to detect
6 checks to find it in your estate.
- Identify Azure SQL Database resources using the DTU-based pricing model
- Check for multiple billing entries for the same database and date
- Verify whether different service tiers (e.g., S3, S6) appear in the same day for the same resource
- Compare billed hours per tier against the intended scaling schedule; more higher-tier hours than planned indicate mid-hour scaling is paying peak rates, and more than 24 total billed hours in a day indicates a billing anomaly to raise with Azure support
- Review workload automation or manual scaling activity for frequency of same-day tier switches
- Assess whether tier transitions are occurring mid-hour or near peak usage windows
How to fix
4 ways to remove the waste.
- Minimize same-day tier switches unless operationally justified
- Schedule up/down-scaling during off-peak windows and, allowing for scaling latency, time scale-ups near the start of an hour and scale-downs near the end of one so partial hours are not billed at the higher tier
- Move to the vCore or serverless pricing model for more transparent and granular cost control
- Establish internal policies to monitor and govern tier changes for DTU-based databases
Documentation
Vendor references for pricing and configuration.