How Sentinel is built: from the loading dock to the lake

A SIEM has one job: take everything your environment emits — sign-ins, endpoint events, mail flow, firewall traffic — and turn that raw noise into a small number of things a human should look at. Collect, correlate, alert, retain. Sentinel is Microsoft's cloud-native take on that job, and the reason it's worth understanding as architecture rather than as a product tour is that every meaningful decision you make with it is a trade between three things that pull against each other: coverage (keep everything), speed (query it instantly), and cost (don't go bankrupt). Almost everything below is a mechanism for spending on two of those without wasting the third.

01Standing it up

The order matters: two of these steps are effectively permanent, and the vendor quickstart front-loads the fun one and leaves the dangerous ones implied.

Sentinel isn't a resource you deploy so much as a capability you switch on over a Log Analytics workspace, which itself lives inside an active Azure subscription. That one fact drives most early mistakes, because a workspace is an Azure Monitor object first and a security object second — design it for the wrong master and you inherit its billing, retention, and access model for years.

The step people skip conceptually is 4 — the Defender attach. As of 2026 the management experience lives in the Microsoft Defender portal (unified SecOps), and the standalone Azure-portal experience for Sentinel is being retired around July 2026. So a complete build is now two onboardings: stand up the workspace, then connect it to Defender. Teach it workspace-first and you're anchoring on "a SIEM you later connect to Defender"; the reverse framing is coming, but for now the honest order is workspace, then attach.

02Getting data in — and shaping it before you pay

Connectors are the intake. The DCR is the sorting line — and it runs before the meter does.

Out-of-the-box data connectors pull from M365, Entra ID, Defender XDR, AWS/GCP, and syslog/CEF; anything bespoke comes in through the Logs Ingestion API or the Codeless Connector Platform. But the connector is just the dock. The piece that earns its keep is the Data Collection Rule (DCR) — a transformation and routing layer that runs at ingest, before the data is written and billed. It does two separable jobs: shape (drop noisy rows, trim or redact columns, enrich) and route (send the result to the right table — including a custom _CL table when the data doesn't fit a built-in schema).

// a DCR transform is just KQL over the incoming stream, aliased 'source'
source
| where not(EventID in (4662, 5145))          // drop known-noisy events at ingest
| project-away DebugBlob, RawXml               // trim columns you'll never hunt on
// what survives here is what you pay to ingest, retain, and mirror

03Where it lives: tables, tiers, and retention

Every source writes to tables. Each table carries a plan that sets its cost, its query power, and the ceiling on how long you can keep it — and you set those per table, not once for the whole workspace.

The nuance worth stating precisely, because a lot of write-ups blur it: the tier and the retention period are related but separate knobs. The tier sets the rules of the game — cost, which KQL you can run, how fast, and the retention floor and ceiling. Retention is a value you then dial: a workspace-wide default, overridden per table. High-value detection tables stay Analytics with long interactive retention; a huge low-value table you keep only for compliance goes Basic or Auxiliary and ages out cheaply into long-term storage. Same workspace, different economics per table.

Tier	Query power	Interactive retention	Cost profile	Put here
Analytics	Full KQL; drives rules, alerts, hunting; real-time	90 days with Sentinel; extend to 2 yrs	Premium ingest + priciest retention	Auth, EDR/XDR alerts, TI — anything a rule reads
Basic	Reduced KQL (no join/union/summarize); per-GB query scan	30 days	Low ingest; pay per query	High-volume logs you rarely touch but may need
Auxiliary	Single-table, unoptimized KQL; per-GB scan	30 days	Lowest ingest + cheap retention	Verbose / compliance / low-touch logs
Long-term (archive)	Not interactive — Search Jobs / Restore	—	Cheap storage; pay to restore or search	Same table, kept past the hot window
Data lake tier	KQL jobs + notebooks; per-GB scan; not real-time	—	Cheapest ingest & storage; 6:1 compression; to 12 yrs	High-volume forensic / compliance data; long lookbacks

Cost bands are ratios, not quotes — per-GB rates vary by region, commitment tier, and date. Check the current Microsoft Sentinel pricing page before you budget.

04The lake, and the one place it actually saves money

The data lake is real architecture, not just a cheaper shelf — but the "save bucks" pitch hides a sleight of hand worth calling out.

When data lands in the Analytics tier it is mirrored to the lake automatically and simultaneously — one write, appears in both, same table name, and the mirror is free: no second ingestion charge, and the lake copy costs nothing to store while it's inside the analytics retention window. That reads like a free lunch, so here's the correction that makes the whole model click: the mirror is not net-new spend, so it is not where savings come from. If everything flows Analytics-first and mirrors down, your bill is just the Analytics bill — the lake changed nothing.

So the lake doesn't make your data cheaper — it makes cold data cheaper. You save in exact proportion to how much you're willing to make invisible to live rules. And the trade is real: lake data supports full KQL through query jobs and Python through notebooks, but it can't back a real-time analytics rule, and every query meters by the gigabyte scanned. The uniform 6:1 compression is a big part of why "cheap cold storage for up to 12 years" is affordable rather than marketing — 600 GB of raw logs bills as roughly 100 GB stored.

05So where should your logs go?

Everything above collapses into one routing decision you make per source. Here's the heuristic I actually use.

• Drives a detection every few minutes? → Analytics. Authentication, EDR/XDR alerts, cloud audit, threat intel. You can't cool these — a rule can't read what isn't hot. Don't try to save here.
• High-volume, mostly forensic, occasionally needed? → lake-direct (or Basic/Auxiliary if you still want short interactive access). Firewall, proxy, DNS, NetFlow. This is where the bill actually drops.
• Kept only to satisfy an auditor? → lake / long-term. Cheap, compressed, 12-year ceiling — retention as an insurance policy, priced like one.
• Pure noise with no forensic value? → drop it at the DCR. The cheapest gigabyte is the one you never ingest — just remember that call is irreversible.

Notice the shape of it: your bill goes down in direct proportion to how much telemetry you're willing to make invisible to real-time detection. That's not a Sentinel quirk — it's the central tension of the whole platform, and it's why "just log everything to Analytics" and "put everything in the lake to save money" are both wrong. The skill is knowing, per source, which of coverage, speed, and cost you're spending and which one you're protecting.

06Where this series goes next

That's the foundation: the data is in, shaped, stored on the right rung, and priced deliberately. But a warehouse full of well-sorted data still doesn't catch anyone — nothing here has fired a single alert yet. That's the next post. The arc:

• Part 2 — How Sentinel detects. Analytics rules (templates vs. custom, and why a rule is its query plus its schedule, entities, and grouping), alerts, incidents, proactive hunting, and entity behaviour.
• Part 3 — How Sentinel responds. Automation rules vs. playbooks (Logic Apps), auto-enrichment, and the line between remediation you trust to run alone and remediation that needs a human on the trigger.
• Then the sources themselves — Defender XDR, Defender for Cloud Apps, and Email & Collaboration — each of which plugs into exactly the pipeline we just drew.