Azure Monitor & Cost Management
Azure Fundamentals
Chapter 9 · Azure Monitor & Cost Management
AWS Fundamentals Chapter 9 covered CloudWatch's own genuine memory/disk-space monitoring gap, and the real, critical distinction between AWS Budgets alerting versus actually stopping spending. Azure's own equivalents share both real lessons — but Azure Monitor frames the first one through a genuinely richer, more explicit real model.
Azure Monitor's Real Four-Layer Model
Azure's own real documentation defines exactly four monitoring layers for a virtual machine, each with genuinely different real requirements:
| Layer | Collected Automatically? | Real Example Data |
|---|---|---|
| Virtual machine host | Yes — no agent needed | CPU utilization, whether the machine is running, configuration changes |
| Guest operating system | No — requires the Azure Monitor Agent | Memory usage, disk space, OS-level events |
| Workloads | No — requires the Azure Monitor Agent | Performance data and events from software running inside the VM |
| Application | No — requires Application Insights | Business application performance and traces |
A Real, Easy-to-Confuse Pair: Two Different Workspace Types
Azure Monitor's own real data platform uses two genuinely separate workspace types, despite their similar names: a Log Analytics workspace collects logs and traces, queried with Kusto Query Language (KQL); an Azure Monitor workspace collects Prometheus and OpenTelemetry metrics, queried with PromQL instead. They're real, separate resource types with different data stores — not two names for the same thing.
Alerts & Autoscale
Azure Monitor alerts watch a real metric or log query against a threshold and trigger a response once crossed — including real, AI-assisted dynamic thresholds that adapt automatically to a metric's own normal pattern, reducing false alarms compared to a single fixed number. Autoscale — Chapter 8's own VMSS scaling mechanism — is itself literally a feature of Azure Monitor, not a separate service: the same real metric data driving your alerts also drives your scale set's own capacity decisions.
Real Cost Management Tools
- Cost Management + Billing — Azure's own real cost analysis tool, breaking down spend by service, resource group, or tag, directly analogous to AWS's own Cost Explorer.
- Budgets — set a real, specific dollar threshold (based on actual or forecasted cost) and get notified when it's approached or crossed.
A Real, Distinctive Azure Feature: Action Groups on a Budget
Azure genuinely offers a more direct, built-in path to real automated response than simply pairing a budget with a separate notification service: when creating or editing a budget, you can attach an Action Group directly — triggering a mobile push notification, a webhook, an Azure Function, or a Logic App the moment a threshold is crossed. This doesn't change the core lesson (the budget itself still only observes and notifies) — but it makes wiring up a real, automated response noticeably more direct than in AWS's own equivalent workflow, where connecting a Budget alert to an automated action (like a Lambda function) has to be assembled from separate pieces.
CloudWatch vs. Azure Monitor
| Property | AWS (CloudWatch / Cost Explorer / Budgets) | Azure (Monitor / Cost Management) |
|---|---|---|
| Automatic host metrics | CPU, network, disk I/O | CPU, running status (a real, narrower default set) |
| Memory/disk-space gap | Needs the CloudWatch Agent | Needs the Azure Monitor Agent (guest OS layer) |
| Log/metric query language | CloudWatch Logs Insights (one system) | KQL (Log Analytics) and PromQL (Azure Monitor workspace) — two separate systems |
| Budget behavior | Alerts only, never stops spending | Alerts only, never stops spending — real, identical behavior |
| Built-in automated response | Assembled via SNS + Lambda separately | A real, direct Action Group attachment on the budget itself |
Hands-On Exercises
A team assumes Azure Monitor is already tracking disk space usage on their VMs, but an alert never fires before a disk actually fills up. Using the real four-layer model, explain, in your own words, why this happened and what real step was missing.
📄 View solutionA team wants to query both their application's own log traces and Prometheus-based container metrics using the same query language and the same workspace. Explain, in your own words, why this expectation is incorrect under Azure Monitor's own real data platform.
📄 View solutionA team sets an Azure Budget at $10,000/month with no Action Group attached, and a compromised credential is later used to launch unauthorized compute. Explain, in your own words, why the Budget alone would not have prevented the unexpected charges, and how attaching an Action Group could have changed the outcome.
📄 View solutionChapter 9 Quick Reference
- Four real monitoring layers — host (automatic), guest OS/workloads (need the Azure Monitor Agent), application (needs Application Insights)
- Real gap: memory and disk-space data live at the guest OS layer, not automatically collected — the same real lesson as CloudWatch's own gotcha
- Log Analytics workspace (KQL, logs/traces) vs. Azure Monitor workspace (PromQL, Prometheus/OpenTelemetry metrics) — two separate real systems
- Autoscale is literally a feature of Azure Monitor, directly powering Chapter 8's own VMSS scaling
- Real, confirmed: Azure Budgets alert only — "Resources aren't affected, and your consumption isn't stopped"
- Real distinctive feature: an Action Group can be attached directly to a budget for a genuinely automated response