# Overbilling due to frequent tier switches in DTU model

Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/overbilling-due-to-tier-switches-and-allocation-overlaps-in-dtu-model

Workloads that frequently scale up and down within the same day-whether manually, via automation, or platform-managed-can encounter hidden cost...

By: Sid Ahmed Redjini

Updated: 2026-09-28

[Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) 

# Overbilling Due to Frequent Tier Switches in DTU Model

The short version

Workloads that frequently scale up and down within the same day-whether manually, via automation, or platform-managed-can encounter hidden cost amplification under the DTU model.

[Sid Ahmed Redjini](https://www.linkedin.com/in/sid-ahmed-redjini-349001303/)

FinOps Consultant @ FinOps&Co

Azure service

[Azure SQL](https://www.pointfive.co/efficiency-hub/cloud-services/azure-sql)

Category

[Databases](https://www.pointfive.co/efficiency-hub/service-category/databases)

Reference

CER-0194

Type

Suboptimal Pricing Model

## 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.

- [Purchasing Models - Azure SQL Database  learn.microsoft.com](https://learn.microsoft.com/en-us/azure/azure-sql/database/purchasing-models?view=azuresql)

- [DTU-Based Purchasing Model - Azure SQL Database  learn.microsoft.com](https://learn.microsoft.com/en-us/azure/azure-sql/database/service-tiers-dtu?view=azuresql)

- [Scale Single Database Resources - Azure SQL Database  learn.microsoft.com](https://learn.microsoft.com/en-us/azure/azure-sql/database/single-database-scale?view=azuresql#billing)

- [Pricing - Azure SQL Database Single Database  azure.microsoft.com](https://azure.microsoft.com/en-us/pricing/details/azure-sql-database/single/)

## Related inefficiencies

[Browse the library](https://www.pointfive.co/efficiency-hub)

- Azure SQL  CER-0239

### [Azure Hybrid Benefit Not Enabled on SQL Databases](https://www.pointfive.co/efficiency-hub/inefficiencies/azure-hybrid-benefit-not-enabled-on-sql-databases-41927)

Azure Hybrid Benefit allows organizations to apply existing SQL Server licenses with Software Assurance or qualifying subscriptions to Azure SQL Databases. When this configuration is missed or not enforced, workloads continue to incur...

Databases

- Azure SQL  CER-0434

### [Missing Reservation or Savings Plan Coverage for Steady-State Azure SQL vCore Compute](https://www.pointfive.co/efficiency-hub/inefficiencies/missing-reservation-or-savings-plan-coverage-for-steady-state-azure-sql-vcore-compute)

Provisioned vCore databases in Azure SQL Database and instances in Azure SQL Managed Instance are billed hourly for compute at pay-as-you-go rates unless a commitment discount applies. Production databases typically run around the clock at...

Databases

- Azure SQL  CER-0264

### [Suboptimal Use of Serverless Compute for Azure SQL Database](https://www.pointfive.co/efficiency-hub/inefficiencies/suboptimal-use-of-serverless-compute-for-azure-sql-database-4fe48)

Serverless is attractive for variable or idle workloads, but it can become more expensive than Provisioned compute when database activity is high for long portions of the day. As active time increases, per-second compute accumulation...

Databases

---
Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.

