The previous lesson ended with an uncomfortable rule: before committing you have to optimize, because reserving an oversized resource means paying three years for a mistake. But to optimize you need to know what is badly sized, what has been running for months without anybody using it and what got left behind by a migration that finished a year ago. On a platform with fifty-odd resources spread across two subscriptions, nobody carries that information in their head.

Azure does. Azure Advisor continuously analyzes the real resources in your subscriptions and produces concrete recommendations — with the resource name, the reason and the estimated saving — across five categories. It is free, it needs no prior configuration and it has been in the portal since day one, which is exactly why almost nobody looks at it: there is nothing to switch on, so there is never a moment when somebody decides to use it.

This lesson covers all of it: the five categories and how they map onto the Well-Architected Framework pillars, the score and how to read it without becoming obsessed, the cost recommendations in detail — underutilization, orphaned resources, right-sizing and reservation purchases — the complete walkthrough of what Advisor tells Contoso and what the team does with each recommendation, the cases where Advisor gets it wrong, automating it with the CLI and the API, configuring it, and finally the waste that Advisor does not see and that you have to go looking for with Azure Resource Graph.

Reminder: every euro figure is illustrative and fictitious. Real prices vary by region and change frequently; check them in the official calculator.

1. What Advisor is and why it is the starting point
2. The five categories and the Well-Architected Framework pillars
3. The Advisor score
4. The cost recommendations in detail
5. Contoso's walkthrough: apply, postpone or dismiss
6. When Advisor gets it wrong
7. Querying and automating Advisor
8. Configuration: exclusions, thresholds and scope
9. Integration with Defender for Cloud and Cost Management
10. The waste Advisor does not see: Azure Resource Graph
11. Marta's monthly report
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

Advisor is a recommendation engine that evaluates the real configuration and telemetry of your resources against a set of Microsoft best practices. The difference from any list of tips published on the internet is substantial:

Three properties worth being clear about from the start. Advisor only reads: it changes nothing on its own, its recommendations are proposals and applying them is always an explicit action. It needs time and data: underutilization recommendations are based on observation windows of days, so a freshly created subscription will show few. And its coverage is not total: there is waste Advisor does not detect, which is why section 10 exists.

The correspondence with the Well-Architected Framework is no accident: Advisor is, in practice, the automated implementation of part of the framework over your real resources. The full framework — its principles, its review questions and its trade-offs between pillars — is covered in lesson 09-02; here it is enough to hold on to the idea that the five categories are not independent and they often pull in opposite directions. A cost recommendation proposing to remove a replica collides head-on with a reliability one asking for redundancy. Advisor presents both without resolving the conflict, because resolving it requires knowing the business. That arbitration is the architect's job, not the tool's.

Advisor calculates a score from 0 to 100, overall and per category, weighting the potential impact of the pending recommendations against the consumption of the affected resources. It is useful for two legitimate things: measuring the trend over time and comparing subscriptions or teams.

And it is worth saying clearly what it is not for, because misusing this metric does real harm:

• It is not a goal in itself. Chasing 100% leads to applying recommendations that do not apply, just to make them disappear from the list.
• It is not comparable between organizations. It depends on the composition of your resources.
• It goes down as you grow. Deploying new resources generates new recommendations; a drop can mean the team is building, not deteriorating.
• Dismissing a recommendation with a reason raises the score, and that is fine: it is how you tell the tool you have already decided.

At Contoso, the cost score went from 61 to 84 in two months. Nuria asked, quite reasonably, how many euros those 23 points were. The honest answer was: the euros are in the table in section 5; the score is a process indicator, not a results indicator. The figure that goes to the committee is the saving in euros; the score is used internally to see whether the team is working the list or letting it grow.

The recommendations in the cost category fall into four groups, and they are worth knowing because each one is decided differently.

Underutilized resources. Advisor observes the CPU and network of virtual machines over a configurable window (7, 14, 21, 30, 60 or 90 days) and flags those that stay below a threshold. It proposes shutting down or resizing. It is the recommendation with the most potential saving and also the one that demands the most judgment, because a machine at 3% may be waste or may be a license server that does very little but is indispensable.

Orphaned resources: the silent waste. These are resources that keep billing without being attached to anything. They throw no errors, they appear in no alert and nobody misses them:

Right-sizing and SKU changes. Advisor proposes downgrading databases with low usage, switching to more modern and cheaper SKUs (for example, from an older series to its current equivalent with a better price/performance ratio), or moving to serverless tiers where the pattern justifies it.

Reservation and savings plan purchase recommendations. These are the same ones you see in Cost Management and they follow what you already know from 08-03: they are not accepted blindly, because they look backwards and they calculate on the unoptimized state.

Marta opened Advisor over both subscriptions and worked the entire list. Every recommendation ends in one of three decisions, and all three are valid answers as long as the reason is recorded:

Four observations about that table, and they are what makes the exercise worthwhile:

• None of the applied actions affects a resource anybody was using. It is pure waste: €457 a month, €5,484 a year, for cleaning up.
• The two dismissed recommendations are technically correct and economically wrong, and only a human with context could know that (section 6).
• Postponing is a decision, not an evasion, as long as it has a date and a reason. All three postponed items have both.
• The orphans will come back. This is not a project that finishes; it is a monthly review (section 11).

Before applying anything, the safeguard Contoso wrote down: a 30-day snapshot before deleting any disk, and a check that no public IP has a DNS record pointing at it. Deleting an orphaned disk is irreversible, and saving €9 to cause a two-day restore is a bad deal.

Advisor does not get the data wrong: it gets the context wrong, because it does not have any. The patterns to be suspicious about:

• Seasonality. Recommendation 9 proposes shrinking vmss-api-disponibilidad-pro because its average CPU is low. That is true and irrelevant: the API exists to carry the summer season opening, when autoscale climbs to 14 instances and each one needs its size. A recommendation calculated over 30 days of February cannot know that.
• Deliberately idle resources. disk-motor-datos-copia is an intentional copy taken before an engine migration. To Advisor it is an orphaned disk; to the team it is a safety net with an expiry date.
• Contingency infrastructure. The whole North Europe pilot light (07-05) is, by definition, underutilized. That is its function.
• Cold-start workloads. A minimum instance always running on ca-motor-disponibilidad is nearly idle, and it exists precisely so that the first request does not have to wait.
• Short observation windows. A process that runs on the 1st of every month is invisible in a 14-day window.

The conclusion, which holds for any automated recommendation tool: Advisor proposes; a person with context decides. And when they decide to dismiss, they should do it with the tool's own dismissal function, stating the reason and a review date. Dismissing "forever" and silently turns the list into noise; dismissing with a reason and an expiry keeps it useful.

extendedProperties is where the interesting data lives and its contents vary by recommendation type: annualSavingsAmount, savingsCurrency, targetSku, currentSku, region. It is worth inspecting one complete recommendation with -o json the first time, to see which fields are there.

To automate the monthly report, Contoso runs this from a runbook in aa-contoso-operaciones (07-04) on the 1st of every month, drops the result into stlagocontosopro and posts the summary to Teams:

There are also alerts on new recommendations: you configure a rule that notifies when Advisor generates a recommendation of a given category and impact, targeting an action group. Contoso has one on High impact cost recommendations, pointed at ag-equipo-contoso, the same action group from 07-01 and from the budgets in 08-02. One practical piece of advice: do not alert on low or medium impact recommendations, or the channel will fill with noise and stop being read within a week.

And one warning about the Advisor API: recommendations are recalculated periodically, and their identifiers are not stable between generations. A script that stores identifiers to compare them month to month will not work; you have to compare by resource and recommendation type.

Advisor is configurable, and doing it well is what separates a useful list from a list nobody looks at:

The two decisions that pay off most. A different threshold per environment: in development a high threshold is what you want, because any machine below 20% is probably oversized and the risk of resizing it is nil; in production you want a low, conservative threshold, because a false positive costs you an incident. And a long window in production: with 14 days, an airline's seasonality generates absurd recommendations every low season.

Exclusion rules should be used sparingly. Excluding a resource takes it off the radar forever and silently, whereas dismissing a recommendation with a date brings it back to the list when it is due. Exclusion is for infrastructure whose nature is to be idle — contingency, cold start; dismissal is for everything else.

Advisor does not calculate everything it shows: it is also a shop window for other services.

The practical consequences of that diagram: Advisor's security category is Defender for Cloud's secure score, so you work on it there and not here — the paid plans from module 4 greatly extend what gets detected; and the reservation purchase recommendations are the same ones from Cost Management, calculated by the same engine, so it makes no difference where you look at them from, but they are decided with the criteria from 08-03.

Advisor covers the standard cases well, but there is waste it does not detect: untagged resources that cannot be allocated, development environments running at night, resources created outside the allowed regions, or any convention specific to your organization. That is what Azure Resource Graph (07-04) is for: it queries the full inventory with KQL in seconds.

Orphaned disks, with their size and their tier — including those Advisor has not processed yet:

Resources missing the mandatory tags, which is the origin of the "unallocated" bucket from 08-02:

Unassociated public IPs and load balancers with no backend, in a single query:

Development environments that should be switched off: machines tagged horario=laborable that are running. Run in the morning it confirms that the runbook started them; run in the middle of the night it reveals the ones that slipped through.

Storage accounts with no recent content and resources outside the allowed regions, two more hygiene checks:

These queries live versioned in contoso-infra alongside the Bicep templates, and that is an important recommendation: a waste query that exists only in one person's portal history is not a process. In a repository, anybody can run it, it gets reviewed in the pull request and it evolves with the platform.

All of the above is condensed into a one-page document that Marta takes to the committee on the first Tuesday of each month, with this fixed structure:

Two traits make this report work where others die. It fits on one page, so it gets read. And it includes what was dismissed and why, which is what stops the committee asking about the same recommendation every month and what demonstrates that the team decides rather than obeying a tool. The actions-executed section, with the real saving — not the estimated one — is what builds credibility with finance: the first time Nuria checked that the promised €457 actually showed up on the next month's invoice, the conversation about costs changed tone for good.

• Never looking at Advisor, precisely because there is nothing to switch on. It is the most common mistake and the cheapest to fix.
• Applying everything it says. Advisor knows nothing about seasonality, contingency or your deliberate copies.
• Dismissing silently and forever. A dismissal with no reason and no date turns the list into noise.
• Chasing the score. It is a process indicator; the result is measured in euros and in risk avoided.
• Deleting orphaned disks without a prior snapshot. Saving €9 and causing a two-day restore is a bad deal.
• Accepting the reservation purchase recommendation before right-sizing. You pay three years for the wrong size (08-03).
• Using the same window and threshold in development and production. They produce useless recommendations in one place and dangerous ones in the other.
• Storing recommendation identifiers to compare across months: they are not stable.
• Tip: run the orphaned disks and unassociated IPs queries today. It is the best-invested minute in this lesson.
• Tip: alert only on high-impact cost recommendations. The rest gets seen in the monthly review.
• Tip: version your Resource Graph queries in the infrastructure repository, alongside the templates.

Exercise 1. Advisor proposes moving vm-motor-disponibilidad-dev down from Standard_D4s_v5 to Standard_D2s_v5 because of 3% average CPU over 30 days. List the checks you would make before applying it and in what specific case you would reject the recommendation even though the data is correct.

Exercise 2. Write an Azure Resource Graph query that finds every disk snapshot older than 180 days, showing name, resource group, size, owner and cost center, sorted by size. Explain what you would do with the result before deleting anything.

Exercise 3. Contoso Miles (centro-coste=CC-2077) has just received its first recommendations: reduce its App Service SKU (medium impact, €40/month), delete two unattached disks (€18/month), buy a 3-year reservation on the PostgreSQL server (high impact, €55/month) and enable backups on the database (reliability category, no saving). Prioritize the four, state the decision and reason for each, and say what Advisor configuration you would adjust for this project.

Solution 1: prior checks. (1) Window and seasonality: 30 days may not cover a monthly process; widen the window to 60 or 90 days and look at the 95th percentile of CPU, not just the average — a machine averaging 3% that hits 90% for two hours every night is correctly sized. (2) Other dimensions: the recommendation is based on CPU and network, but the machine may be constrained by memory or by disk IOPS; you have to look at available memory in log-contoso-pro before reducing a size that also reduces RAM and maximum IOPS. (3) Software requirements: some engines demand a minimum vCPU count for licensing or configuration reasons. (4) Operational impact: resizing requires restarting the machine, so it needs a window, even if in development that is trivial. (5) Consistency with the baseline: if that VM is covered by a reservation, resizing it may leave the reservation unused — not applicable here, it is development and it is not reserved. You would reject it, despite the data being correct, if the machine were the agent for a monthly close process that consumes all the CPU one day a month, or if it were there as contingency capacity to absorb another environment's load. In this specific case — development, no reservation, no monthly process — you apply it: the risk is nil and the saving is real.

Solution 2: the query and the procedure.

Before deleting: (1) group by owner and send each person their list, with 10 days to claim whatever they want to keep — whoever created the snapshot knows why; (2) cross-reference with the activity log in log-contoso-pro to rule out that any of them has recently been used to create a disk; (3) check whether any of them precedes a schema migration or a major change, which is exactly the one to keep; (4) tag instead of delete on the first pass, with a caducidad=2026-10-01 tag, and delete whatever nobody has claimed at the next monthly review; and (5) record it in the monthly report. The snapshot with no owner is the hard case: if nobody claims it and there is no trace of use, it gets deleted, but that situation is itself a governance recommendation — require the propietario tag with a Deny policy from module 4.

Solution 3: priority and decisions. First, enable the backups (reliability, no saving): it is not a cost recommendation, but it is the only one whose absence could cost the entire project; the prioritization criterion is never the euro alone. Second, delete the unattached disks (€18/month): nil risk, minimal effort, with a 30-day snapshot first. Third, reduce the App Service SKU (€40/month): apply it only if there are 60 days of data and the 95th percentile supports it, and bearing in mind that dropping from Premium v3 to a lower tier can mean losing deployment slots, zone redundancy or autoscale — you have to check what you lose before looking at what you gain. Fourth and postponed, the 3-year PostgreSQL reservation (€55/month): it is the largest saving and the most dangerous decision, because the project is four months old and does not meet Contoso's rule of three months of stable usage; it is postponed 60 days and, if consumption holds up, bought for 1 year instead of 3, given the two-year business horizon. Advisor configuration to adjust: include the project's subscription in the scope, set the observation window to 60 days so that redemption seasonality does not generate noise, set an intermediate CPU threshold of 10% since this is low-risk production, and set a high-impact alert targeting ag-equipo-contoso with the project lead as an additional recipient.

You now know what Azure Advisor is and why it is the mandatory starting point for any optimization exercise: it is free, it analyzes your real resources instead of giving you generic advice, it quantifies the saving of each recommendation and it has been there since day one. You know its five categories — reliability, security, operational excellence, performance and cost — how they map onto the five Well-Architected Framework pillars you will see in 09-02, and the fundamental fact that they pull in opposite directions: the tool presents the conflict, the architect resolves it. You read the score as a process indicator and not as a goal, knowing that it drops when you grow and that dismissing with a reason is a legitimate way of raising it.

You have mastered the cost recommendations in their four groups: underutilization with its window and its threshold, orphaned resources — unattached disks, reserved public IPs, old snapshots, gateways with no connections, load balancers with no backend, empty accounts — right-sizing and SKU changes, and the purchase recommendations you already knew not to accept blindly. You have walked through Contoso's full list deciding one by one between apply, postpone or dismiss, with €457 a month of pure waste removed without touching a single resource in use, and with the two dismissed recommendations that demonstrate the limits of automation: shrinking vmss-api-disponibilidad-pro, which ignores the summer season, and the disk-motor-datos-copia disk, which is a deliberate copy. Advisor proposes; a person with context decides, and records the reason and the review date.

You also know how to query and automate it with the CLI, how to alert only on high impact towards ag-equipo-contoso, and how to configure it with judgment: a high threshold in development, a low threshold and a 60-day window in production, exclusions only for infrastructure whose nature is to be idle. You can place its role as a shop window for Defender for Cloud and Cost Management. And, above all, you know how to go looking for the waste Advisor does not see with Azure Resource Graph: orphaned disks, resources missing the four mandatory tags, unused IPs and load balancers, development environments running at 3 a.m. despite the runbook, storage accounts outside the allowed regions. All of it versioned in contoso-infra and condensed into the one-page monthly report Marta takes to the committee, with its dismissals section and its measured real saving.

With this you have the three major sources of saving identified and quantified: the estimate that avoids the spend before it is created, the commitment that lowers the price of what already runs, and the cleanup that removes what serves nobody. What is missing is the hardest part, and it is not technical: turning all of this into a way of working that does not depend on somebody remembering. The lesson that closes the module is about FinOps: its three phases and its three protagonists — Nuria, Marta and Diego — the complete catalog of optimization levers consolidating everything learned across the course, the conscious trade-off between cost, reliability, performance and security, Contoso's prioritized plan with its before-and-after table, unit cost as the indicator that really matters, the monthly review as a governance process, and the anti-patterns that ruin any optimization initiative — starting with the most expensive of all: saving fifty euros at the cost of twenty hours of engineering.