Azure Cost Management: Budgets, Tags, and Advisor

What: apply the agreed tags to every resource in tyf-rg in one pass. Why: Cost Analysis can only group spend by tags that actually exist on the resources. Untagged resources land in an "untagged" bucket, and once a bill is generated, historical spend cannot be re-tagged retroactively, the attribution only starts from the moment the tag is applied.

The command resolves every resource ID in the group, then merges the two tags onto each one. By default az resource tag performs a merge: existing tags are kept and the new keys are added or overwritten. Passing --operation replace instead would wipe any tags already present, rarely what you want.

Tag the resource group itself too. Resource group tags are not inherited automatically (Step 05 fixes that with policy), but having them in place makes the inheritance policy meaningful:

VERIFY, EVERY RESOURCE CARRIES BOTH TAGS

az resource list -g tyf-rg --query "[].{name:name, type:type, project:tags.project, env:tags.env}" -o table

Expected output:

$ az resource list --tag env=lab -o table
Name      ResourceGroup    Type
--------  ---------------  ---------------------------------------
tyf-vm01  tyf-rg           Microsoft.Compute/virtualMachines
tyf-vnet  tyf-rg           Microsoft.Network/virtualNetworks

What this teaches: Tags are the only way to attribute shared-subscription spend to teams and projects; design the convention before resources exist.

What: define a monthly spending cap and wire alert thresholds to an email action group. Why: a budget without notifications is just a chart, you only look at it after the damage is done. Alerts at 80% of actual spend and 100% of forecasted spend give you time to react while the month is still recoverable.

The minimal form creates a budget with default settings:

The start and end dates are required: the start must be the first of a month, so the example computes it from today and the example sets an end date one year out; adjust both to your own window.

--category Cost means the budget tracks actual billed cost (including taxes and marketplace charges where applicable), as opposed to Usage, which tracks raw consumption. For personal guardrails, Cost is the right choice, it matches what the invoice will show.

Worth knowing before you create anything: budgets are scoped. Created with no extra flags (as here) a budget watches the whole subscription. Pass --resource-group tyf-rg to scope it to one group instead, useful for capping a single experiment without noise from the rest of the subscription. Enterprise environments can also scope budgets to billing accounts and management groups, but the CLI pattern stays the same.

To actually receive alerts, first create an action group with your email as a receiver, then attach it to the budget's notifications. An action group is Azure Monitor's reusable "who to notify" object, so the same group can later serve uptime alerts and security alerts too:

CREATE THE ACTION GROUP AND CAPTURE ITS ID

az monitor action-group create -g tyf-rg -n budget-alerts \
  --short-name budgalrt \
  --action email taki [email protected] -o table

AG_ID=$(az monitor action-group show -g tyf-rg -n budget-alerts --query id -o tsv)
echo $AG_ID

Expected output:

$ az monitor action-group show -g tyf-rg -n budget-alerts --query "{name:name, receivers:length(emailReceivers)}" -o table
Name           Receivers
-------------  -----------
budget-alerts  1

Before relying on the path, verify the receiver address: a typo in the email fails silently, no bounce, no error. Run the throwaway-budget test in the validation section and confirm the alert arrives (check spam for the first message from the Azure sender); only then trust the budget alerts.

Now recreate the budget with explicit start/end dates and two notification thresholds. Start dates for a Monthly grain must fall on the first of a month, and cannot be in the past beyond the current month:

BUDGET WITH 80% ACTUAL AND 100% FORECASTED ALERTS

az consumption budget create \
  --budget-name tyf-monthly \
  --amount 50 \
  --category Cost \
  --time-grain Monthly \
  --start-date 2026-09-01 \
  --end-date 2027-09-01 \
  --notifications '{
    "actual_GreaterThan_80_Percent": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 80,
      "contactEmails": ["[email protected]"],
      "contactRoles": [],
      "contactGroups": ["<paste the echoed action group ID here, the single quotes prevent $AG_ID from expanding>"]
    },
    "forecasted_GreaterThan_100_Percent": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 100,
      "contactEmails": ["[email protected]"],
      "contactRoles": [],
      "contactGroups": []
    }
  }'

Each notification key encodes its own condition: actual_GreaterThan_80_Percent fires when billed spend passes 80% of $50, and forecasted_GreaterThan_100_Percent fires when Azure's forecast predicts you will exceed the budget by month-end. The forecast alert is the early warning; the actual alert is the confirmation.

What this teaches: Budgets watch the future while alerts make them actionable; a budget nobody gets notified about is decoration.

What: pull Azure Advisor's Cost recommendations and act on them. Why: Advisor watches utilization signals you would have to dig out of metrics yourself, CPU averages, network throughput, disk IOPS, and turns them into concrete money-saving actions with an estimated saving attached.

The table view is enough to triage, but the real decision data lives in the recommendation's fields: which resource, what the problem is, and what Advisor suggests. Query them directly:

FULL RECOMMENDATION DETAIL

az advisor recommendation list --category Cost \
  --query "[].{resource:impactedField, impact:impact, problem:shortDescription.problem, fix:shortDescription.solution}" \
  -o table

Expected output:

$ az advisor recommendation list --query "[].{category:category, impact:impact}" -o table
Category    Impact
----------  --------
Cost        High
Cost        Medium

Typical actions from this output:

• Right-size: az vm resize -g tyf-rg -n tyf-vm01 --size Standard_B2s if the VM idles at 5% CPU.
• Deallocate: az vm deallocate -g tyf-rg -n tyf-vm01 stops billing for compute (disks still bill). A plain stop from inside the OS does not stop compute charges.
• Delete orphans: unattached disks and old public IPs keep billing after their parent VM is gone. Find disks with az disk list --query "[?diskState=='Unattached']" -o table.

Advisor's Cost category recycles a handful of recommendation types. Knowing them by name makes the triage faster:

What this teaches: Advisor recommendations are suggestions with dollar amounts attached; review each one before applying, since rightsizing is not always safe.

What: query month-to-date cost grouped by the project tag. Why: this is the showback payoff from Step 01, instead of one opaque subscription total, you get a per-project number you can hand to a team lead or use to decide which experiment is worth keeping.

MONTH-TO-DATE COST GROUPED BY THE project TAG

az costmanagement query --type ActualCost \
  --timeframe MonthToDate \
  --dataset-granularity None \
  --dataset-grouping name="project" type="TagKey" \
  -o table

Expected output:

Cost Analysis grouped by tag project: demo-web shows $18.42 month-to-date; untagged shows $6.10 month-to-date.

The (untagged) row is your hygiene metric: it represents spend you cannot attribute. The goal over time is to drive it to zero. A nonzero value right after tagging is normal, usage records from before the tags were applied stay untagged, and new cost data can take 8-24 hours to appear.

What this teaches: Cost Analysis turns raw meter lines into answers by grouping on the dimensions you care about, usually tags.

What: assign two built-in policies at the resource group scope: one requires the project tag on new resources, the other inherits it from the resource group. Why: manual tagging decays the moment someone deploys through the portal at midnight. Policy makes the convention self-enforcing so Step 04's untagged bucket stays empty without babysitting.

Built-in policies are referenced by ID, so look them up by display name first, never paste a GUID from a blog post without resolving it against your own tenant:

RESOLVE THE BUILT-IN POLICY IDS

REQ_ID=$(az policy definition list --query "[?displayName=='Require a tag on resources'].id" -o tsv)
INH_ID=$(az policy definition list --query "[?displayName=='Inherit a tag from the resource group'].id" -o tsv)
echo "$REQ_ID"; echo "$INH_ID"

Expected output:

{
  "name": "require-owner-tag",
  "properties": {
    "enforcementMode": "Default",
    "provisioningState": "Succeeded"
  }
}

ASSIGN BOTH POLICIES TO tyf-rg

SCOPE=$(az group show -n tyf-rg --query id -o tsv)

az policy assignment create --name require-project-tag \
  --policy "$REQ_ID" --scope "$SCOPE" \
  --params '{"tagName":{"value":"project"}}'

az policy assignment create --name inherit-project-tag \
  --policy "$INH_ID" --scope "$SCOPE" \
  --params '{"tagName":{"value":"project"}}'

The Deny-effect policy blocks new deployments missing the tag; the Modify-effect inherit policy silently copies the resource group's tag onto anything created without one. Together they cover both the "refuse" and "auto-fix" philosophies, in a real environment you typically pick one.

What this teaches: Policy turns a tagging convention into a rule the platform enforces at deploy time, when it is cheapest to comply.

What: confirm the budget is tracking real spend and that the alerting path is live. Why: a governance setup you have never seen fire is a hypothesis, not a control.

BUDGET TRACKING CURRENT SPEND

az consumption budget show --budget-name tyf-monthly \
  --query "{amount:amount, currentSpend:currentSpend.amount, unit:currentSpend.unit}" -o table

Expected output:

$ az consumption budget show --budget-name tyf-monthly --query "{amount:amount, currentSpend:currentSpend.amount, unit:currentSpend.unit}" -o table
Amount    CurrentSpend    Unit
--------  --------------  ------
50.0      36.29           USD

You cannot force a budget alert on demand, it fires only when cost data crosses a threshold. The practical test is to temporarily create a throwaway budget of --amount 1 (below your real spend) with your email attached; the 80% actual alert fires on the next evaluation cycle and proves the delivery path. Create it, wait for the alert email, then delete it:

What this teaches: The loop only works continuously: tag, budget, review, enforce, repeat. A one-time pass decays within weeks.