How to Cut Azure Data Costs Without Slowing Down Your Platform

Azure data cost optimisation usually starts the wrong way. Someone sees the monthly bill, buys a three-year reservation for the biggest line item and calls it done. The discount is real, but it locks in whatever waste was already there for the next three years.

The order matters more than the tactics. Find out where the money goes, remove what you do not need, right-size what is left, and only then commit to discounts. Done in that order, most organisations can cut their data platform bill without touching performance.

This guide covers Azure SQL Database, SQL Managed Instance, SQL Server on Azure virtual machines, Microsoft Fabric and storage. Prices and discount levels quoted are Microsoft's published "up to" figures as of November 2026. Your actual savings depend on region, tier and usage, and Microsoft changes prices and discount levels regularly, so check current figures with Microsoft before you commit to anything.

The six-step order

1. See: understand where every pound goes
2. Remove: delete or switch off what nobody uses
3. Right-size: match tiers and capacity to real demand
4. Schedule: stop paying for compute out of hours
5. License: use the licences you already own
6. Commit: buy reservations or savings plans for the steady baseline

Then repeat, because data platforms drift back to waste unless someone watches them.

Step 1: See where the money goes

You cannot optimise what you cannot attribute. Many Azure bills show the total clearly but hide who is responsible for each line.

• Tag every resource with an owner, environment (production, test, development) and cost centre. Untagged resources are the first place waste hides.
• Use Azure Cost Management to break spend down by resource group, service and tag, and to spot month-on-month jumps.
• Set budgets and alerts per subscription or team so overspend is caught in days, not at quarter end.
• Read Azure Advisor's cost recommendations. They flag idle and underused resources automatically. Treat them as a starting list, not a final answer.

A useful early test: ask each team which of their databases they could switch off tomorrow. The answers are often surprising.

Step 2: Remove what nobody uses

This is the cheapest saving there is, because it needs no redesign. Common examples in data estates:

• Forgotten databases from finished projects, proofs of concept or migrations that were never cleaned up
• Non-production copies of production that are larger, or more numerous, than anyone needs
• Orphaned disks, snapshots and backups left behind after virtual machines were deleted
• Duplicate Power BI datasets and dataflows refreshing the same data several times a day
• Old exports and staging files sitting in hot storage

Before deleting, confirm ownership and retention requirements. For anything regulated, archive rather than delete.

Step 3: Right-size what is left

Data platforms are almost always sized for a peak that happened once, or a growth forecast that never arrived.

Azure SQL Database and Managed Instance

Check CPU, memory and storage use over at least 30 days. If a database rarely goes above 30 to 40 percent CPU, a smaller tier is worth testing. For several small databases with different busy periods, an elastic pool lets them share capacity instead of each paying for its own peak.

SQL Server on Azure virtual machines

Look at both the VM size and the SQL Server edition. Enterprise edition costs far more than Standard, and many databases running on Enterprise use no Enterprise-only features. Running sys.dm_db_persisted_sku_features in each database shows whether any edition-specific features are in use. If none are, moving to Standard can be a significant saving. If you are weighing up the platform itself, see our comparison of Azure SQL and SQL Server on a VM.

Microsoft Fabric

Fabric capacity is bought in sizes (F SKUs). Check the Capacity Metrics app to see how much of your capacity you actually use. Many organisations buy a larger SKU "to be safe" and run well below it. Reducing heavy, badly written workloads, such as repeated full refreshes, can let you drop a size. Learn more about our Microsoft Fabric expertise.

Fix performance before buying capacity

Slow queries are often fixed with indexing or query changes rather than more hardware. Scaling up to hide a performance problem is one of the most expensive habits in Azure. See common SQL Server performance issues.

Step 4: Stop paying for idle time

Many data workloads only run during working hours or in overnight batches. Paying for compute 24 hours a day, seven days a week is waste.

• Azure SQL Database serverless scales compute automatically and bills per second. In the General Purpose tier it can auto-pause after a set period of inactivity, when only storage is billed. Auto-pause in Hyperscale is still a preview feature (Microsoft Learn: serverless compute tier). The first connection after a pause can briefly fail while the database wakes up, so applications need retry logic.
• Fabric pay-as-you-go capacity can be paused when it is not needed, stopping compute billing. Any outstanding smoothed usage is added to the bill when you pause (Microsoft Learn: pause and resume Fabric capacity). Pausing saves money on pay-as-you-go, not on capacity already covered by a reservation.
• Development and test virtual machines can be scheduled to shut down overnight and at weekends.

Serverless is not always cheaper. A database that is busy most of the day can cost more on serverless than on provisioned compute. Use it for intermittent workloads, not steady ones.

Step 5: Use the licences you already own

If you have SQL Server or Windows Server licences with active Software Assurance, you may be paying for licences twice.

• Azure Hybrid Benefit lets you apply existing SQL Server licences to Azure SQL Database, SQL Managed Instance and SQL Server on VMs. Microsoft says this can save up to 30 percent or more on SQL Database and Managed Instance (Microsoft Learn: Azure Hybrid Benefit). It is a setting on each resource, and it is easy to miss when resources are created quickly.
• Dev/test pricing gives discounted rates on Azure SQL Database, Managed Instance and Windows VMs for active Visual Studio subscribers running non-production workloads (Azure Dev/Test pricing). Check your non-production subscriptions are set up to use it.

Step 6: Commit, but only to your baseline

Once usage is clean and right-sized, commit to discounts for the part that runs all the time. Microsoft offers two main options.

Two details worth knowing:

• Reservations do not apply to Azure SQL Database serverless (Microsoft Learn: reservation charges). The newer savings plan for databases does cover serverless, along with SQL Database, Managed Instance, Hyperscale and SQL Server hourly licences on Azure VMs (Microsoft Learn: savings plans).
• Commit to less than you use. Unused commitment is lost. Cover the steady baseline and leave peaks on pay-as-you-go.

Do not forget storage

Storage is rarely the biggest line, but it grows quietly every month.

• Use Blob Storage access tiers. Hot suits frequently used data. Cool, Cold and Archive cost less to store but more to access. In general-purpose v2 accounts, each has a minimum storage period: 30 days for Cool, 90 for Cold and 180 for Archive, with early-deletion charges if data is moved or deleted sooner (Microsoft Learn: access tiers).
• Set lifecycle rules to move old data to cheaper tiers automatically.
• Review backup retention. Keep what policy and regulation require, not everything forever.
• Check monitoring and log retention. Diagnostic logs sent to Log Analytics are billed by volume, and verbose logging on busy databases adds up.

Keep costs down once you have cut them

Savings disappear if nobody owns them. New databases appear, projects end without clean-up, and test environments become permanent.

• Name an owner for data platform costs and review them monthly
• Make tagging mandatory with Azure Policy so new resources cannot be created without an owner
• Watch for change. Alerts on unusual spend catch a runaway job or a forgotten scale-up early. Data observability adds the same early warning for pipeline failures and data issues that drive reruns and wasted compute.
• Review commitments before they renew so you do not roll over reservations for workloads that have changed

This is continual improvement in practice, one of the strategic approaches in our operational excellence framework.

Where Cyber Samurai helps

Our Azure Data Cost Optimisation assessment reviews your Azure SQL, SQL Server, Fabric and storage spend. It works through the six steps above and gives you a prioritised list of savings, with the effort and risk of each. We validate the numbers with you rather than promising a fixed percentage.

If you would rather hand over day-to-day management, Data Platform Management as a Service includes ongoing cost and performance tuning for Microsoft Fabric and Azure data platforms. Our database expertise covers SQL Server editions, licensing and performance.

Book a consultation