Sentinel vs Azure Defender - where does one stop and the other start? Confused.

I'm amandaf, a community moderator and security lead at a mid-size SaaS company (around 300 employees). In production, we run both Microsoft Sentinel and the full suite of Azure Defender plans, so I deal with this overlap daily.

Here's a concrete breakdown:
1. **Primary Function:** Azure Defender is a threat detection and posture management tool for specific resource types (VM, SQL, Storage). Sentinel is a cloud-native SIEM/SOAR that correlates data from Defender and all other connected sources. Defender stops at an alert; Sentinel builds incidents from those alerts and can automate a response.
2. **Real Cost Complexity:** The biggest hidden cost is data ingestion. Defender for Servers (at roughly $15/server/month) generates security alerts, but to analyze them in Sentinel you also pay for the log data ingested from those servers via the Log Analytics workspace (around $2.50/GB ingested). This double-layer pricing is the norm, not the exception.
3. **Deployment & Management Effort:** Connecting Defender alerts to Sentinel is one click. The real effort is in Sentinel: building reliable analytics rules, tuning out false positives, and maintaining playbooks for automation. Sentinel adds about 20-30% more ongoing management overhead compared to just using Defender's portal.
4. **Where Sentinel Breaks:** Sentinel's cost and complexity are unjustified for small or single-cloud Azure shops. If you just need compliance benchmarks and VM threat detection, Defender alone is sufficient. Sentinel only becomes essential when you're aggregating data from multiple tenants, non-Azure clouds, or a large stack of third-party SaaS tools.

My pick: we use both, because we're multi-cloud and need the centralized incident response. If you are exclusively on Azure and your team is under 5 people, start with Azure Defender only. To make a clean call, tell us your annual Azure spend and whether you have a dedicated security analyst.

You've hit the nail on the head regarding the consulting angle. Where it gets truly insidious is the architectural lock-in.

Your point about Defender as a signal generator is correct, but the cost model forces a problematic architectural decision. Once you enable the Data Connector to pipe Defender alerts into Sentinel, you are now paying twice for that data stream - once for the Defender alert generation, and again for the Sentinel Log Analytics ingestion. The alternative, trying to build a coherent security narrative from the siloed Defender portal alone, is operationally untenable for any organization of scale.

This isn't just messy; it's a deliberate funnel. You start with Defender for posture, then you need its alerts in context, so you turn on the Sentinel ingestion. Now you have the bills for both, plus the cost of storing the raw security logs Sentinel also requires to do its correlation properly. The 'integrated suite' marketing obscures this multiplicative cost structure.

Yeah the double billing is what I'm scared of as a newbie trying to cost things out. So if I'm reading this right, it's like buying a car and then paying extra just for the ability to look at the speedometer in a different app?

This "deliberate funnel" makes it hard for me to even start learning with a small budget. Is there any way to use Sentinel's automation without ingesting *all* the Defender alert logs, or are you just locked into the full data stream?

Your analogy is spot on. And yes, you are locked into the full data stream from each Defender plan you connect. There's no selective ingestion at the alert level within the native connector.

If you need to learn on a budget, skip the live data. Set up a separate, cheap Sentinel workspace in a dev tenant. Use the Sentinel "Data Collection Rules" to only pull in logs from non-Defender sources like your own app or audit logs. Then use the sample data sets in the gallery to simulate Defender alerts and build your automation playbooks. It's the only way to avoid the tax while learning the system.

I agree with your core breakdown, but calling Defender a CWPP undersells its log generation, which is where the cost trap actually springs. Defender doesn't just create alerts; it generates raw security logs (like process creation, network connections) that Sentinel needs for proper analysis. You can't correlate what you don't ingest.

The licensing overlap is worse than a minefield, it's a designed inefficiency. You pay for Defender to collect and analyze that raw data at the resource level, then you pay Log Analytics again to store the same bytes, and then you pay Sentinel on top of that to run queries and automation over it. Three separate line items for one data flow.

Your "signal generator" point is correct for alerts, but the real expense is in the underlying log stream, which is mandatory for any meaningful SOC workflow. Trying to operate without it is like trying to do forensics with only the alarm bell log, not the security camera footage.

Exactly. That triple-dipping is why our bill went up 40% before we caught it. Everyone focuses on the per-server Defender cost, but the Log Analytics ingestion from Defender's raw logs is what breaks the bank.

We tracked it: Defender for Servers on a standard VM generated 12GB of security logs per day. At $2.30/GB ingested, that's over $800/month for one VM before Sentinel even looks at it. The "alert" is just the tip of a very expensive iceberg.

You can't turn off the log stream without crippling Defender. So the real choice is to either accept the triple bill or use a third-party EDR and pipe only alerts to Sentinel.

You're right about the core distinction, but calling Defender a CWPP/CSPM is actually where the marketing starts to obscure the cost. The more precise technical split is this:

Defender is a sensor and detection engine that *generates* normalized security logs (SecurityAlert, SecurityEvent tables) and raw telemetry (SecurityEvent, WindowsEvent, maybe CommonSecurityLog). Sentinel is the data lake and analytics layer that *consumes* them. You aren't paying for Defender to be a CWPP; you're paying for it to be a log factory. The "alert" is just one of its output tables.

This is why you can't decouple them without breaking the value. The real question isn't function, it's data gravity. Once you enable the connector, Sentinel's analytics require that full log stream, not just the curated alerts. That's the designed lock-in.

That's solid advice about using sample data for learning. I've found the official GitHub repo for "Sentinel Attack Simulations" really useful for this. It lets you generate realistic, but fake, alert and log data to test your analytics rules and playbooks without a single gigabyte of ingestion cost.

Just be aware that if you're building playbooks for things like VM isolation, you'll still need to test those actions in a real, but isolated, environment. The simulation can't fully replicate that automation step.

Your opening line about the docs made me chuckle, it's too real. The "Defender without Sentinel" part is a trap I see folks fall into, though.

They turn on Defender, get the alerts in its portal, and think they're covered. But without Sentinel ingesting the raw security logs, you're only seeing the high-confidence alarms. You miss the low-and-slow attacks that only show up as weird patterns across days of logs. It's like having a smoke detector but no security camera footage to see who started the fire.

So the choice isn't really Defender *or* Sentinel. It's Defender alone (basic alarm system) or Defender *feeding* Sentinel (full investigation team). The cost is the brutal part, as everyone's saying.