Azure Cost Management Fundamentals

Why this matters

The Inform phase from module 00 says "you can't manage what you can't see" — this module is where you actually learn to see. Azure Cost Management is the built-in, free tool that turns the raw usage records you glimpsed last module into queryable, groupable, allocatable views. But it has two traps that mislead almost everyone the first time: the amortized-vs-actual cost distinction (which makes the same month look like two different bills) and the fact that grouping by tag only works if the tags were there at the time of usage — the exact create-time enforcement lesson from track 17 module 06. Get these right and every later module (budgets, showback, unit economics) rests on solid data.

Concepts

Cost Analysis is a pivot table over your usage records

Cost Analysis is the primary view in Azure Cost Management. Mentally, it's a pivot table over the usage records you saw in module 00: every line of usage has a cost, a date, a resource, a resource group, a subscription, a service (meter), a location, and — crucially — the resource's tags. Cost Analysis lets you pick a scope (subscription, resource group, or management group — the same hierarchy from track 17), a time range (this month, last month, a custom range, or billing period), a granularity (daily/monthly), and then group by and filter by any of those dimensions. That's the whole model: scope → time → group/filter. The portal's charts and the az costmanagement query CLI are two front-ends over the exact same query engine, so anything you can see in the portal you can pull from the CLI (and script into a report — the basis of module 06's showback). The mental shift from module 00's raw az consumption usage list is that you're no longer reading individual records — you're aggregating them along a dimension that answers a question.

Grouping by tag: allocation in action (track 17 module 06)

The single most valuable grouping is by tag — and this is the direct payoff of the taxonomy you built in track 17 module 06. Grouping cost by CostCenter answers "which team/budget does this spend belong to?"; grouping by Environment answers "how much is dev costing vs prod?"; grouping by Owner answers "who do I talk to about this line?". This is cost allocation: taking one undifferentiated subscription invoice and splitting it along the dimensions your org cares about, without needing a subscription per team. But there's a hard limit you must internalize now: Cost Analysis groups a usage record by the tags that record carried at the time of usage. A resource that was untagged when it ran shows up under "(untagged)" forever — backfilling the tag today does not re-allocate last month's cost. This is the same point track 17 module 06 made about why the create-time Deny matters, now seen from the cost side: your allocation is only as complete as your tagging was when the money was spent. The size of the "(untagged)" bucket is your allocation gap, and shrinking it is a prerequisite for trustworthy showback (module 06) and unit economics (module 00).

Caveat — not every resource type tags into cost the same way. Some costs (e.g. certain shared/marketplace/bandwidth meters) don't inherit resource tags onto their usage records, so even a perfectly tagged estate has some unallocatable cost. The job is to shrink "(untagged)" to the irreducible minimum, not to obsess over reaching zero.

Amortized vs. actual cost — the same month, two numbers

This is the distinction that makes people think Cost Management is broken. Actual cost shows charges on the day they were billed. Amortized cost takes any upfront or recurring commitment purchase — most importantly a reservation or savings plan (module 05) — and spreads its cost evenly across the period it covers, attributing the daily slices to the resources that actually consumed the benefit. A concrete example: you buy a 1-year Reserved Instance for $8,760 up front on July 1.

• Actual cost shows an $8,760 spike on July 1 and then $0 for that VM's compute for the next 365 days (it's "already paid for").
• Amortized cost shows ~$24/day every day for a year, attributed to the VM that used the reservation — and nothing on July 1 for the purchase itself.

Neither is wrong; they answer different questions. Actual matches your bank statement / invoice (finance cares about cash flow and when money left the account). Amortized matches usage and is what you want for rightsizing, allocation, and unit economics — because it tells you what a resource truly costs to run per day, not the accident of when you prepaid. Rule of thumb: use amortized for engineering decisions and showback, actual for reconciling the invoice. If two people compare "the cost of prod last month" and get different numbers, this toggle is almost always why.

Scope, and why it mirrors the governance hierarchy

Every cost query has a scope, and the scopes are the same tree you built in track 17: management group → subscription → resource group → individual resource. Scope determines both what's included and who's allowed to see it (Cost Management respects RBAC and adds cost-specific roles like Cost Management Reader). Choosing scope well is half the skill: a management-group scope rolls up every subscription under it into one view (how a platform team sees total org spend and does cross-subscription allocation), while a resource- group scope narrows to one app or environment. This is why track 17's structure wasn't just governance hygiene — a clean MG/subscription/RG hierarchy is your cost-allocation hierarchy. When a budget (module 02) or a showback report (module 06) is scoped wrong, it's almost always because someone picked the wrong node in this tree — a mistake you'll deliberately reproduce and fix next module.

Cost Management is free, near-real-time-ish, and lags a bit

Two operational facts that shape every exercise in this track. First, Cost Management itself is free — analyzing, grouping, budgeting, and exporting cost data costs nothing (you only pay for the resources being measured). Second, cost data lags: usage typically takes 8-24 hours to appear, and the current day/period is always an incomplete, moving estimate. This is why "today's cost is low" means nothing, why budgets (module 02) evaluate on a schedule rather than instantly, and why several exercises say "check back tomorrow." Forecasts — Cost Management's projection of where the current period will land — are built on this lagging data plus historical trend, which is why a forecast can swing early in a period and why forecast-based budget alerts (module 02) behave differently from actual-based ones. Internalize the lag now so you don't misread a chart later.

Command reference

The portal's Cost Analysis is the friendliest front-end, but the CLI is what you script into reports. az costmanagement query is the workhorse; it's free and read-only.

Flag breakdown — group month-to-date cost by the CostCenter tag (the track-17 allocation query):

az costmanagement query \
  --type AmortizedCost \
  --scope "/subscriptions/$(az account show --query id -o tsv)" \
  --timeframe MonthToDate \
  --dataset-grouping type=Tag name=CostCenter \
  --dataset-aggregation '{"totalCost":{"name":"PreTaxCost","function":"Sum"}}' \
  -o json

• --type AmortizedCost — use amortized (spread commitments) rather than ActualCost; this is the toggle from the concept above, and amortized is the right default for allocation. Switch to ActualCost to match the invoice.
• --scope "/subscriptions/<id>" — the node in the governance tree to analyze; swap for /providers/Microsoft.Management/managementGroups/<mg> to roll up the whole org, or a resource-group id to narrow to one app.
• --timeframe MonthToDate — the time range; other common values are TheLastMonth, BillingMonthToDate, or Custom with --time-period.
• --dataset-grouping type=Tag name=CostCenter — the allocation pivot: group by the CostCenter tag from track 17 module 06. Use type=Dimension name=ResourceGroup (or ServiceName, ResourceLocation) to group by a built-in dimension instead.
• --dataset-aggregation '{"totalCost":{...}}' — what to sum; PreTaxCost summed is the standard "how much did it cost" measure.

Flag breakdown — group last month's cost by resource group, sorted, for a quick waste scan:

az costmanagement query \
  --type ActualCost \
  --scope "/subscriptions/$(az account show --query id -o tsv)" \
  --timeframe TheLastMonth \
  --dataset-grouping type=Dimension name=ResourceGroup \
  --dataset-aggregation '{"totalCost":{"name":"PreTaxCost","function":"Sum"}}' \
  -o table

• --type ActualCost — here we want actual, because we're eyeballing which RGs billed the most last month, not doing per-resource allocation.
• --timeframe TheLastMonth — a complete period, so no lag/incompleteness distorts the ranking (unlike MonthToDate).
• --dataset-grouping type=Dimension name=ResourceGroup — group by the built-in ResourceGroup dimension; the biggest RGs are where module 03/04 optimization will pay off most.

Hands-on exercises

All read-only and free. Work against your real subscription; the messier its history, the more instructive. Cost data lags 8-24h, so don't expect today to look complete.

1. Open Cost Analysis and set scope + time. In the portal (Cost Management → Cost analysis) or via CLI, look at this month to date for your subscription. Note the total and mentally flag that today's slice is incomplete. This is your baseline view.

2. Group by service, then by resource group. Change the grouping to Service (which meters cost the most), then to Resource group. Same money, two different stories. Run the CLI equivalent:

   SUB=$(az account show --query id -o tsv)
   az costmanagement query --type ActualCost --scope "/subscriptions/$SUB" \
     --timeframe MonthToDate \
     --dataset-grouping type=Dimension name=ServiceName \
     --dataset-aggregation '{"totalCost":{"name":"PreTaxCost","function":"Sum"}}' -o table
   

   Write down your top three services by cost — that's where your money actually goes, and it's often surprising.

3. Group by the CostCenter tag (allocation in action). Run the --dataset-grouping type=Tag name=CostCenter query from the command reference. Observe how much cost lands under a real cost centre vs. under (untagged). The untagged bucket is your allocation gap.

4. Measure your allocation gap as a percentage. Group by Environment (or CostCenter) and compute what fraction of total spend is untagged. Write it down. This single number is the health metric for your Inform phase — module 06's showback is only as trustworthy as this is small.

5. Toggle amortized vs. actual and explain the difference. Run the CostCenter query twice, once with --type ActualCost and once with --type AmortizedCost, over TheLastMonth. If you have no reservations or savings plans, the totals will match — and understanding why they match (no commitments to spread) is as important as seeing them differ. Write down which you'd use for showback and which for reconciling the invoice.

6. Read a forecast. In the portal, extend the time range to include the rest of the current month and note the forecast line. Come back tomorrow and see whether the forecast moved. This lag-and-projection behavior is exactly what forecast-based budget alerts (module 02) react to.

7. Filter to one environment. Add a filter Environment = prod (or whatever value you use). You've now isolated prod's spend from a shared subscription — the poor-org's version of "a subscription per environment," made possible purely by tags. Note how a large "(untagged)" bucket undermines this filter's accuracy.

8. Diagnose and fix: "the numbers changed and I didn't touch anything." A very common real confusion. Reproduce it: look at last month's total in actual cost, note it, then look at the same month in amortized cost — if you have any reservation/savings plan, the totals and daily shape differ, and a teammate comparing the two "proves" the bill is wrong. Diagnose: nothing is wrong — one view spreads a commitment purchase across usage days and the other shows it on the purchase day. Fix: agree on a convention — this team uses amortized for engineering/allocation, actual for invoice reconciliation — and always state which view a number came from. (If you have no commitments, write down how the two would diverge once you buy a reservation in module 05, so the trap doesn't ambush you later.)

9. Grant scoped cost visibility (governance tie-in). Without giving anyone broader access, you can grant Cost Management Reader at a scope so a team lead sees only their spend. Inspect the role:

   az role definition list --name "Cost Management Reader" --query "[].{name:roleName, desc:description}" -o table
   

   Note that cost visibility is its own RBAC concern (track 16) — you can let finance read cost without letting them touch resources. (Don't assign it to a real person unless you mean to; just understand the role exists.)

Independent challenge

No commands given. Using this module (scope, grouping, amortized-vs-actual) and the tagging taxonomy from track 17 module 06, produce a one-page cost allocation snapshot of your real subscription for last month (a complete period). It must: pick and justify amortized vs. actual; break spend down by CostCenter and by Environment, each with an explicit (untagged) figure and percentage; identify your top three services and top three resource groups by cost; and end with two or three sentences on what your (untagged) percentage implies for the trustworthiness of a showback report (module 06) and a unit-cost metric (module 00). Draw the scope from track 17's hierarchy. The deliverable is the written snapshot plus the exact CLI queries you used, so it's reproducible next month.

Common mistakes & troubleshooting

• Comparing an amortized number to an actual number. They'll differ whenever a reservation/savings plan exists — one spreads the purchase across usage, the other bills it on the purchase day. Always state which view a figure came from.
• Expecting a backfilled tag to fix past cost. Cost Analysis groups by the tag a record had at the time of usage. Tagging a resource today does nothing for last month's allocation — enforce tags at create time (track 17 module 06).
• Reading today's incomplete cost as real. The current day/period lags 8-24h and is a moving estimate. Draw conclusions from complete periods (TheLastMonth), not from the current day's partial slice.
• Ignoring the "(untagged)" bucket. A big untagged fraction quietly makes every filter and allocation wrong. Measure it as a percentage and treat shrinking it as real work, not cleanup you'll get to eventually.
• Analyzing the wrong scope. Subscription vs. resource group vs. management group changes both what's included and what you're allowed to see. Confirm the scope node in the track-17 tree before trusting a total.
• Assuming perfect tags mean zero unallocatable cost. Some meters (bandwidth, certain shared/marketplace items) don't carry resource tags onto usage. Aim to minimize "(untagged)", not to reach a mythical zero.

Checkpoint quiz

Write down your answer to each question before expanding it — checking without attempting first is the single easiest way to fool yourself into thinking you've learned this.

Next

Continue to 02-budgets-and-alerts — you can now see and allocate spend; next you'll put guardrails on it. Budgets turn "we noticed the bill was high at month-end" into "we got alerted at 80% of plan," including the forecast-based alerts that warn you before the money is spent — and the scoping trap that makes a budget silently never fire.