Entrazure
“The bill has gone up every month for a year”
The symptoms are consistent. Finance asks for next quarter’s Azure forecast and gets a range instead of a number. Someone opens Cost Management, sees the top five subscriptions, and cannot say which team owns three of them. There is a resource group named after a project that finished eighteen months ago, and nobody will be the person who deletes it.
Meanwhile the engineering team is not being wasteful in any way they would recognize. Every individual decision was defensible at the time. The environment was provisioned generously because the launch date was tight. The disk tier was chosen for a load test that never got repeated. Diagnostic settings were switched on across the estate because a security review asked for logging, and nobody scoped which logs.
Nothing here is a scandal. It is the normal accumulated state of an estate that grew faster than its governance, and it does not correct itself.
Why the usual answer fails
A dashboard is not a control. The most common response is to buy a cost visibility platform, connect it, and circulate a weekly report. Visibility is necessary and it is nowhere near sufficient. The report lands with a platform team that has no authority to switch off another department’s environment, on resources whose owner is recorded nowhere, in a currency the recipients cannot act on. Six months later the tool is a line item on the bill it was bought to reduce.
The one-off optimization sprint. A four-week engagement finds the idle machines, resizes the obvious over-provisioning, buys some reservations and reports a saving. The number is real. It is also temporary, because nothing changed about how resources get created. The bill returns to its previous trajectory within two quarters, usually with the same categories of waste in the same places, and the organization concludes that cost work does not stick. It did not stick because it was done as a project rather than as a property of the platform.
Committing before right-sizing. Reservations and savings plans are the fastest visible win, so they get bought first. That is backwards. A one or three year commitment against a virtual machine size you were about to halve locks in the error and makes it harder to correct, because now there is a sunk commitment arguing against the change. Commit last, against the part of the estate that has been stable for weeks, not against the part you have not examined.
Percentage-of-savings arrangements. A gainshare model pays the vendor a cut of what they cut. The incentive it creates is to find one-time reductions that are easy to attribute, and to stay away from the boring structural work: tagging discipline, ownership, ingestion design, deployment defaults. That structural work is where the durable money is, and it is exactly the work a gainshare contract is not paid to do.
How we bring a bill under control
Ownership before anything else. A tagging standard with a small number of tags that actually get used, enforced by Azure Policy at the management group level so an untagged resource cannot be created rather than being flagged after the fact. Every subscription and resource group maps to a named owner and a cost center. This is unglamorous and it is the step that makes every later action possible, because a resource with an owner can be switched off and a resource without one cannot.
Right-size on measured behavior. Azure Monitor data over a full billing cycle, not a snapshot. Compute resized to observed utilisation, storage tiers matched to access patterns, orphaned disks and idle public IP addresses removed, non-production environments scheduled off outside working hours, App Service plans consolidated where density allows.
Fix the ingestion bill deliberately. Log Analytics and Microsoft Sentinel are where mature estates quietly lose money, because diagnostic settings are applied broadly and priced per gigabyte. We design ingestion per table, choose the retention tier per data type, and archive what exists only to satisfy an auditor. Retention requirements are set by the controls you are held to, which is why this is designed with the compliance architecture rather than negotiated against it.
Then the commercial layer. Reservations and savings plans against the steady core, Azure Hybrid Benefit where Software Assurance allows it, dev and test pricing, and consolidated billing through a direct CSP. Where an enterprise Microsoft commitment exists, purchasing through the Azure Marketplace draws down against it, which removes a procurement obstacle rather than a technical one.
Cost as a deployment-time property. Budgets and anomaly alerts per subscription, and a cost estimate produced on the pull request so an expensive change is visible before it is merged rather than in next month’s invoice. This belongs in the platform, which is what an Azure landing zone provides, and it is the difference between optimizing once and staying optimized.
The engagement that delivers it
Three weeks to baseline and act, then a monthly cadence to hold it. Week one produces the cost baseline, the ownership map and the ranked action list with an estimate and a risk note against each item. Week two executes the reversible actions: scheduling, orphan removal, tier changes, ingestion redesign. Week three implements tagging policy, budgets, alerts and the commitment plan, and hands over the forecast model.
You keep the tagging policy as code, the ownership map, the ranked backlog with everything we did not do and why, the ingestion design, and a forecast model your finance team can maintain without us.
Two adjacent situations change the shape of this work. If the spend problem originates in a migration that was sized on allocated rather than observed capacity, the cost model belongs in the VMware exit plan instead, before the commitment exists. If the growth is in data platform capacity rather than compute, the answer is usually workspace and capacity governance rather than trimming, covered under data platform modernization. Our commercial position, including how consulting and licensing are priced separately, is set out on the about page.
Questions we get
Should we buy reservations now to stop the bleeding?
Not first. Reservations lock a size and a region for one or three years, so buying them before right-sizing commits you to the mistakes you are trying to correct. Right-size, run for two or three weeks to confirm the new shape is stable, then commit against the part of the estate that is genuinely steady. The order matters more than the discount rate.
How much can we expect to save?
We will not quote a percentage before seeing the estate, because the honest answer depends entirely on how it was built. What we commit to is a baseline you can audit, a ranked list of actions each with its own estimate and its own risk note, and a forecast you can put in front of finance. A vendor promising a number before the assessment is guessing or gainsharing.
Is a cost management tool enough?
A tool tells you what happened. It does not tell you who owns the resource, whether the workload still matters, or who is allowed to switch it off. Those are organizational answers enforced through tagging policy and named ownership. Buy the tool if you like, but it is instrumentation, not a control.
Why did our Log Analytics and Sentinel bill grow faster than compute?
Because log ingestion is priced per gigabyte and verbose diagnostic settings get applied estate-wide by default. It is the single most common surprise on a mature Azure bill. The fix is a deliberate ingestion design, table-level retention, basic and auxiliary tiers for high-volume low-value logs, and archive for what only needs to exist for an auditor.
Does moving licenses across help?
Often materially. Azure Hybrid Benefit applies existing Windows Server and SQL Server licenses with Software Assurance to Azure compute, dev and test subscriptions are priced differently, and consolidating billing through a direct CSP simplifies both the invoice and the forecast. We are a direct CSP, and moving your tenant to us is never a condition of doing this work.
Should we move workloads back on-premise?
For a small number of steady, predictable, storage-heavy workloads that is a legitimate answer, and we will say so. For most estates the bill is high because of how the cloud was used, not because it is cloud. Repatriating an ungoverned estate reproduces the same sprawl on hardware you now have to buy twice.