We manage roughly 40 Azure subscriptions with annual spend in the mid-seven figures. Most workloads are PaaS, plus two AKS clusters that currently have no clear owner. Tagging and policy enforcement are already established: resources require business-unit and environment tags, tags propagate from resource groups, and chargeback reporting is handled through a central hub with Azure Data Explorer. Finance can now see which team owns each cost, so allocation is no longer the main problem.
The gap is explaining what caused costs to change and getting action taken quickly. Azure Advisor keeps recommending the same three underused VMs, even after one was resized twice, while more significant issues have been found manually. Examples include premium SSDs attached to development systems that shut down every evening, a barely used ExpressRoute circuit, and elastic pools still sized for an old load test.
By the time someone identifies an issue, the money has already been spent. Findings are often captured in a screenshot, discussed briefly, and forgotten until the same cost appears again the following month. What tools, reporting, or operating processes have worked for you once tagging and chargeback are already in place?
4 Answers
For AKS, compare node-pool capacity with actual pod requests and scaling behavior. Cluster autoscaling can leave a lot of quietly over-provisioned capacity, and it still looks like legitimate usage in most cost views. Put a budget or anomaly alert specifically on each AKS resource group so the signal is not buried in subscription-wide spend.
Infrastructure-as-code cost estimates are useful for catching changes before deployment. Adding Infracost to an OpenTofu or Terraform pipeline gives reviewers an estimate of the monthly impact of new resources and configuration changes. It is not a complete optimization system, though, so you will still need separate treatment for reservations, savings plans, and usage-driven services.
I would not treat every low-utilization recommendation as waste. ExpressRoute or excess capacity may be intentional because of resiliency, latency, or a business requirement. The practical approach is to review spend line by line with the service owner, record the reason for keeping an unusual resource, and focus on unexplained recurring charges. Some of the best savings come from small settings that nobody realized had been left enabled for years.
Start with a cost-change workflow rather than another static recommendation feed. Send daily or weekly deltas by subscription, resource group, service, and owner, then require an owner and an action for anything above a threshold. A dashboard can show the problem, but a ticket with a due date and a follow-up check is what keeps the saving from disappearing next month.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures