Tiered SIEM with Microsoft Sentinel
The design question in Sentinel is not which connectors you enable but which tier each table lands in. Analytics is expensive and immediately queryable, the data lake is cheap and slow, and that choice decides which detections you can still write.
Architecture
Click a step for details
Sources
One incident on a Data & AI platform touches four products, and four consoles give you four half stories.
The data lake is provisioned in the same region as your primary workspace. Defender XDR keeps hunting data in its own tier for thirty days and does not push it into analytics or the lake on its own.
Overview
A SIEM is usually discussed as a collection of connectors. In Sentinel that is the least interesting decision. The architectural question is which tier each table lands in, because your cost, your detections and your retention all hang off it.
Sentinel has two tiers. The analytics tier is the hot tier: this is where analytics rules, hunting, workbooks and every other Sentinel feature work. The default retention is 30 days, extendable to two years at a prorated long-term retention charge; tables from Sentinel solutions can be extended to 90 days for free. The data lake tier is the cold tier: open Parquet, a single copy of the data, storage separated from compute, minimal ingestion cost and retention up to twelve years. Queries there are priced separately and are not optimized for real-time analysis.
What that difference means in practice: a table in the data lake can answer an audit and carry a forensic investigation, but no analytics rule can run on it. A table in the wrong tier is therefore not a pricing question but a detection you can no longer write.
Since Sentinel and Defender XDR were unified in the Defender portal, a Sentinel workspace is a Log Analytics workspace with Sentinel enabled, and the portal connects one primary workspace plus multiple secondary ones. XDR data also has its own default tier: Defender XDR keeps hunting data for 30 days and does not push it into analytics or into the data lake on its own.
At a glance
- Best for
- Correlation across security signals
- Complexity
- High
- Scalability
- ★★★★★
- Cost
- Variable
- Workloads
- Analytics tier · Data lake tier · Analytics rules · Playbooks
When to use this
- Signals from more than one product that you have to line up. that is the core reason. One incident on a Data & AI platform touches Entra, Defender, Purview and the platform itself, and four consoles give you four half stories.
- A retention obligation you cannot afford in the hot tier. the data lake makes keeping years of data affordable without parking logs outside your SIEM where you will never find them again.
- Automation on incidents. a SOC that performs the same three actions every evening performs them better in a playbook than in a runbook on a wiki.
- Multiple tenants or customers. the portal connects a primary workspace to multiple secondary ones, so you keep visibility across boundaries without merging the data.
- One Azure subscription with only Defender alerts. you are buying a correlation layer without correlating anything. Look in Defender for Cloud itself.
- As a general-purpose log archive. Sentinel is not a data platform. Application logs nobody uses as a security signal belong in your own lakehouse, where they sit cheaper and query better.
- As a replacement for the posture work. Sentinel tells you what happened, not that your storage account is public. See [Posture and workload protection with Defender for Cloud](/patterns/defender-for-cloud-posture).
- Without people who respond to the incidents. a SIEM without a rota produces a queue, and a queue nobody empties is more expensive than no SIEM.
Key Design Decisions
Analytics or data lake
Why decide per table? The analytics tier is hot: analytics rules, hunting and workbooks work there. The data lake tier is cold: open Parquet, up to twelve years, billed separately per query. A table in the wrong tier is not a pricing question but a detection you can no longer write.
One primary workspace
Why not split? The Defender portal connects one primary workspace plus multiple secondary ones. Every split costs you cross-boundary queries. Split for sovereignty, for an MSSP or for a real organizational boundary, not for an authorization question.
RBAC instead of a second workspace
Why inside one workspace? Resource-context RBAC and table-level RBAC give you the same separation without every hunting query from that moment on having to span two workspaces.
The XDR default tier
Why check this explicitly? Defender XDR keeps hunting data in its own tier for thirty days and does not push it into analytics or the lake on its own. Assume everything visible in the portal is also queryable in Sentinel and you discover the difference during an investigation.
Trade-offs
One workspace/several
one workspace is the recommendation, because every split costs you cross-boundary queries. The reasons to split anyway are limited and recognizable: granular access to parts of the data, sovereignty and regulation tied to a region, an MSSP with multiple customers, and wanting to separate cost. The first reason is the most commonly used and usually the weakest, because resource-context RBAC and table-level RBAC solve it inside a single workspace.
Analytics/data lake per table
this is a decision you take per table, not per connector. Do not ask "what does this table cost" but "which detection do I want to be able to write on it". Everything that feeds an analytics rule belongs hot; everything you only read back afterwards belongs in the lake.
Ingest everything/ingest what you detect on
completeness feels safe and is the most expensive form of postponement. A source without a detection and without an investigative question is storage with a SIEM price tag.
Retention/reusability
twelve years in the lake is cheap to keep and not free to read; queries on that tier are billed separately. Work out what a recurring annual investigation costs before you set retention to the maximum.
The data lake is more than cheap storage
The data lake is easily read as an archive, and that sells it short. It stores in open Parquet files, keeps a single copy of the data and separates storage from compute, which lets multiple analytics engines run on it: KQL for exploration alongside notebooks for investigation that goes beyond a query.
For a Data & AI platform that is exactly the bridge that is usually missing. "Is this export pattern normal for this user" is not an alerting question but an analysis question over months of behaviour, and you ask that in the tier where months of behaviour are affordable.
Two things to know up front. The lake is provisioned in the same region as your primary Sentinel workspace, so you make that region choice once and with your sovereignty requirements in hand. And auxiliary log tables become part of the lake as soon as you enable it; after that they are no longer reachable from Advanced hunting in the Defender portal, but through data lake exploration queries.
Common pitfalls
The first pitfall is letting the invoice decide the tiering. That almost always happens after the fact, when somebody has to bring costs down and moves the largest tables to the lake. The largest tables are rarely the least valuable though; network logs and sign-in data are large because a lot happens. You only notice months later, when a detection has to be written on a table that is no longer hot.
The second is enabling connectors without writing detections. A connector is an afternoon of work and a detection is a conversation with the people who run the workload, so the first happens and the second is left. The result is an expensive amount of data you know nothing about. Only take a source into production once at least one rule runs on it that somebody can explain.
The third is creating a second workspace to solve a permissions problem. It works, and it is almost never necessary: resource-context RBAC and table-level RBAC give you the same separation inside one workspace, without every hunting query from that moment on having to span two workspaces. Split for sovereignty or for a real organizational boundary, not for an authorization question.
The fourth is assuming XDR data is already in there. Defender XDR keeps its hunting data in its own tier for 30 days by default and does not forward it to analytics or to the lake on its own. Assume that everything visible in the Defender portal is also queryable in Sentinel and you will discover the difference during an investigation.
Good versus bad
- Every rule has its data hot
- History stays affordable
- Large usually means a lot is happening
- You notice it months later
Best practices
Tier per detection
Do not ask what a table costs but which detection you want to be able to write on it. Everything that feeds an analytics rule belongs hot, everything you only read back afterwards belongs in the lake.
A rule before production
Only take a source into production once at least one rule runs on it that somebody can explain. A connector is an afternoon of work, a detection is a conversation with the team running the workload.
Region at provisioning
The data lake is provisioned in the same region as your primary workspace. You make that choice once, with your sovereignty requirements in hand rather than after the fact.
Know what an investigation costs
Keeping twelve years is cheap, reading it back is not: queries on the lake are billed separately. Work out what a recurring annual investigation costs before you set retention to the maximum.
The data lake is not an archive. Open Parquet with storage separated from compute lets KQL and notebooks run over the same data, and that is exactly the tier where 'is this export pattern normal for this user' gets answered.