Sentinel analytics tier vs data lake tier
Verdict: The analytics tier runs real-time alerting, hunting and incidents. The data lake tier holds a single mirrored copy for cheap long-term retention. Promote lake rows back with a KQL job; one output table per job.
| Criterion | Analytics tier | Data lake tier |
|---|---|---|
| Purpose | Hunting, alerting, incident management | Cost-effective long-term retention and large-scale analysis |
| Retention | Interactive retention settings | Up to twelve years as a single mirrored copy |
| Analytics rules run against | Yes | No; rules cannot query the lake tier directly |
| Python and machine learning | No | Jupyter notebooks with ML libraries |
| Prerequisite to enable | Standard workspace | Workspace onboarded to the Defender portal |
| Move data between tiers | Destination of promotion | A one-time or scheduled KQL job promotes matching rows up |
Rules
- Keep hot data in the analytics tier for alerting and incidents, and mirror a single copy into the lake tier for up to twelve years of retention.
- Run Python or machine learning models on historical lake data with Jupyter notebooks in the data lake, not with analytics rules.
- Using the data lake requires the workspace to be onboarded to the Defender portal first.
- Promote a slice of lake-tier data into the analytics tier for ongoing alerting with a one-time or scheduled KQL job.
- Retrospective indicator sweeps over lake data, such as 90 days of CommonSecurityLog, use a KQL job that writes matching rows to a new analytics-tier table.
Traps
- Each KQL job writes to only one output table; splitting severity across two tables needs two separate jobs.
- An underused-table SOC optimisation finding is a cost and coverage recommendation, not a security incident to escalate; add a rule or change the plan.