Microsoft Sentinel vs Defender for Cloud: What's the Difference?
Two Microsoft security products, constantly confused, sitting next to each other in the portal. They do different jobs — and once you see the split, you stop guessing which one an interviewer, or your own architecture, is actually asking for.
New to cloud? CAMPUX is a free, build-first course. Start here →
Here is the whole answer in one line: Microsoft Defender for Cloud secures your resources — it finds misconfigurations and threats in your Azure, AWS, and GCP workloads. Microsoft Sentinel is your SIEM — it collects security signal from everything, correlates it, and runs the investigation. One protects the things you run. The other watches all the signal those things produce, plus signal from identity, endpoints, and on-premises, and turns it into incidents a human works. They overlap at exactly one seam, and Microsoft built a connector for it. Get that mental model straight and the rest of this is detail.
People trip over these two for a fair reason: the names changed. What you may remember as Azure Security Center is now Defender for Cloud; what you may remember as Azure Sentinel is now Microsoft Sentinel. If a comparison you are reading still uses the old names, it predates the current products — treat it with suspicion. The rest of this note uses the current names throughout.
What Defender for Cloud does (CSPM plus workload protection)
Defender for Cloud answers one question: are the resources I run configured safely, and is anything attacking them right now? It does that in two layers.
The first layer is cloud security posture management, or CSPM. It continuously scans your environment against a security benchmark, flags misconfigurations — a storage account open to the public, a VM missing disk encryption, a database without auditing — and rolls the whole picture into a Secure Score you can track over time. The foundational tier of this is free, and it spans Azure, AWS, and GCP. That is the piece almost every Azure customer ends up with, often without deciding to; it just shows up and starts scoring you.
The second layer is workload protection: the paid Defender plans. You switch on a plan per workload type — Defender for Servers, Defender for Storage, Defender for SQL, Defender for Containers, and so on — and each adds threat detection and hardening for that resource type. This is where Defender for Cloud stops describing your posture and starts catching live threats: a suspicious process on a VM, a malware upload to a blob, an anomalous SQL login.
The billing follows the shape of the product. Foundational CSPM is free. The Defender workload plans are priced per resource — per server per hour, per storage account, per database — so your bill tracks how many resources of each type you protect. If you want the deeper posture features (attack path analysis, agentless scanning, the security graph), that is the paid Defender CSPM plan, also billed by billable resource. The mental shortcut: Defender for Cloud costs scale with how much stuff you have.
Defender for Cloud is a CSPM plus workload-protection tool — it hardens and defends the resources you run, and you pay roughly in proportion to how many of them there are. It is not a place you go to investigate an incident end to end; it is a place that produces findings and alerts about your resources.
What Sentinel does (SIEM and SOAR, hunting, incidents)
Sentinel answers a different question: across my entire estate, what is happening, and can I investigate it in one place? It is a cloud-native SIEM — security information and event management — with SOAR (security orchestration, automation, and response) built in.
A SIEM is a collector and a correlator. You point log sources at it — Azure resources, Microsoft 365, Entra ID sign-ins, firewalls, endpoints, on-premises servers, third-party clouds — and it ingests all of that into one workspace. Then it runs analytics rules across the combined stream to surface incidents: not raw alerts, but grouped, prioritized cases a human works. Under the hood, Sentinel is built on a Log Analytics workspace, so its storage and query layer are the same ones Azure Monitor uses — which is why KQL is the language you hunt and investigate with.
What you actually do in Sentinel:
- Ingest and connect — data connectors pull signal from Microsoft and non-Microsoft sources into one workspace.
- Correlate into incidents — analytics rules turn many low-level events into a smaller set of investigable cases.
- Hunt — proactively query the data with KQL to find threats no rule caught yet.
- Respond with SOAR — playbooks automate the boring first steps: isolate a host, disable an account, open a ticket, notify the on-call.
That is a different job from Defender for Cloud. Defender for Cloud is opinionated about a set of resource types and their security state. Sentinel is deliberately source-agnostic; it is the place a security team lives when they need one console over everything, not just cloud resources.
Defender for Cloud tells you a resource is at risk. Sentinel is where an analyst decides whether that risk is one thread of a larger attack.
How they work together (the Defender connector into Sentinel)
They are not rivals; they stack. The seam between them is a data connector. Sentinel ships a Microsoft Defender for Cloud connector, and turning it on streams Defender for Cloud's alerts into your Sentinel workspace. From that point, a misconfiguration or threat Defender for Cloud detects becomes one more signal in Sentinel's correlation engine — sitting alongside identity events, endpoint alerts, and firewall logs.
That is where the value compounds. On its own, a Defender for Cloud alert says "this VM shows suspicious activity." Inside Sentinel, that same alert can line up with a risky Entra ID sign-in from minutes earlier and a burst of outbound traffic on the firewall — and now you are not looking at three disconnected alerts, you are looking at one incident with a story. Defender for Cloud is a first-class source of signal; Sentinel is where signals from many sources become a case.
Defender for Cloud detects. Sentinel investigates. The Microsoft Defender for Cloud connector is the pipe that carries the first into the second. If you run both, wire that connector early — it is the whole reason running both is worth more than running either alone.
Which one you actually need — by org size and team
The honest answer depends less on your Azure footprint than on whether you have people to work incidents.
Small shop, no security analysts. Turn on Defender for Cloud. The free posture management alone will flag your worst misconfigurations, and you can add a Defender workload plan or two on your most sensitive resources. You probably do not need Sentinel yet — a SIEM with nobody watching it is a cost with no payoff. Nobody hunts the logs; the incidents pile up unworked.
Growing org, first security hire or a managed provider. This is the crossover. You now have someone whose job is to investigate, and they want one console over cloud, identity, and endpoints. Add Sentinel, connect Defender for Cloud into it, and start with a narrow set of high-value log sources rather than ingesting everything on day one.
Enterprise with a SOC. You run both, and Sentinel is the center of gravity. Defender for Cloud is one of many connectors feeding it; the security operations center lives in Sentinel, hunting with KQL and automating response with playbooks. The interesting question at this scale is not whether to ingest, but which data is worth the ingestion bill.
The gap: cost models that decide the answer
Here is the part most comparisons skip, and it is the part that actually decides your architecture. The two products bill on completely different axes, and that difference — not features — is usually what settles which you lean on.
Defender for Cloud bills per resource. Foundational CSPM is free; the Defender workload plans and paid Defender CSPM are priced by the count of resources you protect — per server, per storage account, per database, roughly per hour. Your cost is predictable and it scales with your fleet. Double your servers, roughly double that slice of the bill.
Sentinel bills per gigabyte ingested. Sentinel charges for the volume of data you bring into and analyze in the workspace — not for how many resources you have. You can pay as you go per gigabyte, or commit to a daily commitment tier (these start at 100 GB per day) for a lower effective rate. Because the meter is data volume, a single chatty log source — verbose firewall logs, full network flow data — can cost more than a hundred quiet servers.
That difference has a real consequence. With Defender for Cloud, the cost question is "how many resources do I protect?" With Sentinel, the cost question is "which logs are actually worth ingesting?" A team that flips on every connector and streams every log into Sentinel can run up a bill that dwarfs their entire Defender for Cloud spend — and most of that data never gets queried. The discipline that keeps Sentinel affordable is choosing your sources, not collecting all of them. Treat log selection as an architecture decision, because on the invoice, it is one.
| Defender for Cloud | Microsoft Sentinel | |
|---|---|---|
| Category | CSPM + workload protection | SIEM + SOAR |
| Scope | Your cloud resources — Azure, AWS, GCP | Everything you connect — cloud, identity, endpoints, firewalls, on-premises |
| Primary job | Find misconfigurations and threats in resources; harden posture | Collect, correlate, hunt, and respond across all signal |
| Billing model | Free foundational CSPM; paid plans priced per resource | Per gigabyte ingested; pay-as-you-go or daily commitment tiers |
| Needs a SOC team? | No — useful even with nobody watching | Yes, in practice — a SIEM pays off only when people investigate |
| Multicloud? | Yes — native Azure, AWS, GCP posture | Yes — ingests from any source with a connector or API |
Read the table top to bottom and the decision falls out on its own. If your question is "is my cloud configured safely," that is Defender for Cloud, and the free tier gets you started today. If your question is "can my team see and investigate everything in one place," that is Sentinel — and you should size the ingestion before you switch on the connectors. Run both, wire the Defender connector between them, and you get posture and investigation feeding each other. Say that split cleanly in an interview and you sound like someone who has operated the tools, not someone who read the marketing page.
New to the posture side? Start with Defender for Cloud basics — Secure Score, plans, and where to look first. On the SIEM side, the query language is the skill that matters: KQL for beginners.
Questions people also ask
Is Microsoft Sentinel the same as Defender for Cloud?
No. Defender for Cloud is a cloud security posture and workload protection tool that finds misconfigurations and threats in your Azure, AWS, and GCP resources. Microsoft Sentinel is a cloud-native SIEM that collects logs and alerts from many sources, correlates them, and runs investigations. Defender for Cloud protects resources; Sentinel investigates signal across everything.
Do I need both Sentinel and Defender for Cloud?
Often, but not always. Most Azure customers turn on Defender for Cloud first because its foundational posture management is free and immediate. You add Sentinel when you have a security team that runs investigations and needs one place to correlate signals from cloud, identity, endpoints, and on-premises. A small shop with no analysts may run Defender for Cloud alone.
Is Sentinel a SIEM?
Yes. Microsoft Sentinel is a cloud-native SIEM with built-in SOAR. It ingests security data at scale, correlates it into incidents, supports threat hunting with KQL, and automates response through playbooks. It is built on a Log Analytics workspace, so its storage and query engine are the same ones Azure Monitor uses.
How much does Microsoft Sentinel cost?
Sentinel is billed by the volume of data you ingest and analyze, not per resource. You can pay as you go per gigabyte, or commit to a daily tier — commitment tiers start at 100 GB per day — for a lower effective rate. Because cost tracks data volume, the main lever is deciding which logs are worth ingesting.
Can Sentinel ingest Defender for Cloud alerts?
Yes. Sentinel ships a Microsoft Defender for Cloud data connector that streams Defender for Cloud alerts into your Sentinel workspace. Once connected, those alerts become part of Sentinel's correlation and incident engine, so a misconfiguration or threat Defender for Cloud finds can trigger a Sentinel investigation alongside signals from other sources.