Contoso Airlines now has all the individual pieces: it knows how to estimate before deploying, it knows what it spent and whose it is, it knows which commitments to buy and it knows where the waste is. What it still does not have is the hardest part, and it is not technical: a way of working in which cost manages itself, without depending on somebody remembering. Because optimization done once undoes itself within six months. The orphaned disks come back, the environment left running at night comes back, the log ingestion nobody queries comes back, and next quarter Nuria asks the same question again.

This lesson closes the module with that leap: from tools to FinOps culture. You will see its three phases and the three roles that sustain it — Nuria, Marta and Diego — the complete catalog of optimization levers consolidating everything learned across the course, the conscious trade-off between cost and reliability, performance and security, with the cuts Contoso deliberately rejects, the prioritized plan with its before-and-after table, unit cost as the indicator that really matters, the monthly review as a governance process, cost inside the development lifecycle, and the anti-patterns that ruin any savings initiative.

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

1. What FinOps is and why it is culture, not tooling
2. The three phases and the three roles
3. The complete catalog of optimization levers
4. The trade-off: cost versus reliability, performance and security
5. The cuts Contoso rejects
6. Contoso's optimization plan
7. Before and after
8. Unit cost: the indicator that matters
9. The monthly cost review
10. Policies that prevent spending
11. Cost in the development lifecycle
12. Optimization anti-patterns
13. Common Mistakes and Tips
14. Exercises
15. Conclusion

FinOps is an operating discipline for managing cloud spending: a set of practices that put economic accountability with the team that makes the technical decisions, using shared data in near real time. It is not a product, it is not a dashboard and you cannot buy it.

The reason it is needed is structural and it already appeared in 08-01: in the cloud, the person spending the money is the engineer, not the purchasing department. A control model in which finance approves and engineering then executes does not work when execution takes three seconds. That leaves only two options: block people with approval processes that destroy the very agility that justified the cloud, or give people the data and the accountability. FinOps is the second.

The three principles that sum it up:

• Visibility: every team sees what it spends, in enough detail to act, and without having to ask anybody.
• Accountability: the team that decides is the one answerable for its bill, and it has room to decide.
• Continuous optimization: it is not a quarterly project, it is a monthly routine with owners and dates.

And the reason people insist that it is culture: the three things that saved Contoso the most were not technical. They were a tagging scheme that lets you know whose every euro is, a one-hour monthly review where somebody has to explain their figures, and the habit of attaching an estimate to every architecture proposal. The tools execute; the culture is what makes somebody look at them.

The cycle runs continuously and you cannot skip the first phase: optimizing without informing is guesswork. Contoso spent two months on the inform phase — tagging, the hereda-centro-coste policy, views, budgets, exports — before touching a single resource, and that is why the optimize phase took three weeks instead of six months.

The three roles, with names attached:

The classic dysfunction is only two of the three taking part. Without finance, the team optimizes without knowing whether it matters. Without engineering, ceilings get set that break production. And without the business — the most frequent case — you cut what is technically easy instead of what is economically irrelevant, and those two rarely coincide.

This is the table that consolidates the whole course. Each row is a lever seen in an earlier module, put here in its economic place.

Two ways to read this table. Vertically, it is the list of everything you can touch. Horizontally, it is a warning: the risk column says the most profitable levers are not the safest, and there are three rows — redundancy, backup retention and sampling — where saving means accepting more risk, not removing waste. That distinction is the subject of the next section.

There are two classes of optimization, and confusing them is the origin of almost every disaster:

The first column is executed without asking permission: nobody has to approve deleting a public IP that is not attached to anything. The second is never decided by engineering alone, because it is not a technical decision: it is an exchange of money for risk, and the risk is borne by the business.

The right way to put a trade-off to whoever has to decide it has three parts: how much is saved, what exactly is lost and what happens on the day that matters. Framed like that, most questionable cuts fall over on their own. Framed as "we can save €190 a month on storage", almost all of them get approved, and nobody remembers why on the day of the incident.

These proposals came up in the review and were rejected in writing, which is as important as what was actually done:

Contoso could have cut another €2,555 a month off its bill by applying this list. It decided not to, and it wrote that down. That document is worth more than it looks: when somebody asks a year from now why GZRS is being paid for, the answer will be written with its date and its signature, and nobody will have to reconstruct the reasoning from scratch. A mature team is not the one that cuts the most: it is the one that knows what it does not cut, and why.

Starting from the analyzed July invoice — €17,800 — the team prioritized the actions by saving, risk and effort. Illustrative and fictitious figures:

The ordering criterion was not the absolute saving but the ratio of saving ÷ (risk × effort), and that is why action 3 — €457 of cleanup with no risk and no effort — was executed before action 1, despite saving six times less. There is also a hard dependency between the two: rule 3 from 08-03 demands optimizing before committing, so the cleanup and the right-sizing had to come first for the reservation to be bought over the already slimmed-down platform.

And a warning about the arithmetic that is always worth making: these savings are not perfectly additive. Action 2 reduces the ingestion and with it the base on which a future capacity commitment would be calculated; action 4 reduces egress but also Storage transactions, overlapping slightly with action 5. The honest estimate Contoso took to the committee was not a figure but a range: between €12,400 and €13,000 a month, and the new budget was set at €13,000 so as not to promise the best case.

Three readings. No service was degraded: response times, availability and RPO/RTO are identical before and after, and that was verified with the module 7 dashboards over the following four weeks. More than half the saving came from two places — commitments and observability — consistent with the rule of optimizing from the top down. And fw-contoso-hub-pro still costs the same, because not everything expensive is optimizable, and acknowledging that is part of the job.

An absolute total is a bad indicator, because it does not distinguish between spending more because you are growing and spending more because you are wasting. The indicator that does distinguish is unit cost: cost divided by a unit of business value. At an airline, cost per booking sold.

The third row is what changes the conversation in the committee. August's invoice is 10% higher than July's and, looked at in absolute terms, it looks like a failure. Looked at in unit cost, it is the best news of the year: the platform absorbed 60% more bookings for 10% more spend, that is, it scales with increasing efficiency. A rising invoice can be excellent news, and without unit cost there is no way to prove it.

The indicator is calculated by joining the daily cost export from stlagocontosopro (08-02) with the bookings table, in syn-contoso-analitica-pro:

Contoso publishes three unit indicators: cost per booking sold, cost per boarding pass issued and cost per million requests to the Availability API. Each one has an owner, and all three are reviewed monthly. The rule that governs them: the goal is not for the invoice to go down; it is for the unit cost to go down. If the business grows 40% and the invoice grows 15%, the team has done excellent work even though Nuria pays more than last month — and she knows it, because the indicator shows her.

The process that sustains everything else fits into one hour a month:

Four rules learned the hard way that make the difference between a useful meeting and a ceremony:

• The report goes out beforehand. A meeting that starts by reading data does not make decisions.
• Every action has a name and a date. "Somebody should look into the logging thing" is not an action.
• Promised saving is compared with realized saving. This is the point that builds credibility, and also the one that exposes optimistic estimates.
• You celebrate the unit cost, not the invoice. If you reward lowering the invoice, somebody will end up slowing down the growth of the business to achieve it.

The cheapest optimization is the one that prevents the spend before it exists, and that is what the policies from module 4 are for, applied from the "Base de gobernanza de Contoso" initiative:

That last caveat deserves attention because it is the module's full loop: a policy designed to improve observability creates spending in log-contoso-pro. That is not an argument for not having it; it is an argument for deploying it with the log categories chosen deliberately, instead of switching them all on.

And a warning about balance: an overly strict Deny policy turns into a queue of exceptions somebody has to approve, and that reintroduces exactly the friction the cloud was supposed to remove. Contoso keeps a short list of Deny policies — regions, disproportionate sizes, tags — and uses Audit for everything else, reviewing the result in the monthly meeting.

For cost to be a design criterion rather than a subsequent audit, it has to be built into four points of the process, all of them already covered:

The piece with the greatest cultural effect is the third. When the pull request automatically shows that raising a database SKU costs €380 a month (08-01), the conversation about cost happens between two engineers, at the moment when changing it means editing one line, and without anybody having to play policeman. Cost stops being an audit and becomes design information, which is the whole point of FinOps.

The third one deserves a separate comment because it is the most common among motivated technical teams. A day of engineering costs something in the order of several hundred euros; spending twenty hours on a €50-a-month saving takes almost a year to pay back, and during that year those twenty hours could have been spent on something else. Before optimizing something, estimate how much optimizing it costs. It is the same discipline from 08-01 applied to your own work.

• Believing FinOps is a tool. You buy a dashboard and nothing changes; what changes things is the monthly review with owners.
• Confusing removing waste with accepting a trade-off. The first is executed; the second is decided with the business and written down.
• Optimizing without verifying afterwards. The change gets applied and nobody checks whether the saving showed up on the invoice.
• Measuring only the total invoice. Without unit cost you cannot tell growth from waste.
• Cutting observability blindly. It is the easiest item to touch and the one that leaves you with no instruments.
• Not writing down what gets rejected. A year from now nobody will remember why GZRS is being paid for.
• Automating shutdowns without tag-based safeguards. A badly filtered runbook switches production off on a Tuesday.
• Tip: put the monthly review in the calendar today, even if the first report is poor. The routine creates the data, not the other way round.
• Tip: publish the unit cost on the same dashboard where the team looks at latency. What gets seen gets managed.
• Tip: keep a log of cost decisions — applied and rejected — alongside the templates in contoso-infra.

Exercise 1. Contoso Miles' (centro-coste=CC-2077) invoice is €1,240/month: App Service Premium v3 (€420), PostgreSQL flexible with high availability (€390), Log Analytics (€180), receipt blobs on GZRS (€140) and Functions on consumption (€110). The project has 6,000 redemptions a month and a budget of €900. Propose a prioritized plan with saving, risk and effort, state what you would not cut and calculate the unit cost before and after.

Exercise 2. An engineer proposes reducing log-contoso-pro retention from 90 to 7 days, saving €480/month. Analyze the proposal: what gets lost, what alternatives exist with the same saving and less impact, and how you would put it to the committee if it had to be done anyway.

Exercise 3. Design the monthly cost meeting for a 40-person company with a single subscription and a €4,000/month invoice. Define the attendees, duration, agenda, indicators and what you would automate so that the report prepares itself.

Solution 1: starting unit cost: €1,240 ÷ 6,000 redemptions = €0.207/redemption. Prioritized plan. (1) Log Analytics (€180): apply the three levers from 07-02 — review with Usage which tables are being ingested, move container or application logs that are never investigated to the Basic plan and adjust the per-table retention; estimated saving €90, low risk, medium effort; it is the item with the best saving/risk ratio. (2) PostgreSQL (€390): high availability with zone redundancy doubles the compute; this is a trade-off, not waste, so the business decides — if a loyalty program can tolerate a few hours of downtime, disabling it saves around €180; if not, it stays and you look elsewhere. In parallel, checking the sizing and reserving for 1 year if usage has been stable for three months is pure waste removal (around €60 more). (3) App Service (€420): check whether Premium v3 is required for zone redundancy and slots or whether it was chosen out of inertia; if the project can tolerate a lower tier the saving is large, but you lose slots and autoscale — again, a trade-off. (4) GZRS blobs (€140): moving to ZRS saves part of it, but redemption receipts may have evidentiary value; it does not get cut without consulting legal. (5) Functions on consumption (€110): already on the most efficient model; leave it alone. What is not cut under any circumstances: the minimum legal retention of the receipts, and the database backups. Plausible result: ~€330 of saving with no trade-offs (Log Analytics, the reservation and cleanup) → €910/month, unit cost €0.152/redemption, 27% lower, effectively within budget without degrading anything. If the business additionally accepts giving up high availability, you drop below €900 comfortably, but that decision is not signed off by engineering.

Solution 2: what you lose with 7 days of retention: the ability to investigate any incident older than a week, the comparison against last month's baseline, the trend analysis that underpins the optimization exercise itself, and — critically — compliance, because AzureActivity and access logs usually have retention requirements measured in months or years; cutting indiscriminately to 7 days may be a straightforward breach. On top of that, security incidents and ransomware are detected late (07-05): without logs there is no way to reconstruct what happened. Alternatives with comparable saving and far less impact, in order: (1) reduce the ingestion of what nobody queries — the highest-impact lever — identifying with the Usage table which tables account for the bulk of the volume and switching off unused diagnostic categories or filtering them with transformations in the collection rule; (2) the Basic plan for high-volume, low-query tables such as container logs; (3) differentiated per-table retention, which is what resolves the conflict: AzureActivity at 365 days for compliance, AppTraces at 30, debug logs at 8; (4) long-term archive, much cheaper, with search jobs when needed; and (5) exporting to stlagocontosopro for whatever is only needed occasionally. Combining the five reaches a similar saving while preserving what is investigable. If the cut had to be made anyway, you put it to the committee as an explicit trade-off: "we save €480/month and we accept that any incident older than a week will be uninvestigable and that the audit logs will stop meeting requirement X", with the signature of whoever takes on that risk and a review date.

Solution 3: attendees, four people: whoever runs finance, whoever runs infrastructure, a product representative and the technical lead of the main product; more than five people for €4,000 is disproportionate. Duration 30 minutes a month. Agenda: (1) the month's invoice, variance and deviation from budget, 5 min; (2) the unit cost of the chosen business indicator, 5 min; (3) top 5 items and anomalies detected, 5 min; (4) waste from Advisor and Resource Graph with an apply/postpone/dismiss decision, 10 min; (5) actions with an owner and a date, 5 min. Indicators: total, monthly variance, unit cost, percentage of untagged resources, realized saving versus promised, and commitment coverage if there are any. Automation: a monthly runbook in Azure Automation that runs az advisor recommendation list --category Cost and the Resource Graph queries for orphans and untagged resources, dumps the result into a storage account and posts the summary to Teams 48 hours before the meeting; a daily cost export; a budget with alerts at 80% actual and 100% forecasted targeting the existing action group; and anomaly detection enabled. At this size chargeback is not appropriate — with a single subscription and four people, showback and a conversation are enough — nor is buying reservations before there are three months of stable usage.

You now know what FinOps is and why it is culture and not tooling: in the cloud the person spending the money is the person writing the template, and the only alternative to blocking people with approvals is giving them the data and the accountability. You know its three phases — inform, optimize, operate — the rule that you cannot skip the first, and the three roles with their names: Nuria bringing budget and economic context, Marta bringing the knowledge of what can be touched, and Diego and product deciding what is worth it; along with the typical dysfunction of the business being absent and the team ending up cutting what is technically easy instead of what is economically irrelevant.

You have the complete catalog of levers that consolidates the entire course — switching off, cleaning up orphans, right-sizing, autoscaling, spot instances, reservations and savings plans, Hybrid Benefit, consolidating plans, serverless tiers with auto-pause, RU/s autoscale, pausing Synapse, storage tiers and lifecycle rules, the three Log Analytics levers, sampling in Application Insights, caching and CDN against egress, the right hosting plans, serverless and event-driven architectures, and token limits — with their typical saving and, above all, with their risk. And with it, the distinction that avoids disasters: removing waste is executed without asking permission, accepting a trade-off is decided by an informed business, with the three questions — how much is saved, what exactly is lost and what happens on the day that matters. That is why Contoso left €2,555 a month on the table, rejecting in writing the removal of zone redundancy on db-reservas, the fg-contoso-reservas replica, the WAF, Defender for Cloud, GZRS on the boarding passes, backup retention and the bastion.

You carry the complete prioritized plan, ordered by saving divided by risk and effort, with the cleanup executed before the commitments; the measured result — from €17,800 to €12,550 a month, 29% less, without degrading a single service — and the honesty of presenting it as a range and budgeting the worst case. You know that the indicator that really matters is unit cost, which fell from €0.193 to €0.136 per booking sold and kept falling during peak season even as the invoice rose, because a rising invoice can be excellent news and without that indicator there is no way to prove it. And you have the process that sustains it: the one-hour monthly review with its attendees, its report sent 48 hours ahead, its actions with names and dates and its comparison of promised against realized saving; the policies that prevent spending from the governance in module 4; the integration of cost into the development lifecycle, with the estimate in the architecture review and the automatic comment on the Bicep pull request; and the anti-patterns that ruin any initiative, with the most expensive of all clearly identified: saving fifty euros at the cost of twenty hours of engineering.

That closes module 8 and, with it, the construction of the platform. It is worth looking at the whole: Contoso Airlines started this course with a vague idea of what the cloud was and finishes with a platform deployed on well-chosen compute, storage and networking; with its data in the right services and its service levels justified; secured with identity, RBAC, secrets, a WAF, Defender for Cloud and policies that prevent the creation of what should not exist; delivered by pipelines and infrastructure as code instead of by clicks; extended with containers, functions, messaging and AI; observed end to end, investigable with KQL, automated and recoverable with a tested plan; and now estimated, measured, budgeted, allocated, optimized and governed, with every euro charged to a cost center and every cutting decision — including the ones that were rejected — written down with its reason. Nuria Peña's question, the one that opened this module, finally has an answer: you know how much each piece costs, what part of that invoice is value and what part was waste, and who decides about each one.

One last thing remains, and it is to look at all of this at once. Across eight modules you have seen the platform in parts, each one in its lesson, and that is how you learn it; but it is not how it exists. Module 9 closes the course with the whole picture: the complete Contoso Airlines architecture drawn in full, with all its components and all its connections, so that you can read it the way you read a blueprint; the Azure Well-Architected Framework, the framework that justifies — or dismantles — every one of the decisions you have been making, with its five pillars and their trade-offs; the common mistakes that repeat in every organization and how to avoid them before you make them; how an entire organization migrates with the Cloud Adoption Framework, because Contoso still has systems in Barcelona; and where Azure is heading, with the certifications that accredit what you already know how to do. You have all the pieces: module 9 is where you learn to read the whole with judgment.