The Sentinel data lake cuts log costs if you pick the right tables

If you run Microsoft Sentinel in a larger environment, you've probably hit this already. Log Analytics workspaces get expensive quickly once you ingest high-volume sources like firewalls or proxies. Now that the Sentinel data lake is generally available, there's finally a practical way to keep cheap long-term storage apart from the analytics tier while still being able to search it. Cold, rarely used data sits in the lake at low cost, and you can run KQL queries against it whenever you need to, with some limits on performance and integration. Organisations with compliance, forensic or audit requirements have been waiting a long time for this.

The Sentinel data lake separates cheap storage from the analytics tier

The idea is straightforward. The Sentinel data lake is a separate, low-cost storage tier that sits alongside the analytics tier you already know. Logs you actively use stay in analytics, where they feed fast SIEM detections and hunting. The rest, meaning data you rarely look at but have to keep (firewall, proxy or RADIUS logs, or authentication "noise" from Entra ID), goes to the data lake. When logs have to be kept for months or years, that saves a lot of money, and you don't lose their forensic value.

In many tenants I work with, the analytics tier is flooded with huge network or sign-in logs that contribute very little to detection. The data lake lets you split operational security from compliance storage and get your budget back under control. Microsoft's documentation explains the architecture and the query workflow well.

Onboarding requires a workspace connected to the Defender portal

Your Sentinel workspace has to be connected to the Microsoft Defender portal before you can use the data lake. Most tenants created in 2025 or later have this by default, but check it under Sentinel setup anyway. You'll do the actual work in the Defender portal under "Microsoft Sentinel → Data lake exploration → KQL queries". Older workspaces that aren't connected may need a migration or a new target workspace.

Which logs land in the data lake is a per-table decision. These are the candidates I come across most often:

• Firewall and proxy logs
• VPN and RADIUS sign-in events
• Authentication noise (e.g. success events from Entra ID)
• IoT/OT telemetry with little security value
• Bulk diagnostic or telemetry streams kept just for audit

This is about more than retention. For each table you set from when and for how long its data goes to the data lake rather than the analytics tier. You configure that in the per-table retention settings in Sentinel setup.

KQL queries and scheduled jobs make lake data usable

What really makes the lake worthwhile is that you can hit your cold data directly with KQL, although there are a few catches. In the Defender portal, under "Microsoft Sentinel → Data lake exploration → KQL queries", there's a KQL query editor for lake tables. Standard KQL works, but only against tables assigned to the data lake.

The feature I find most useful is scheduled KQL jobs. They run predefined searches against the lake (suspicious proxy usage, for example) and then "promote" just the relevant results back to the analytics tier. That way you can spot past threats or patterns without paying analytics prices to store all the raw data.

Below is a simple KQL example to run in the Defender portal ("Microsoft Sentinel → Data lake exploration → KQL queries"). You'll need Sentinel workspace access and lake table permissions.

// Find failed VPN logins in the data lake for the last 180 days
VPNConnectionLogs
| where Result == "Failure"
| summarize Count = count() by User, bin(Timestamp, 1d)
| sort by Count desc

Pro tip: Keep your scheduled jobs as selective as you can. The less data you promote to the analytics tier, the more you save over time.

This diagram shows the query workflow at a glance:

flowchart TD
    User["Defender portal"] --> Query["KQL query (data lake)"]
    Query --> Lake["Data lake (cheap)"]
    Lake --> Job["Scheduled KQL job"]
    Job --> Analytics["Analytics tier (costly)"]

Figure: KQL query flow in the Sentinel data lake. Data only moves to analytics when it's actually needed.

Lower costs come with real limitations

For high-volume logs that you rarely open, Sentinel data lake pricing works out well. You get cheap storage and still have KQL access. It doesn't fully replace analytics-tier data, though. Queries are slower, and some advanced features, such as near real-time alerts or complex analytics rules, only work on data in the analytics tier. Data lake logs also don't integrate natively with every Log Analytics feature, security playbook or automation, so expect to rework some of those workflows. And since promoting data back to analytics costs money, your scheduled jobs need tight filters.

In practice, a lot of admins are still unsure which tables should go to the lake. My rule of thumb: if you don't need a log for SIEM rules or live dashboards, and it only matters for compliance or the odd investigation, put it in the data lake. Decide on this split early and you'll get noticeable savings and tidier governance. The KQL in data lake overview and your own queries in the Defender portal are good places to start.

Splitting logs early pays off in my experience

If you deal with large log sources, the Sentinel data lake is a big step forward. You can keep compliance storage and operational analytics apart instead of dumping everything into the expensive analytics tier. Plan your scheduled KQL jobs and promotion flows early. The most efficient setups I've seen were in tenants that split high-value signals from "just-in-case" logs from day one. For more on Sentinel and log retention, my posts on Defender XDR and audit log retention go into more practical detail.