All in Sentinel data lake

What Advance Hunting Tables too

I am are you?

Microsoft just made data lake tier ingestion generally available for XDR Advanced Hunting tables in Microsoft Sentinel. If you’re running Sentinel today, this changes how you should think about your data strategy. Here’s the bottom line.

1. Stop Losing Your Advanced Hunting Data

Every query you run in Advanced Hunting generates high-fidelity telemetry — endpoint process events, email delivery logs, cloud app activity, identity signals. By default, that data lives in the Defender portal with limited retention. When it ages out, it’s gone.

Sending Advanced Hunting logs into Sentinel’s data lake means you keep that telemetry long-term at a fraction of the cost. Think of it as your security data warehouse. Need to hunt across six months of DeviceProcessEvents or correlate EmailEvents from last quarter with today’s incident? That’s now practical and affordable. Retention without regret.

2. Data Lake Ingestion vs. Analytics Tier — Pick the Right Lane

Here’s where cost optimization gets real. The Analytics tier is your real-time detection engine — logs land, analytics rules fire, alerts generate. But not every data source needs real-time detection logic running against it.

Direct data lake ingestion gives you a lower-cost tier for tables that are primarily used for hunting, investigation, and compliance rather than real-time alerting. Endpoint file certificate info (DeviceFileCertificateInfo), image load events (DeviceImageLoadEvents), or URL click telemetry (UrlClickEvents) — these are invaluable during investigations but rarely drive standalone detection rules. Routing them to the data lake tier instead of Analytics can dramatically reduce your ingestion costs while keeping every byte searchable via KQL.

The play: put your detection-critical tables in Analytics, and route your investigation and hunting tables to the data lake.

3. Send Network Logs to the Lake Too

Here’s the move most teams hesitate on — but shouldn’t. Firewall logs, DNS queries, proxy traffic, NDR telemetry — this is some of the highest-volume data in your environment and the most expensive to keep in the Analytics tier. Route it directly into the data lake. The volume-to-detection ratio on raw network logs rarely justifies real-time analytics pricing. You’ll keep full visibility across network telemetry at a fraction of the cost, and it’s all still searchable via KQL when an investigation demands it.

4. Going All-In on the Lake? Build the Muscle

If you’re committing to a lake-first strategy and keeping only a thin slice in the Analytics tier, you need to evolve your detection workflow to match. That means building scheduled lake search jobs that run daily detections across your data lake tables — think of them as your async detection engine. Pair that with weekly structured hunts across the lake to surface patterns that scheduled queries might miss.

Once that foundation is solid, the next step is looking at agents that can leverage the data lake alongside Microsoft’s Security Graph — using graph edges and nodes for deep correlation across identities, devices, and threat signals. That’s where the lake-centric model pays off: massive data coverage, low cost, and AI-driven correlation that scales beyond what manual rule-writing ever could.

What’s Supported Now

The GA release covers tables from Defender for Endpoint, Defender for Office 365, and Defender for Cloud Apps — with Defender for Identity coming soon. This is a direct signal that Microsoft is going all-in on a lake-centric security architecture.

Bottom line: Tiered ingestion isn’t just a cost play — it’s a data strategy. Send everything to the lake, build scheduled detections and hunts to cover it, and let agents handle the deep correlation.