Our two-person FinOps team manages the entire cloud environment, so we do not have much time for continuous cost reviews. We are considering AI agents that monitor utilization, identify oversized VMs and containers, find idle resources, recommend scheduled downsizing, and account for reservations or savings plans.
For anyone using this in production: How accurate are the recommendations when workloads have spikes, batch windows, seasonal demand, or other context that average utilization might miss? Do you allow automatic changes, or require human approval? Have the savings been meaningful compared with simply using Azure's built-in recommendations, and has an automated rightsizing change ever caused an outage?
4 Answers
I would use an agent as an always-on analyst before allowing it to operate independently. Automatically stopping clearly identified development and test resources on an approved schedule is relatively low risk. For production, have it prepare a change with the utilization window, constraints, owner, expected savings, and rollback plan, then require approval. Expand automatic permissions only to narrow, reversible resource categories after the results have been proven.
Traditional monitoring and rules can handle much of this without AI, and they have the advantage of being predictable. Track CPU and memory, but also look at disk throughput, queue depth, latency, startup time, processing schedules, and seasonal traffic. Reserved-instance or savings-plan coverage is a separate concern too, since rightsizing recommendations do not necessarily show that capacity is over- or under-allocated.
Azure Advisor is a sensible first step because it is already available, free, and based on deterministic metrics. It can identify straightforward opportunities without adding another non-deterministic AI layer. A specialized tool may still help with automation and broader waste discovery, but I would establish a baseline with Advisor first.
That seems like the practical approach: get the built-in recommendations working first, then evaluate whether a paid agent actually finds additional savings rather than just presenting the same information differently.
The recommendations can be useful, but agents often miss workload context. One tool wanted to shrink a batch cluster because it was idle most of the day, even though it needed all of its capacity during processing windows. The biggest savings we found came from forgotten resources such as orphaned disks, unused IP addresses, and old snapshots rather than VM rightsizing alone. Expect to spend time teaching the system about spikes and exceptions.
The idea of measuring realized savings while checking service health makes sense. A recommendation is not valuable if the workload becomes unstable after the change.