On a mature Azure estate the platform services, not the virtual machines, are often where the bill quietly grows. Log Analytics ingestion, oversized App Service plans, premium SQL tiers, and overprovisioned Cosmos DB throughput each have a specific lever, and tuning them rarely touches application code. That makes them some of the lowest risk savings on Azure, because you change a configuration rather than a system.
This is an Azure data and PaaS topic. Below are the services that most often drive cost and the move that cuts each, with the discipline to keep the signal you actually use.
Log Analytics and Azure Monitor: cut noise, keep signal
Ingestion is billed by volume, and most estates ingest verbose logs they never query. The levers are table level retention so you do not store everything for the same period, routing low value logs to a cheaper basic tier or to storage, sampling in Application Insights, and a commitment tier once daily ingestion is predictable. The aim is to keep the telemetry you investigate with and drop the noise you pay to store and never read.
App Service and Functions: size the plan to the load
App Service plans are frequently provisioned for a launch peak and never revisited. Consolidate underused apps onto a shared plan, scale the plan to the real load rather than the worst case, and use the consumption model for spiky Functions workloads where you pay per execution rather than for an always on plan. The pattern is the same across compute: match the tier to the workload behaviour, not to the day you launched.
SQL Database and Cosmos DB: tier and throughput discipline
Databases carry two distinct levers. On SQL Database, choose the right tier and buy reserved capacity for the steady core, and weigh Managed Instance against single databases on cost rather than habit. On Cosmos DB, the common waste is provisioned request units set high for a launch peak and never lowered.
| Service | Common waste | Lever |
|---|---|---|
| SQL Database | Premium tier and overbought capacity | Right tier plus reserved capacity for the steady core |
| Cosmos DB | Provisioned request units fixed at the peak | Autoscale or right sized throughput, consolidate idle containers |
| Azure OpenAI | Standard tokens for a steady workload | Provisioned throughput once volume is predictable |
Azure OpenAI: govern the fastest growing line
AI workloads are the fastest growing line on many Azure bills, and they need their own discipline. Token costs, model choice, and provisioned throughput all move the number. Use the standard pay per token model while volume is uncertain, then move steady, high volume workloads onto provisioned throughput where the unit cost is lower. Treat capacity reservations and prompt efficiency as cost levers, not just engineering details.
A European SaaS company found two thirds of its Azure platform spend sitting in Log Analytics ingestion and a set of Cosmos DB containers provisioned at launch peak. Table level retention, log routing, and autoscale on the containers recovered a substantial share with no application change. Figures are verified against billing data and anonymised.
Frequently asked questions
Which Azure PaaS services most often drive cost?
How do you cut Log Analytics cost without losing visibility?
Is Cosmos DB throughput a common source of waste?
Tune the platform with us
We help enterprises cut the Azure platform services that quietly drive the bill, from Log Analytics to Cosmos DB, without slowing teams down. It is part of the wider Azure cost optimization guide. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.