Documentation Index

Fetch the complete documentation index at: https://azure-cost-management-playbook.turbo360.com/llms.txt

Use this file to discover all available pages before exploring further.

Serverless SQL Costs

Prev Next

Problem


In one scenario we were looking at the costs for a SQL database which during a review were higher than expected.

During the development phase a Serverless SQL database had been chosen for some configuration data to be stored in and the serverless model was chosen because the database was expected to be used very infrequently.

About 6 months after go live the customer was reviewing their costs and someone asked why they were paying so much for SQL when it was expected to be nearly zero.

Analysis


In the below chart you could see that the costs for the SQL database were costing nearly 1k per month.

When the database was originally developed they were expecting the costs to be in the region of $10-20 per month as it would be so infrequently used.

When you check in Azure it is predicting the costs would be in the region of $10 per month based on the configuration.

It is expected that with Serverless SQL the database will go to sleep during periods of inactivity where you would stop being charged.

If you look at the SQL metrics for the database you can see that the App CPU billed counter for the database indicates that the database is never going to sleep.

Solution


The root cause here was that one of the developers had built a pipeline which on a schedule regularly pings the database so the database never goes to sleep and stops being billed.

The original infrastructure was designed with one assumption but the developers later had used a different assumption about how they would use the database.

Because this had been happening for a long time there were no cost alerts because this was already a part of the business usual costs.

The database had been flagged in a review thou which lead to this investigation.

The solution here was to change the database from the Serverless model to the DTU model which needed only the smallest DTU setting so the database was back down to in the region of $10 per month.

The mistake was expensive because this problem was in place for more than 1 database covering dev/test/prod and for 6 months + no one had noticed that the customer was paying about $990 per month more than they had originally planned to be paying.

Cost Reviews in the development phase of the project would have identified this issue much sooner.