TTechclick ⚡ XP 0% All lessons
Microsoft · Cloud SIEM · ArchitectureInteractive · L1 / L2 / L3

Microsoft Sentinel Architecture — Workspace, Connectors & the Defender Portal

Microsoft Sentinel is a cloud-native SIEM and SOAR that runs on top of a single Log Analytics workspace. This lesson maps the whole machine: how connectors and the AMA agent pour logs into tables, how the analytics and data-lake tiers store them, how you design workspaces and RBAC, what you actually pay for, and why in 2026 it all lives inside the unified Microsoft Defender portal.

📅 2026-06-19 · ⏱ 17 min · 5 infographics · live ingestion demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

A clear, interactive guide to Microsoft Sentinel architecture (2026): a cloud-native SIEM + SOAR built on a Log Analytics workspace (Azure Monitor), how data connectors and the AMA agent feed tables through the ingestion pipeline, analytics vs data-lake tiers and retention, single vs multi-workspace design with RBAC, pay-as-you-go vs commitment pricing, and how it now all lives in the unified Microsoft Defender portal.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

What it is

Cloud SIEM + SOAR on a Log Analytics workspace.

2

Connectors & pipeline

Microsoft, CEF/Syslog, AMA, codeless — into tables.

3

Tiers & workspaces

Analytics vs lake, retention, single vs multi, RBAC.

4

Pricing & Defender

Pay-as-you-go vs commitment, the 2026 portal.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. What does Microsoft Sentinel actually store its data in?

Answered in What it is.

2. How do most on-prem firewalls and Linux boxes get logs into Sentinel?

Answered in Connectors & pipeline.

3. In 2026, where do you manage Microsoft Sentinel day to day?

Answered in Pricing & Defender.

Most engineers think…

Most people picture a SIEM as 'a server you install that swallows logs and shows alerts'. For Sentinel that mental model is wrong and it shows in interviews.

Microsoft Sentinel is a cloud-native SIEM + SOAR layered on top of a Log Analytics workspace — the same Azure Monitor store that holds your other Azure logs. Sentinel adds the security brain (detections, hunting, incidents, automation) on top of that workspace. Once you see it as workspace-centric — connectors fill tables, tiers decide cost and retention, RBAC and workspace design decide who sees what — every architecture and pricing question becomes easy. And in 2026 you drive the whole thing from the unified Microsoft Defender portal, not the Azure portal.

① What Microsoft Sentinel actually is — a SIEM + SOAR on a workspace

The single most important idea: Microsoft Sentinel is not a box and not a separate database. It is a cloud-native SIEM and SOAR that runs on top of a Log Analytics workspace, which is part of Azure Monitor. You enable Sentinel onto a workspace; that workspace is where every log actually lives.

So the architecture is layered. The workspace is the storage and query engine (tables of logs you query with KQL). Sentinel is the security layer on top — detections, hunting, incidents, UEBA and automation. Because the store is shared Azure Monitor plumbing, Sentinel inherits its connectors, its tables, its retention controls and its pricing model. Get the workspace right and the rest follows.

Figure 1 — The Sentinel stack — layers, not a box
Sentinel is a security layer on top of a Log Analytics workspace, which sits on Azure Monitor.The Sentinel stack — layers, not a boxDefender portalUnified SecOps UI — incidents, hunting (2026)Microsoft SentinelSIEM + SOAR — detections, UEBA, playbooksLog Analytics workspaceTables, KQL, retention — the data storeAzure MonitorIngestion pipeline, connectors, AMA agent
Sentinel is a security layer on top of a Log Analytics workspace, which sits on Azure Monitor.
Quick check · Q1 of 10 · Understand

Microsoft Sentinel is best described as…

Correct: a. Sentinel is a cloud-native SIEM + SOAR layered on a Log Analytics workspace (Azure Monitor). The workspace stores the logs as tables; Sentinel adds detection, hunting, incidents and automation on top.
👉 So far: Microsoft Sentinel = a cloud-native SIEM + SOAR built on a Log Analytics workspace (Azure Monitor). The workspace stores logs as tables; Sentinel adds detection, hunting, incidents and automation on top.

② Data connectors and the ingestion pipeline — filling the tables

Data gets into the workspace through data connectors, and they come in a few flavours. Microsoft service-to-service connectors (Entra ID, Microsoft 365, Defender XDR, Azure activity) wire up natively inside a tenant. For firewalls, proxies and Linux boxes you use CEF/Syslog via the Azure Monitor Agent (AMA) — the agent sits on a log forwarder and a Data Collection Rule (DCR) filters what ships. For SaaS APIs there is the Codeless Connector Framework (CCF), a fully-SaaS config-file connector with no servers to run.

Where the data lands

Each source maps to a table in the workspace. Plain Syslog lands in the Syslog table; CEF lands in CommonSecurityLog; codeless connectors usually create their own _CL custom tables. The interview line: connectors fill tables, KQL reads tables. Choosing the right connector is mostly about where the source lives — Microsoft cloud, on-prem appliance, or third-party SaaS.

Figure 2 — The ingestion pipeline — source to incident
Every source follows the same path: a connector ships logs through the AMA agent or an API into a workspace table, where Sentinel detects and raises incidents.The ingestion pipeline — source to incidentSourcefirewall / SaaS /cloudConnectorMicrosoft / CEF / CCFAgent / APIAMA + DCR or APITableSyslog /CommonSecurityLogDetectrules + incidents
Every source follows the same path: a connector ships logs through the AMA agent or an API into a workspace table, where Sentinel detects and raises incidents.
Figure 3 — Connectors all feed one workspace
Different connector types pour data into the same Log Analytics workspace, where every table is queryable with KQL.Connectors all feed one workspaceWorkspaceLog AnalyticsMicrosoft S2SCEF / Syslog (AMA)Codeless (CCF)Logs Ingestion APIDefender XDRThreat intel
Different connector types pour data into the same Log Analytics workspace, where every table is queryable with KQL.
🗄️
Log Analytics workspace
tap to flip

The Azure Monitor data store Sentinel runs on — holds every log as a table you query with KQL. Get this right and the rest follows.

🔌
Data connector
tap to flip

How data enters: Microsoft service-to-service, CEF/Syslog via AMA, or Codeless Connector Framework for SaaS APIs. Each maps a source to a table.

📡
Azure Monitor Agent (AMA)
tap to flip

The agent on a log forwarder that collects Syslog/CEF, filters it with a Data Collection Rule (DCR), and ships it into the workspace.

🛡️
Defender portal (2026)
tap to flip

The unified SecOps console where Sentinel now lives — incidents correlated with Defender XDR. The Azure portal retires after 31 Mar 2027.

Match the connector to where the source lives

In an interview, sort connectors by source: Microsoft cloud → service-to-service; on-prem firewall/Linux → CEF/Syslog via AMA with a DCR; third-party SaaS API → Codeless Connector Framework. Naming the right path for each source shows you understand the pipeline, not just the buzzwords.

▶ Watch a firewall log travel from the wire to an incident

How one Syslog/CEF event is ingested end-to-end. Press Play for the healthy path, then Break it to see the classic failure.

① EmitAn on-prem firewall emits a CEF event and forwards it to a Linux log forwarder running the Azure Monitor Agent.
② Filter (DCR)The Data Collection Rule on the AMA agent filters the message and keeps the fields you actually need.
③ Ingest to tableThe agent ships the event into the workspace, where it lands in the CommonSecurityLog table.
④ Detect + incidentA scheduled analytics rule queries the table with KQL, matches the pattern and raises an incident in the Defender portal.
Press Play to step through the healthy ingestion path. Then press Break it.
Quick check · Q2 of 10 · Apply

You must bring logs from an on-prem Linux firewall into Sentinel. Which connector path fits?

Correct: c. On-prem appliances that emit Syslog/CEF use the Azure Monitor Agent on a log forwarder, driven by a Data Collection Rule. Service-to-service connectors are for Microsoft cloud sources inside the tenant.
👉 So far: Connectors fill tables: Microsoft service-to-service, CEF/Syslog via the AMA agent (with a DCR), and the Codeless Connector Framework for SaaS APIs. Syslog → Syslog table, CEF → CommonSecurityLog, codeless → _CL tables.

③ Tiers, retention and workspace design — cost, access and scale

Not every log deserves premium storage. The analytics tier keeps data in fast, fully-queryable interactive retention for 90 days by default (extensible up to two years) — use it for primary detection data. The cheaper data-lake tier (and the older Basic/Auxiliary table plans) holds high-volume, low-value logs like NetFlow or proxy logs for long-term retention, where you pay mostly per GB scanned. Sentinel gives the first 90 days of retention free; beyond that you pay.

One workspace or many?

A single workspace is simplest and is enough for many orgs. You go multi-workspace for data residency, separate billing, or tenant isolation. Access is controlled with Azure RBAC (Sentinel Reader, Responder, Contributor), ideally scoped at the resource-group level. For multiple tenants — an MSSP or a group of subsidiaries — you use Azure Lighthouse (and the Defender portal's multitenant view) so one SOC can query and manage many tenants without copying data into one place.

Figure 4 — Analytics tier vs data-lake tier
Choose the tier per table: fast and pricey for detection data, cheap and deep for high-volume retention.Analytics tier vs data-lake tierAnalytics tierPrimary security dataFast interactive query, no90 days free, up to 2 yearsPowers analytics rulesData-lake tierHigh-volume, low-value logsLow storage cost, pay per GBLong-term retention / complianceNetFlow, proxy, firewall noise
Choose the tier per table: fast and pricey for detection data, cheap and deep for high-volume retention.
Dumping everything into the analytics tier

The classic cost blow-up is sending every noisy, low-value log into the premium analytics tier. That data is billed at the highest rate but rarely queried. Tier per table: analytics for detection data, data-lake (or Basic/Auxiliary) for high-volume retention. Cost is driven by ingestion volume and how long you keep it.

Quick check · Q3 of 10 · Analyze

You have huge volumes of low-value proxy logs you must keep for a year but rarely query. Best home?

Correct: b. High-volume, low-value logs you keep for retention but rarely query belong in the data-lake tier — cheap storage, pay mainly per GB scanned. The analytics tier is for primary detection data you query constantly.
👉 So far: Tier per table — analytics (fast, 90 days free, up to 2 years) for detection data, data-lake for cheap long retention. Design one workspace or many; control access with Azure RBAC; span tenants with Azure Lighthouse.

④ Pricing and the 2026 Defender portal — what you pay and where you work

Cost is driven by how much data you ingest and how long you keep it. Pay-as-you-go bills per GB ingested — simple, and right for small or spiky volumes. Commitment tiers (starting at 100 GB/day) give a discounted flat rate for a committed daily volume; anything above bills at that discounted rate. Newer workspaces use the simplified pricing tier that combines the Log Analytics ingestion cost and the Sentinel analysis cost into one meter.

The big 2026 change

Microsoft Sentinel now lives in the unified Microsoft Defender portal (unified SecOps), where Sentinel incidents are correlated with Defender XDR in one queue. It is generally available there even without an E5 licence or Defender XDR. The old Azure portal experience is being retired — after 31 March 2027 remaining customers are redirected to Defender. So in 2026 the right answer is: design the workspace, but drive Sentinel from the Defender portal.

Figure 5 — Pay-as-you-go vs commitment tier
Two ways to pay for the analytics tier — pick by how predictable your daily volume is.Pay-as-you-go vs commitment tierPay-as-you-goBilled per GB ingestedNo commitmentBest for small or spiky volumeDefault modelCommitment tierFlat daily rate, discountedStarts at 100 GB/dayOverage at the discounted rateBest for steady, high volume
Two ways to pay for the analytics tier — pick by how predictable your daily volume is.

Priya, a SOC lead at a Pune fintech, faces this

The monthly Sentinel bill suddenly doubles after the team onboards verbose firewall and proxy logs into the analytics tier.

Likely cause

Every new high-volume source was ingested into the premium analytics tier on pay-as-you-go, so noisy logs are billed at the most expensive rate.

Diagnosis

Open Data management ▸ Tables and sort by volume — the proxy and firewall tables dominate ingestion, yet analysts almost never query them interactively.

Defender portal ▸ Microsoft Sentinel ▸ Data management ▸ Tables + Settings ▸ Pricing
Fix

Switch the noisy, low-value tables to the data-lake tier for cheap long retention, keep detection-critical tables in analytics, and move steady volume onto a commitment tier.

Verify

Re-check the cost view next cycle: ingestion cost drops sharply, detections still fire on the analytics-tier tables, and the year-long retention requirement is met cheaply.

Confirm you are in the right portal

Don't assume screenshots from old guides still apply. In 2026 Sentinel is generally available in the unified Microsoft Defender portal, and the Azure portal experience is retiring after 31 March 2027. Verify you are working in the Defender portal so incidents correlate with Defender XDR in one queue.

Quick check · Q4 of 10 · Evaluate

Your daily ingestion is steady at ~150 GB/day. Which pricing choice is usually smartest?

Correct: d. Steady, high volume is the textbook case for a commitment tier: you get a discounted flat rate for the committed volume and overage bills at that same discounted rate. Pay-as-you-go suits small or spiky volumes.
👉 So far: Pay by ingestion + retention: pay-as-you-go for small/spiky, commitment tier (from 100 GB/day) for steady volume. In 2026 Sentinel lives in the unified Defender portal; the Azure portal retires after 31 March 2027.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

Microsoft Sentinel stores its log data in…

Correct: a. Sentinel runs on a Log Analytics workspace, which is part of Azure Monitor. The workspace holds every log as a table; Sentinel is the security layer on top.
Q6 · Understand

Which statement about Sentinel data connectors is correct?

Correct: c. Connectors map each source to a table in the workspace. Microsoft service-to-service connectors are agentless; CEF/Syslog uses the AMA agent; the Codeless Connector Framework is fully SaaS for third-party APIs.
Q7 · Apply

Which table does CEF data from the AMA agent land in?

Correct: b. CEF messages land in CommonSecurityLog, while plain Syslog lands in the Syslog table. Codeless connectors usually create their own _CL custom tables.
Q8 · Analyze

Why move high-volume, rarely-queried logs to the data-lake tier?

Correct: a. The data-lake tier is optimised for high-volume, low-value data kept long-term: low storage cost and you pay per GB scanned. The premium analytics tier is for detection data you query constantly.
Q9 · Evaluate

An MSSP must run one SOC across many customer Entra tenants without copying all data into one workspace. Best approach?

Correct: d. Azure Lighthouse lets a managing tenant query and manage Sentinel workspaces across customer tenants while data ownership, residency and isolation stay with each tenant. The Defender portal adds a unified multitenant view.
Q10 · Evaluate

In 2026, where should you primarily manage Microsoft Sentinel?

Correct: c. Sentinel is generally available in the unified Microsoft Defender portal, where its incidents correlate with Defender XDR. The Azure portal experience is retiring after 31 March 2027, after which customers are redirected to Defender.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why is Microsoft Sentinel called 'workspace-centric' rather than 'a SIEM appliance'? Then compare with the expert version.

Expert version: Because Sentinel doesn't store anything itself — it runs on a Log Analytics workspace (Azure Monitor), and that workspace is where every log lives as a table. Connectors fill those tables, the tier you choose per table decides cost and retention, RBAC and workspace design decide who sees what, and KQL plus analytics rules read the tables to raise incidents. There is no inline 'SIEM box': there is a workspace plus a security layer, which is exactly why pricing is about ingestion and retention, why you scale by designing workspaces, and why in 2026 you drive it all from the unified Defender portal.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Log Analytics workspace
The Azure Monitor data store Sentinel runs on; holds every log as a table you query with KQL. Sentinel is enabled onto a workspace.
SIEM + SOAR
Security Information and Event Management (collect, correlate, alert) plus Security Orchestration, Automation and Response (automated playbooks). Sentinel is both.
Data connector
How data enters Sentinel: Microsoft service-to-service, CEF/Syslog via AMA, Codeless Connector Framework, or API/Functions/Logic Apps. Each maps a source to a table.
Azure Monitor Agent (AMA)
Agent on a log forwarder that collects Syslog/CEF, filters via a Data Collection Rule (DCR), and ships events into the workspace.
Codeless Connector Framework (CCF)
A fully-SaaS, config-file way to build connectors for third-party APIs with no servers to install; includes health monitoring.
Analytics tier
Premium storage for primary security data — fast interactive query, 90 days free retention by default, extensible to two years; powers analytics rules.
Data-lake tier
Low-cost storage for high-volume, low-value logs kept long-term; you pay mostly per GB scanned, ideal for retention and compliance.
Commitment tier
A pricing model starting at 100 GB/day that gives a discounted flat rate for a committed daily ingestion volume, with overage at the same rate.
Azure Lighthouse
Lets a managing tenant query and manage Sentinel workspaces across many customer tenants at scale, keeping each tenant's data and ownership separate.
Unified Defender portal
The Microsoft Defender portal (unified SecOps) where Sentinel is managed in 2026; correlates Sentinel and Defender XDR incidents. Azure portal retires after 31 Mar 2027.

📚 Sources

  1. Microsoft Learn — What is Microsoft Sentinel? overview & the Defender portal. learn.microsoft.com/azure/sentinel/overview
  2. Microsoft Learn — Connect data sources: agent-based, CEF/Syslog via AMA, and Codeless Connector Framework. learn.microsoft.com/azure/sentinel/connect-data-sources
  3. Microsoft Learn — Log retention tiers in Microsoft Sentinel (analytics tier vs data-lake tier). learn.microsoft.com/azure/sentinel/log-plans
  4. Microsoft Learn — Plan costs and understand Microsoft Sentinel pricing and billing (pay-as-you-go & commitment tiers). learn.microsoft.com/azure/sentinel/billing
  5. Microsoft Learn — Extend Microsoft Sentinel across workspaces and tenants (Azure Lighthouse, multi-tenant). learn.microsoft.com/azure/sentinel/extend-sentinel-across-workspaces-tenants
  6. Microsoft Learn — Plan / deploy for unified security operations & Azure portal retirement timeline (after 31 Mar 2027). learn.microsoft.com/unified-secops/overview-plan

What's next?

Got the architecture? Next, learn KQL and analytics rules — the query language and scheduled detections that actually turn those workspace tables into alerts and incidents, plus SOAR playbooks that automate the response.