# Microsoft Sentinel Architecture — Workspace, Connectors & the Defender Portal

Source: https://ai.techclick.in/blog_microsoft_sentinel_architecture
Markdown: https://ai.techclick.in/blog_microsoft_sentinel_architecture.md
Publisher: Techclick Infosec Pvt Ltd

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.

Microsoft Sentinel Architecture — Workspace, Connectors &amp;amp; the Defender Portal student learning map
                     A visual study map for Microsoft Sentinel Architecture — Workspace, Connectors &amp;amp; the Defender Portal showing learning path, evidence, traps, and practice sequence.

                     TECHCLICK STUDY MAP
                     Microsoft Sentinel Architecture — Workspace,...
                     Microsoft · learn the flow, prove with evidence, avoid unsafe shortcuts

   1. Start
   🎯 By the end you will be able to

   2. Understand
   Pick where you want to start

   3. Prove
   ① What Microsoft Sentinel actually...

   4. Practice
   ② Data connectors and the...

                     How to use this page
                     First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself.
                     Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456

             Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail.

             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 box Defender portal Unified SecOps UI — incidents, hunting (2026) Microsoft Sentinel SIEM + SOAR — detections, UEBA, playbooks Log Analytics workspace Tables, KQL, retention — the data store Azure Monitor Ingestion 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… a) A cloud-native SIEM + SOAR built on a Log Analytics workspace b) A standalone SIEM appliance you install on-prem c) Just a dashboard for Azure logs d) A firewall with logging 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 incident Source firewall / SaaS / cloud Connector Microsoft / CEF / CCF Agent / API AMA + DCR or API Table Syslog / CommonSecurityLog Detect rules + 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 workspace Workspace Log Analytics Microsoft S2S CEF / Syslog (AMA) Codeless (CCF) Logs Ingestion API Defender XDR Threat 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. ① Emit An 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 table The agent ships the event into the workspace, where it lands in the CommonSecurityLog table. ▼ ④ Detect + incident A 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 . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q2 of 10 · Apply You must bring logs from an on-prem Linux firewall into Sentinel. Which connector path fits? a) A Microsoft service-to-service connector b) Email the logs to support c) CEF/Syslog via the Azure Monitor Agent (AMA) d) It cannot be done 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 tier Analytics tier Primary security data Fast interactive query, no 90 days free, up to 2 years Powers analytics rules Data-lake tier High-volume, low-value logs Low storage cost, pay per GB Long-term retention / compliance NetFlow, 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? a) The analytics tier b) The data-lake tier c) Delete them d) Email them to an archive 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 tier Pay-as-you-go Billed per GB ingested No commitment Best for small or spiky volume Default model Commitment tier Flat daily rate, discounted Starts at 100 GB/day Overage at the discounted rate Best 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? a) Pay-as-you-go forever b) Turn off connectors c) Stop ingesting logs d) A commitment tier (e.g. 100 GB/day) for the discount 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. What is Microsoft Sentinel, in one architecture sentence? What kinds of data connectors exist and when do I use each? What happens in the ingestion pipeline and where does data land? What is the difference between the analytics tier and the data-lake tier? Single workspace or multiple, and how do I handle many tenants? How is Sentinel priced, and what changed in 2026? 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… a) A Log Analytics workspace (Azure Monitor) b) Its own proprietary database c) A local SQL server you manage d) An on-prem appliance 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? a) All connectors require installing an agent b) There is only one connector type c) Connectors map sources to tables; types include Microsoft S2S, CEF/Syslog via AMA, and codeless (CCF) d) Connectors only work for Microsoft 365 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? a) The Syslog table b) The CommonSecurityLog table c) A random table d) It is not stored 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? a) Cheaper long-term storage; you pay mostly per GB scanned, not for premium interactive query b) It makes them query faster c) It deletes them d) It is required for all logs 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? a) Forward every customer's logs into a single shared workspace b) Give every analyst the customer's admin password c) It is impossible d) Use Azure Lighthouse (and the Defender portal multitenant view) to manage per-tenant workspaces centrally 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? a) The legacy Azure portal only b) A third-party console c) The unified Microsoft Defender portal d) PowerShell only 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. Submit all answers Try again 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. Compare with expert answer 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. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Microsoft Sentinel at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 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 Microsoft Learn — What is Microsoft Sentinel? overview & the Defender portal . learn.microsoft.com/azure/sentinel/overview
- Microsoft Learn — Connect data sources: agent-based, CEF/Syslog via AMA, and Codeless Connector Framework . learn.microsoft.com/azure/sentinel/connect-data-sources
- Microsoft Learn — Log retention tiers in Microsoft Sentinel (analytics tier vs data-lake tier) . learn.microsoft.com/azure/sentinel/log-plans
- Microsoft Learn — Plan costs and understand Microsoft Sentinel pricing and billing (pay-as-you-go & commitment tiers) . learn.microsoft.com/azure/sentinel/billing
- Microsoft Learn — Extend Microsoft Sentinel across workspaces and tenants (Azure Lighthouse, multi-tenant) . learn.microsoft.com/azure/sentinel/extend-sentinel-across-workspaces-tenants
- 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.

                 Next · All interview lessons →
                 Practice on exam.techclick.in →

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt
