Azure Advisor recommendations need triage rather than obedience
Advisor has produced 34 recommendations. Fourteen are cost. One of them suggests buying a three year reserved instance for a virtual machine you were planning to delete next month, which would be an expensive way to take your own advice.
Azure Advisor recommendations get treated in one of two unhelpful ways. Either the list becomes a target and somebody works through it top to bottom, or it gets dismissed after the third bad suggestion and never opened again. Both are understandable and both waste it, because the mix of genuinely useful and confidently wrong is high enough that the only sensible approach is triage.
Where azure advisor recommendations are reliable
Advisor is at its best where the answer does not depend on anything it cannot see.
Reliability and resiliency findings. No redundancy on a storage account, a single instance where an availability set was intended, backups not configured. These are statements about configuration, and configuration is something Advisor can read completely.
Security findings, which are mostly a view onto Defender for Cloud. Same reasoning: it is reporting a setting rather than inferring an intention.
Service retirements and deprecations. Genuinely valuable, and the category people most often miss because they filter to cost. An API version going away or an extension reaching end of support is a real deadline with a real date, and Advisor is a reasonable place to find out.
Operational excellence items such as missing diagnostic settings. Dull, correct, and quick.
Microsoft's Advisor documentation sets out the five categories and what feeds each one, which is worth reading once because knowing the data source tells you how much to trust the output.
Where it misleads on a small estate
The cost category is the problem, and specifically two kinds of recommendation.
Rightsizing based on averages. Advisor watches CPU and network over a lookback window and suggests a smaller SKU when utilisation is low. The logic is sound and the failure is in what an average hides. A machine that sits at 4 percent CPU for 29 days and pins at 95 percent during a month-end batch run has a low average and a hard requirement. Downsize it and you find out on the last working day of the month, which is the worst available time.
Advisor does not know that the batch job exists, or that the machine was sized for a load test, or that it is deliberately oversized because resizing it requires a change window nobody wants to book.
Reservation and savings plan suggestions. These assume the workload continues. On a mature estate that is a reasonable assumption. On a small estate mid-cleanup it is exactly wrong, because the machines with the steadiest usage patterns are frequently the legacy ones you are trying to retire. A three year commitment on a VM that appears in your decommissioning plan is a way of paying in advance for something you intend to stop doing.
The order matters here more than the recommendation does. Delete first, then commit. Advisor cannot know which order you are in.
The recommendation it cannot make
Worth noticing what is absent. Advisor will tell you a virtual machine is
underutilised. It will not tell you that the machine has no owner, sits in a
resource group called rg-poc-2022, and has had no inbound network traffic
other than monitoring for eleven months.
That is because Advisor is answering "is this correctly sized" while the question you have is "should this exist at all". Those produce different actions, and the second one saves considerably more money. Nothing in Advisor covers unattached disks, unassociated public IP addresses, snapshots whose source disk was deleted, or empty App Service plans, which is the entire subject of the orphaned resources note and typically where the first real savings in a small estate are found.
So Advisor is a check on the things you are keeping. It is not an inventory of the things you have forgotten.
Triaging the list
What works, on a list of 30 or so, in about twenty minutes.
Read the retirement and deprecation items first and put dates in a calendar. These are the only ones with a deadline attached and they are the ones a quarterly skim will miss.
Take the reliability and security items at face value and fix or dismiss them individually. If you dismiss one, use the built-in dismissal with a reason rather than mentally ignoring it, so the list stays meaningful next month.
Treat every rightsizing suggestion as a question, not an instruction. The question is: what is the peak, and what happens at the peak. Check the maximum rather than the average over the same window Advisor used. If maximum utilisation is also low, the machine is a candidate for deletion rather than resizing, which is a better outcome than Advisor proposed.
Park reservation advice until the cleanup is finished. Then revisit it properly, because at that point the assumption it rests on is true and the savings are real.
Dismiss with a reason. An Advisor list nobody has curated is noise within two quarters, and the dismissal reason is the only thing that stops you re-litigating the same fourteen items every time somebody new looks at the portal.
Using it alongside your own checks
The two are complementary rather than competing, and they answer different questions.
Advisor is the better source for anything that depends on Microsoft's roadmap or on Defender's signals. Your own inventory is the better source for anything that depends on knowing what the business is doing, because that context does not exist in any telemetry Advisor can read.
The practical arrangement: run your own orphan and idle sweeps to decide what to delete, act on those first, then use Advisor to right-size and commit on what remains. Doing it in the other order means paying to optimise things you were about to throw away.
The AzClean Toolkit covers the inventory half of that, and the note on reporting findings covers presenting the result in a way that survives a finance meeting.