Microsoft gives you about a dozen things with “Monitor,” “Log,” or “Defender” in the name. Here’s what each one actually does — and how to pick the right one without ingesting your budget into oblivion.
If you’ve ever stared at the Azure and Microsoft 365 portals trying to figure out whether you want Azure Monitor, Log Analytics, Application Insights, Sentinel, Defender, or Purview — you’re not alone. The names overlap, the products overlap, and Microsoft keeps reorganizing where they live. The confusion is real, but it mostly dissolves once you stop asking “what tool do I use?” and start asking “what question am I trying to answer?”
Because there are really only three questions:
- Is my system healthy and performing? → the Azure Monitor family
- Is something malicious happening? → the Defender / Sentinel family
- Who did what, and can I prove it later? → Microsoft Purview Audit
Get those three straight and the whole landscape clicks into place. Let’s go through each family, then I’ll give you a one-glance cheat sheet at the end.
Family 1: Operational health — the Azure Monitor stack
This is the “are my apps and infrastructure working” family. Three names get used almost interchangeably here, which is the root of most confusion, so let’s pull them apart.
Azure Monitor
The umbrella. Azure Monitor is the overall platform for collecting, analyzing, and acting on telemetry from Azure resources, on-premises systems, and other clouds. When people say “Azure Monitor,” they usually mean the whole monitoring ecosystem — metrics, logs, alerts, dashboards, the lot. Think of it as the brand name for the family rather than a single screen you go to.
Use it when: you’re thinking about infrastructure- and resource-level health — VM CPU, storage throughput, resource availability, platform metrics, and alerting across your estate.
Log Analytics
Log Analytics is the storage-and-query layer underneath Azure Monitor. Your logs land in a Log Analytics workspace, and you query them with KQL (Kusto Query Language). It is where the data lives and where you write the queries that turn raw logs into answers.
A practical note: the old Log Analytics agent (the “MMA”) was retired in 2024. The Azure Monitor Agent (AMA) is its replacement, and data collection is now configured through Data Collection Rules. If you’re still running anything on the legacy agent, that’s a migration you’ve already missed the deadline on.
Use it when: you need to run ad-hoc queries across logs from many sources, build custom log-based alerts, or join telemetry from different services in one place.
Application Insights
Application Insights is application performance monitoring (APM). It’s built on top of Azure Monitor Logs but is laser-focused on your code: request rates, response times, dependency calls, exceptions, distributed traces, and real user behavior. Its standout features — the application map and end-to-end transaction tracing — are about understanding how a request flows through your services and where it breaks.
Note that classic Application Insights resources are gone; everything is workspace-based now, which is why App Insights and Log Analytics increasingly feel like two views over the same data lake.
Use it when: you own an app — a web app, an API, a Function — and you want to know why it’s slow, what’s throwing exceptions, and how users actually move through it.
The quick rule for Family 1
| You want to know… | Reach for |
|---|---|
| Is my infrastructure up and healthy? | Azure Monitor (metrics, alerts) |
| What do the logs say across everything? | Log Analytics (KQL queries) |
| Why is my app slow or erroring? | Application Insights (APM, traces) |
In practice you use all three together: App Insights for deep application visibility, Log Analytics for the broader query surface, Azure Monitor for platform metrics and alerting on top.
This is the “is someone attacking me” family. The two names that matter are Microsoft Defender XDR and Microsoft Sentinel, and the single most important recent change is that they now live in the same place.
Family 2: Security monitoring — Defender XDR and Sentinel
Microsoft Defender XDR
Defender XDR (extended detection and response) unifies prevention, detection, and response across endpoints, identities, email, and cloud apps — pulling together Defender for Endpoint, Defender for Identity, Defender for Office 365, and Defender for Cloud Apps into one consolidated view with automatic incident timelines. Crucially, it’s included with E5 / E5 Security licensing, so for a Microsoft-365-native shop it’s largely “already paid for.”
Use it when: your world is mostly Microsoft 365 and Azure, and you want strong native detection and automated response without standing up a full SIEM.
Microsoft Sentinel
Sentinel is the cloud-native SIEM (with SOAR, UEBA, and threat intelligence built in). Its job is to ingest everything — M365, Azure, AWS, GCP, on-prem firewalls, network gear, third-party SaaS — correlate it, and give you a single pane for detection and response across your whole digital estate. The catch is the cost model: Sentinel is billed roughly per gigabyte ingested, with commitment-tier discounts. The good news is that Microsoft 365 audit data and Defender XDR alerts are free to ingest; it’s your custom logs, network gear, and third-party sources that you pay for. The newer Sentinel data lake is Microsoft’s answer to keeping that bill manageable while retaining more data for AI-driven SecOps.
Use it when: you have a real SOC and meaningful non-Microsoft data sources, or you need one correlated view across multiple clouds and vendors.
The convergence you can’t ignore
Both Defender XDR and Sentinel are now fully integrated in the Microsoft Defender portal — one place for incidents, advanced hunting, and table management. When you onboard a Sentinel workspace under Defender XDR licensing, the XDR connector is wired up automatically and incidents flow between them in minutes.
And the deadline that should be on your calendar: managing Microsoft Sentinel in the Azure portal sunsets on March 31, 2027. New tenants are already being pushed to the Defender portal. The transition itself carries no extra cost, but it’s not just a menu change — KQL queries used for detections, custom analytics, and audit evidence can behave differently (renamed or unified fields), so anything important needs re-validation before you cut over.
The common end state for most enterprises: run both — Defender XDR for native Microsoft detection, Sentinel as the unifying SIEM that pulls XDR’s incidents in alongside everything else.
Advanced Hunting
Worth a mention on its own: Advanced Hunting is the KQL-based, proactive threat-hunting experience in the Defender portal. Where Defender XDR alerts you to known-bad patterns, Advanced Hunting is how you go looking — writing your own queries against raw telemetry to find the things no rule caught yet. (This is also where those Copilot Studio agent-misconfiguration hunting queries from my last post live.)
Family 3: The audit trail — Microsoft Purview Audit
Here’s the distinction people miss most often: security monitoring is not the same as auditing. Defender and Sentinel exist to alert you to threats. Microsoft Purview Audit exists to answer “who did what, when, and to what” — for investigations, compliance, and the regulator who shows up a year later asking for evidence.
Purview’s Unified Audit Log captures activity across Exchange, SharePoint, OneDrive, Teams, and more. Notably, it has been expanded to capture Copilot interactions — including who grounded a prompt with what data. If your governance program cares about that (and it should), make sure your audit retention policy actually covers the Copilot schema, because default retention may not.
You can investigate directly in Purview, or ingest the audit log into Sentinel and hunt there — which is exactly how a mature SOC adds a “who touched the data” lens during an incident.
Use it when: the question is forensic or regulatory — “show me everyone who accessed this file,” “what did this user do before they left,” “prove our breach-reporting timeline.” This is the layer that feeds compliance obligations like DORA and NIS2.
Bonus: monitoring AI workloads (the part this site cares about)
Since this is a notes site about Microsoft’s AI products, it’s worth saying where these tools land when the thing you’re watching is an AI system:
- Custom GenAI apps (Azure OpenAI, Azure AI Foundry): use Application Insights and Azure Monitor for token usage, latency, prompt/response traces, and evaluation metrics. Foundry’s tracing hooks straight into this stack.
- Copilot and Copilot Studio agents: use Purview Audit for the prompt-and-grounding trail, and Defender Advanced Hunting to detect agent misconfiguration and abuse patterns.
- Cross-everything correlation: pipe the above into Sentinel when you need agent activity sitting next to the rest of your security signal.
The pattern mirrors the three questions: App Insights for “is the AI app healthy,” Defender/Sentinel for “is the AI being abused,” Purview for “who prompted what.”
The one-glance cheat sheet
| Your question | Tool | Family |
|---|---|---|
| Is my infrastructure healthy? | Azure Monitor | Operational |
| What do my logs say (KQL)? | Log Analytics | Operational |
| Why is my app slow/erroring? | Application Insights | Operational |
| Detect & respond on M365/endpoints? | Defender XDR | Security |
| One SIEM across all clouds & vendors? | Microsoft Sentinel | Security |
| Hunt proactively for unknown threats? | Advanced Hunting (Defender) | Security |
| Who did what, for compliance? | Purview Audit | Compliance |
| Is my AI app healthy? | App Insights / Azure Monitor | Operational |
| Is my Copilot/agent being abused? | Purview + Defender hunting | Security/Compliance |
The takeaway
The mental model that saves you: operational health, security threats, and audit evidence are three different jobs, and Microsoft has a distinct family for each. Most teams need a bit of all three. The mistakes I see most often are pointing a SIEM at a problem that App Insights would answer for free, paying to ingest data into Sentinel that you only ever needed for occasional audit lookups, and assuming Defender’s alerting gives you the audit trail it doesn’t.
Pick the family by the question, mind the Sentinel-in-the-Defender-portal move before 2027, and watch your ingestion costs like a hawk.
Sources and further reading
- Microsoft Learn — Azure Monitor overview, Application Insights overview, and SIEM & XDR: incident response with Sentinel and Defender
- Microsoft Security — Microsoft Sentinel: AI-ready platform (SIEM/SOAR/UEBA, data lake)
- Microsoft Tech Community — What’s new in Microsoft Sentinel and XDR: Unified SecOps (Defender-portal migration, March 31, 2027 sunset, cost model)
- Turbo360 / w3tutorials — Application Insights vs Log Analytics: use cases
- The Security Everywhere — Microsoft Purview with Unified SecOps (Copilot audit schema)
- SoftwareOne — When is Microsoft Defender XDR the right fit? (E5 licensing, DORA/NIS2 audit trail)
Leave a Reply