The invoice as telemetry
Class One ended with a manager forwarding an invoice at three times the estimate, over one line: "I thought cloud was supposed to be cheaper?" Thirty-one classes later you can finally answer her properly, because you now know what the invoice actually is: a metric stream. Every meter in Azure emits a number per hour — compute hours, gigabytes stored, gigabytes ingested, rows read — and the bill is just the month's aggregation of signals you could have been watching all along. Treated as a surprise, it arrives late, itemised in a currency of regret. Treated as telemetry — charted, filtered, alerted on, exactly like the Class Twenty-Eight kind — it becomes the cheapest observability system you own, because it is already deployed and already accurate.
- FinOps
- The practice of treating cloud spend as an engineering signal with named owners — measured continuously, attributed to teams, and acted on weekly — rather than as a finance document reviewed after the money is gone.
The tooling is Microsoft Cost Management, and it is free, on by default, and sitting in the portal under every subscription. It answers three questions in ascending order of maturity: what did we spend (cost analysis, §2), will we be told before it goes wrong (budgets and alerts, §3), and who does each dollar belong to (tags, §5). One honest caveat before you trust it in a meeting: cost data is not real-time — usage takes several hours to a day to land in the reports, so this morning's experiment shows up tomorrow, not at lunch.1 That lag is why §3's alerts include a forecast, and why cost review is a weekly habit, not a live dashboard you stare at.
Here is the career note, stated once: nearly every engineer you will compete with can deploy infrastructure, and almost none of them can read an invoice. The person who walks into the monthly review able to say which line grew, why, and what it buys is usually the most senior-sounding person in the room, regardless of their title — because money is the one telemetry stream leadership is fluent in.
Cost analysis — group, filter, find the suspects
Cost analysis is the query surface over the invoice, and using it is a two-move pattern you already know from Class Twenty-Nine's KQL: group, then filter. Group the month by service to see what kind of thing costs money; regroup by resource group to see which application it belongs to; regroup by tag to see which team owns it; then filter into the biggest bar and repeat one level down. Three groupings and two filters take you from "the bill is $9,400" to "the storefront's log ingestion doubled on the 12th" in about four minutes — and the 12th, you may recall, is a deploy you can look up in Git.
What you find at the bottom of that drill is remarkably consistent across companies. Four suspects account for most of the recoverable waste in most estates:
| Suspect | How it hides | The fix |
|---|---|---|
| Orphaned resources | Deleting a VM does not delete its disks or public IP; they bill on, attached to nothing, owned by nobody. Invisible unless you go looking. | A monthly sweep for unattached disks and unassociated IPs; snapshot, confirm, delete. Advisor lists them for you. |
| Oversized compute | The VM was sized for a guess in week one and never revisited; it idles at 8% CPU with a straight face. | Right-size against the Class 28 metrics you already collect. Advisor again suggests candidates. |
| Non-production running 24/7 | Dev and test environments bill nights, weekends, and holidays for work done nine to five. Two-thirds of their hours serve nobody. | Auto-shutdown schedules, or — the Class 27 pattern — platforms that scale to zero on their own. |
| Data movement & ingestion | Egress charges and log ingestion grow with traffic and verbosity, not with any deploy decision anyone remembers making. | Class 28's warning, now with a price on it: sample, filter at source, and cap what nobody queries. |
Notice what the suspects have in common: none of them is a pricing problem. They are all attention problems — resources nobody looked at after the week they were created. Which is why the fix for all four is the same fix wearing different clothes: a recurring review with a named owner, the §3 alerts to summon it early, and the §5 tags so the findings land on the right desk.
Budgets and alerts — the shout before the bill
A budget in Azure is an alert rule wearing a finance costume, and the single most-tested fact about it is what it does not do: a budget never stops anything. Crossing it deallocates no VM, throttles no service, blocks no deployment. It notifies the people you name, at the thresholds you set, and that is all.2 First encounter, this reads as a design flaw. It is the opposite: the storefront going dark at 3am because November traffic pushed a counter past an arbitrary number would be a self-inflicted outage — Class Two's whole argument for elasticity, cancelled by a spreadsheet cell. Azure declines to build that footgun; the shout is the feature.
A budget stops the surprise, not the spend.
Two threshold types make the shout arrive early enough to matter. Actual thresholds fire when recorded spend crosses a line — "we have now spent 80% of the month's budget." Forecasted thresholds fire when the projection crosses it — "at this pace, we will land at 130%" — and given §1's data lag, the forecast is the one that buys you time to act inside the same month. The working pattern: a budget per subscription and per major resource group, an actual alert at 80% and 100%, a forecasted alert at 100%, all routed to a Class Thirty action group owned by the team whose spend it is — because an alert about the platform team's money, sent to a shared inbox, is Class Thirty's wallpaper problem with a dollar sign on it. If you genuinely need spend to stop, that is automation you build deliberately: the alert triggers a runbook or a Function that shuts down what you have decided, in advance and in writing, is safe to shut down.
Commitments — reservations and savings plans, honestly
Everything so far cuts waste. The other lever cuts price: commit to Microsoft for one or three years, and the meter rate drops — steeply. A reservation commits you to a specific shape of usage (this VM size family, in this region, or a set capacity of SQL or storage) for headline discounts that reach into the 60–70% range against pay-as-you-go. A savings plan for compute commits you to an hourly dollar amount — "we will spend at least $10 an hour on compute" — and applies a smaller discount across nearly any compute, any family, any region. Two facts keep engineers out of trouble here. First, both are billing constructs: a reservation discounts matching usage, it does not deploy, guarantee, or hold hardware for anything.3 Second, both are use-it-or-lose-it, per hour: an hour in which nothing matches the commitment is an hour you paid for silence.
| Pay-as-you-go | Savings plan | Reservation | |
|---|---|---|---|
| You commit to | Nothing | $/hour of compute, 1 or 3 years | A resource shape, 1 or 3 years |
| Discount depth | None — this is the list price | Meaningful | Deepest |
| Flexibility | Total | High — follows your compute across families and regions | Low — the workload must keep matching the shape you named |
| Right for | Spikes, experiments, anything that might not exist next quarter | A compute floor that is steady in dollars but shifting in shape | The workload you would bet a year's roadmap on staying put |
The honest comparison, then, is not "which discount is biggest" but "how certain are you." The method: chart three months of usage and find the flat floor — the spend that was there every hour of every day. Reserve the most stable, specific slice of that floor; lay a savings plan over the steady-in-dollars, shifting-in-shape remainder; leave everything spiky on pay-as-you-go, because elasticity was the point of Class Two and a commitment is elasticity's opposite. And commit after the cleanup, never before: a reservation bought against §2's waste locks in the price of the mistake. Azure will even do the arithmetic for you — Advisor and the reservation blade recommend purchases from your own usage history, which beats any vendor slide claiming 72%.
Tags — the currency of accountability
Every mechanism in this class eventually collides with the same question: whose is this? Cost analysis can group by resource group, but resource groups answer "which application", not "which budget line". The answer is one you met in Class Seven and have been half-using since: tags — and in cost work they stop being metadata and become the join key between the invoice and the org chart. cost-center, env, owner: three keys, consistently applied, turn "the bill is $9,400" into a per-team statement finance can post against real budgets.
The failure mode is voluntary tagging. Ask forty stores' worth of engineers to please remember the tags, and within a quarter you have CostCenter, cost_centre, and a plurality of resources with nothing at all — and an untagged dollar is an unattributable dollar. The fix is Class Eight, reapplied: Azure Policy enforces the taxonomy. One subtlety does the most work: tags are not inherited — a tag on the resource group does not flow to the resources inside it — so the standard pattern is a policy with a modify effect that copies cost-center from the group onto every resource in it automatically. Engineers tag one object, the group, at creation; policy does the rest; and deny is reserved for exactly one gate, requiring the tag on new resource groups. Denying every untagged resource sounds rigorous and mostly teaches people to type tbd.
The 3× invoice, autopsied at last
The pilot-month invoice that arrived at three times the estimate never got a real autopsy — the team was too new to run one. This class runs it. Cost analysis, grouped by service, then by resource group, finds the money in an afternoon: the pilot's "temporary" VMs — sized generously for a load test that ended in week two — ran twenty-four hours a day for a month; the load test's disks and public IPs outlived their VMs and were still billing, $660 of Figure 16's bar; and Log Analytics, configured in the enthusiasm of Class Twenty-Eight with verbose collection, was ingesting debug logs nobody had ever queried. Not one line of the overage was Azure mispricing anything. Every line was a decision nobody revisited — which is what the manager's question actually meant, and the answer she was owed: cloud is cheaper when someone runs it like a utility; nobody was yet.
The findings become machinery the same week. Budgets on the subscription and on each application's resource group — actual at 80 and 100 percent, forecast at 100 — each routed to the owning team's action group. Auto-shutdown on every dev VM; the orphan sweep on the monthly calendar; ingestion sampled per Class Thirty. Policy inherits cost-center from resource groups and requires it on new ones. And one page goes to the manager monthly: spend by team, trend against last month, one anomaly explained, one action taken. The first such report shows the bill down 38 percent from the pilot peak — and for the first time since Class One, she forwards it with a different one-liner: "keep sending these."
The official pages, and a CAMPUX overview
Explore and analyze costs with cost analysis
learn.microsoft.com/azure/cost-management-billing/costs/quick-acm-cost-analysis
What are Azure Reservations?
learn.microsoft.com/azure/cost-management-billing/reservations/save-compute-costs-reservations
A live walk of the group-and-filter drill from a real bill to a real culprit, a budget with a forecasted alert firing, and the flat-floor read of a usage chart will live here. Video to be added.
Read your own bill, then make it shout
Run the §2 group-and-filter drill on your own subscription, check what Advisor already knows about your waste, and leave a budget behind that will out-shout any future surprise.
In the portal, open your subscription → Cost Management → Cost analysis. Set the period to the current month.
What to notice: even a bootcamp subscription has a shape — the labs you deleted promptly cost cents, and anything you forgot is visibly not cents. This view is free and needs no setup; most engineers simply never open it.Run the drill: group by Service name, then regroup by Resource group, then click into the largest bar and group by Resource.
What to notice: three groupings take you from a total to a named resource. Say the finding as a sentence with an owner in it — "the Class 27 container environment is 60% of my spend" — because that sentence is the entire skill.Open Advisor → Cost and read its recommendations for your subscription.
What to notice: Advisor is the §2 suspect list, automated — idle resources, right-sizing candidates, and commitment suggestions computed from your own usage. In an interview, "I check Advisor's cost tab monthly" is a small sentence that lands large.Create the shout: Cost Management → Budgets → Add. Monthly budget, an amount just above your normal spend (say $10 for a lab subscription); alert conditions at Actual 80%, Actual 100%, and Forecasted 100%, to your email.
The lesson: this budget costs nothing and stops nothing — but the next runaway lab resource emails you at 80% of $10 instead of appearing on an invoice at month-end. Leave it in place; it is the cheapest insurance in this bootcamp.
A line item with an owner
The monthly Azure bill spikes and a VP wants to know why by lunch. You open Cost Analysis, group by tag, and find the runaway resource in minutes — then set a budget with an alert so the next surprise arrives as an email while there is still time to act. You turn "the cloud is expensive" from a complaint into a line item with an owner.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B — a reservation is a billing construct, and both halves of that sentence bite. It deploys nothing (C), and — the one that surprises people in incidents — it holds no hardware: capacity guarantees are a separate product, and a region can run short of a size you hold reservations for. D is the expensive misunderstanding: the discount is use-it-or-lose-it per hour, so an hour with no matching usage is an hour of commitment paid for silence — nothing banks, nothing rolls over. That is why §4's method starts from the flat floor of measured usage rather than from the discount percentage on the slide: the 60-odd percent is real, but only for hours in which the matching workload actually runs. Buy certainty you have, not certainty you hope for.
C — the budget shouts; it never touches the workload. Picture the alternative and the design makes itself: it is mid-November — Campux's peak — and the traffic that pushed spend past $5,000 is revenue. A budget that behaved like A, B, or D would convert the best sales day of the year into an outage, triggered by a number typed in July. Azure refuses to build that, so enforcement is never implicit; if spend truly must stop, you wire the alert to automation you wrote, aimed at resources you chose in advance. The exam and interview shape is the flat question "do Azure budgets stop spending?" — and the two-word answer, no, notify, is one the majority of candidates get wrong in the confident direction.
Orphans, always-on non-production, and unrevisited ingestion. The rejects both smuggle in the same wrong idea — that the bill is something done to you. Meter rates do not drift mid-month; the published price is the published price, and reaching for "Azure must have raised rates" delays the real autopsy by a week. And an untagged resource bills at exactly the normal rate — the penalty is not on the invoice, it is in the meeting: the dollar is unattributable, so nobody owns it, so it recurs. Notice the pattern in the three correct answers: each is a decision that was reasonable the day it was made and simply never revisited. Waste is not made of mistakes; it is made of expired decisions.
# memo: Q3 cost reduction plan — platform team
1. Sweep and delete unattached disks and idle public
IPs monthly, after snapshot review.
2. Auto-shutdown schedules on all dev/test VMs:
off 19:00–07:00 and weekends.
3. Purchase 3-year reserved instances for the dev/test
VMs to discount their remaining hours.
4. Budgets per resource group: actual 80%/100% and
forecasted 100%, routed to each owning team.
Line three — and the memo defeats itself. Line two just cut the dev VMs to roughly a third of the week's hours; line three then commits to paying for those VMs' shape every hour for three years. A reservation's discount only lands on hours with matching usage, so two-thirds of this commitment buys silence — arithmetic that routinely turns a "60% discount" into spending more than pay-as-you-go. The deeper error is §4's rule reversed: commitments are for the flat floor that survives cleanup, and dev/test that shuts down nightly is the least reservation-shaped workload in the estate. Had this memo shipped, Q4's cost review would open with an unused-reservation line nobody can delete, three years long.
The distractors are the plan working: a snapshot-first orphan sweep is exactly the §2 procedure (A), shutdown schedules have no bearing on SLA (B — that objection is invented), and line four is §3 verbatim (D). Read cost memos the way you read the Class 31 config: the wrong line is usually the one applying a good tool to the wrong workload.
Start with the ledger, not the tags. Chargeback fails when the taxonomy is designed from the org chart's ambitions instead of finance's actual ledger — so the first meeting is asking finance what lines they post to, and the answer becomes a closed list of valid cost-center values, published somewhere versioned. Three keys suffice: cost-center (finance's join key, from the closed list), env, and owner. Every key beyond what someone will actually query is future inconsistency: a taxonomy's failure rate rises with its ambition.
Then make the tags involuntary. Humans tag the resource group once, at creation — policy does everything else. One deny policy requires a valid cost-center on new resource groups (deny at the group level is cheap; nobody creates groups mid-incident); one modify policy inherits the tag from group to every resource inside, because tags do not flow downhill on their own and hand-tagging ten thousand resources is a project that never finishes. Existing estate: a remediation task backfills, and the leftovers get one afternoon of archaeology. What you never do is deny individual untagged resources — that gate teaches engineers to type garbage values under deadline, and a wrong tag is worse than a missing one because nobody knows to fix it.
The warnings buy your credibility. First: run one quarter of showback — reports without money moving — before chargeback, because the first report always contains attribution surprises, and you want those argued over a PDF, not an invoice. Second: some spend is genuinely shared — networking, the Class 28 workspace, Defender — so agree the allocation rule for it up front; the alternative is every team disputing the remainder monthly. Third: report the untagged percentage as its own line and drive it toward zero in the open. The sentence for finance: tags make the invoice attributable; policy makes the tags reliable; and the first quarter is for finding out where we were wrong quietly.
Concede the discount before you argue the shape. The 72% is not vendor fiction — deep commitment discounts on the right workload are the single largest price lever in the cloud, and leadership is right to want them. What the slide omits is the condition: the discount pays out only for hours in which usage matches the committed shape, and it is use-it-or-lose-it hour by hour. "Up to 72% off" is accurate; "off usage identical in size, family, and region for thirty-six consecutive months" is the clause. So the response is not "no" — it is "yes, on the slice of the estate that can honestly sign that clause."
Then show them this bootcamp's own history as the risk register. In thirty-two classes Campux has moved workloads from VMs toward containers that scale to zero, resized machines, and changed regions for private connectivity — each move a good decision, and each one would have stranded a three-year reservation bought the week before it. Estates that are still improving are precisely the estates that should commit narrowly. The method, from §4: chart ninety days of usage; reserve only the flat floor that survived the §2 cleanup (commitments bought before cleanup lock in the price of the waste); lay a savings plan over the steady-but-shifting middle, trading discount depth for the flexibility to keep re-architecting; leave the spikes on pay-as-you-go. Advisor's purchase recommendations, computed from your own usage, are the honest version of the slide.
Close with the number they actually want. Leadership asked for savings, not for reservations — reservations were just the slide they saw. So return a portfolio with expected savings attached: cleanup already banked (free, no commitment), a narrow reservation on the proven floor, a savings plan over the middle, reviewed quarterly as the estate settles — typically most of the slide's promise at a fraction of its risk. The closing sentence: the discount is rent we collect on predictability — we should sell Microsoft exactly as much predictability as we truly have, and not a dollar more.
Five things worth carrying out of this class
- The invoice is telemetry — every meter emits hourly, Cost Management charts it for free, and the data lags by hours to a day, which is why the forecast alert and the weekly review exist.
- Cost analysis is group-then-filter, and the waste hides in four usual suspects: orphaned resources, oversized compute, always-on non-production, and unrevisited ingestion. All four are expired decisions, not pricing problems.
- Budgets notify; they never stop anything — by design, because implicit enforcement is an outage waiting for a peak. Actual 80/100, forecasted 100, routed to the owning team's action group.
- Commitments are billing constructs, use-it-or-lose-it per hour: reservations buy the deepest discount on a fixed shape, savings plans a smaller one on flexible compute. Commit to the measured flat floor, after cleanup, never to the slide.
- Tags are the join key between the invoice and the org chart: a closed cost-center list, inherited from resource groups by policy — because tags do not flow downhill on their own — with deny reserved for the one gate at group creation.
- The lag between usage and its appearance in cost reports varies by service and billing account type — figure hours for most meters, up to a day or two for some, with the month's final invoice reconciling small differences. Treat any same-day cost number as provisional, and treat the specific dollar figures in this class's examples the same way you treat all of our numbers: the amounts are illustrative; the proportions and the failure modes are the settled part. ↩
- One genuine exception exists: certain subscription types with hard caps — notably some free-tier and credit-based subscriptions like Visual Studio benefits — can suspend when credit runs out. On the pay-as-you-go and enterprise subscriptions you will run at work, the statement holds without asterisk: budgets notify, nothing more. ↩
- Reservation mechanics beyond this class's scope, worth knowing exist: instance-size flexibility lets a reservation's discount cover other sizes within the same VM family; reservations can be scoped to a subscription, a resource group, or shared across the billing account; and exchanges and refunds are possible within limits Microsoft has changed before and will change again. Check the current exchange policy before you rely on it in a purchase decision — it is the fine print that determines how reversible your commitment really is. ↩