Where mid-market Azure bills actually leak money
In a mid-market Azure estate, the money that leaks every month is rarely a setting someone forgot. It is architectural: non-production environments running at production scale, reserved capacity bought against the wrong usage shape, storage that never gets tiered, App Service and SQL sized for a launch-day guess, egress nobody attributed to a feature, and licensing that Azure Hybrid Benefit would have covered. Below, each one in order of how much it usually costs, what share of the bill it tends to be, and what it takes to fix.
The shares are rough ranges for estates where the problem is present, not a benchmark, and they do not add up to 100: most bills have two or three of these, not all six.
The six leaks at a glance
For the CFO conversation: what it is, how big it usually is, and whether fixing it is a setting, a purchase or an engineering project.
| Feature | Typical share of the bill | Kind of fix | Effort |
|---|---|---|---|
| Non-production at production scale | 15 to 30% | Architecture and scheduling | Days to a sprint |
| Reservations against the wrong usage shape | 10 to 20% | Purchasing decision | Days, plus a finance sign-off |
| Storage that never gets tiered | 5 to 15% | Lifecycle policy | Days |
| App Service and SQL sized for launch day | 10 to 20% | Rightsizing and consolidation | One to two sprints |
| Unattributed egress | 3 to 10%, more for data-heavy products | Architecture | A sprint or more |
| Licensing Hybrid Benefit would cover | 5 to 15% on Windows and SQL Server heavy estates | License inventory and a setting | Days |
Non-production environments running at production scale
Typical share: 15 to 30% of the bill. Development, test, staging and UAT were created by copying production, so they run the same App Service plans, the same SQL tiers and the same redundancy, around the clock, for a handful of people who use them during working hours.
What it takes to fix: give non-production its own sizing in your infrastructure as code rather than a copy of production's parameters, shut down or scale down outside working hours, move eligible subscriptions to Azure Dev/Test pricing, and replace long-lived feature environments with ones that are created per pull request and deleted after. This is usually the largest and fastest saving, and it needs no change to the product.
Reserved capacity bought against the wrong usage shape
Typical share: 10 to 20% of the bill, in two opposite forms. Either nothing is committed and steady workloads run at pay-as-you-go rates, or reservations were bought for a VM family, region or size the platform has since moved away from, and they sit partly unused while the new workload pays full price.
What it takes to fix: read the reservation utilization reports, commit only against the baseline that has been flat for months, prefer savings plans where the compute mix is still shifting, and use Microsoft's exchange options for reservations that no longer fit. This is a purchasing decision as much as a technical one, so it needs finance in the room.
Storage that never gets tiered
Typical share: 5 to 15% of the bill, growing every month because storage only accumulates. Blobs that nobody has read in a year sit in the hot tier, snapshots and backups are kept far past any retention requirement, and diagnostic logs are ingested and retained at full price by default.
What it takes to fix: lifecycle management policies that move data to cool, cold and archive tiers by age, snapshot and backup retention that matches an actual policy, and a deliberate decision about which logs are ingested into Log Analytics and for how long. Mostly configuration, done once.
App Service and SQL sized for a launch-day guess
Typical share: 10 to 20% of the bill. The plan and the database tier were chosen before anyone knew the real load, with a margin for launch, and nobody revisited them once the metrics existed. Often each app also got its own App Service plan, and each database its own server and tier.
What it takes to fix: rightsize from months of real CPU, memory and DTU or vCore data, consolidate apps onto shared plans where their load allows it, move groups of databases with uneven load into elastic pools, and consider the serverless tier for databases that are idle most of the day. One to two sprints, because every change needs a load test and a rollback plan.
Egress nobody attributed to a feature
Typical share: 3 to 10% of the bill, and considerably more for products that move files, media or data exports. Egress shows up as a networking line item with no owner, so nobody connects it to the feature that generates it: a report export, a cross-region call on every request, a sync job that pulls the same data back out every night.
What it takes to fix: first attribution, with tags and cost allocation that tie data transfer to a service, then architecture: keep chatty services in the same region, cache at the edge with Azure Front Door or a CDN, and stop moving data that the consumer could read in place. This is the one most likely to need real engineering work.
Licensing that Azure Hybrid Benefit would have covered
Typical share: 5 to 15% of the bill on estates with many Windows Server VMs or SQL Server workloads. Companies that already own Windows Server or SQL Server licenses with Software Assurance, often from their on-premises years, are paying for the license a second time inside the Azure rate.
What it takes to fix: an inventory of the licenses you actually own and their eligibility, confirmed with whoever manages your Microsoft agreement, then turning Hybrid Benefit on for the eligible resources. Days of work, and one of the few savings that is close to a switch once the paperwork is right.
How to explain the bill to a CFO
Separate the three kinds of saving, because they are approved differently. Configuration fixes (tiering, Hybrid Benefit, schedules) are engineering time and no risk to the product. Commitments (reservations and savings plans) trade flexibility for a lower rate and belong in the budget conversation. Architectural changes (non-production design, rightsizing, egress) cost a sprint or two and pay back every month after.
Then give each finding an annualized figure, the effort to get it, and an order. A CFO does not need to know what an App Service plan is. They need to know that a two-week piece of work removes a recurring cost, and when the saving starts.
If you want that written up for your own estate, the Azure Cost Review does exactly this: one day of read-only access and a findings memo with dollar figures within five business days.
Related questions
Doesn't Azure Advisor already find this?
Advisor finds idle resources and obvious rightsizing, and it is worth acting on. It does not read the architecture, so it will not tell you that staging is a full copy of production or that a feature is generating most of your egress.
Which of these should we fix first?
Usually non-production environments and Hybrid Benefit, because they are large, low-risk and fast. Commit to reservations only after rightsizing, or you lock in the oversized footprint.
At what size of bill is a review worth it?
Roughly $10k a month on Azure or more. Below that, Azure Advisor and Cost Management budgets usually get you most of the way.
Next step
We’re on top of things and aim to respond to all inquiries within 24 hours.
Imhauser Technologies
McLean, VA
United States
Available on-site across the DC metro, Tysons, Reston, Arlington, and Washington, DC, as well as hybrid and remote worldwide.