Lesson 3 — Log Analytics Workspace Basics
Microsoft Sentinel does not store security data by magic.
Behind every Sentinel deployment is a Log Analytics workspace. This workspace is where logs are ingested, stored, queried and retained.
Before you connect data sources or build analytics rules, you need to understand the workspace that Sentinel depends on.
What you will learn
This lesson explains the workspace layer behind Sentinel so future connector, rule and hunting lessons make sense.
Learning objectives
After completing this lesson, you should understand the foundation that Sentinel is built on.
- Explain what a Log Analytics workspace is.
- Understand how Microsoft Sentinel uses a workspace.
- Recognise that data is stored in tables.
- Understand why retention and ingestion affect cost.
- Know why workspace design matters before connecting data sources.
The problem this solves
Sentinel needs somewhere to store security data. That data might come from Microsoft Defender XDR, Entra ID, Azure Activity, firewalls, servers, Syslog, threat intelligence feeds or custom applications.
The Log Analytics workspace is the central location where that data lands and becomes searchable with KQL.
What is a Log Analytics workspace?
A Log Analytics workspace is an Azure resource used to collect, store and query log data. Microsoft Sentinel is enabled on top of a Log Analytics workspace so security teams can use that data for detection, investigation, hunting, dashboards and automation.
If Sentinel is the SOC console, the Log Analytics workspace is the evidence room. Everything you want to investigate has to be collected, stored and queryable somewhere.
How Sentinel and Log Analytics fit together
Sentinel uses the workspace as its data store. When you connect data sources, those connectors send logs into tables inside the workspace. Sentinel then uses those tables for analytics rules, incidents, hunting queries and workbooks.
Tables are where the data appears
Data in a Log Analytics workspace is organised into tables. If you have already used KQL, this will feel familiar because every query usually starts with a table name.
- SigninLogs — Entra sign-in activity.
- AuditLogs — Entra audit activity.
- SecurityEvent — Windows security events.
- CommonSecurityLog — firewall and network security logs.
- AzureActivity — Azure subscription activity.
Not every table exists automatically
A beginner mistake is assuming every table will already be available. Tables only appear when the relevant connector, agent or data collection method sends data into the workspace.
If a query says a table does not exist, it may simply mean that the data source has not been connected yet.
Retention matters
Retention controls how long data remains available for search and investigation. Short retention may reduce storage cost, but it can limit your ability to investigate older incidents.
Long retention can be valuable for compliance, investigation history and threat hunting, but it needs to be planned carefully.
Ingestion affects cost
Sentinel cost planning starts with data ingestion. The more data you send into the workspace, the more important it becomes to understand volume, value and retention.
Not every log source is equally useful. Good Sentinel design means collecting the data that supports detection and investigation outcomes.
Workspace design questions
Before building Sentinel, you should be able to answer a few practical questions about the workspace.
| Question | Why it matters |
|---|---|
| Which Azure region should the workspace use? | Region affects data residency, latency and organisational design. |
| Which data sources will be connected? | Connectors determine which tables and security signals become available. |
| How long should data be retained? | Retention affects investigation depth, compliance needs and storage cost. |
| Who should have access? | Workspace permissions affect who can query, investigate and administer security data. |
| How much data is expected? | Ingestion volume drives cost planning and workspace design decisions. |
Real-world example
A SOC wants to investigate suspicious sign-ins, firewall traffic and Azure administrative changes. Sentinel can only correlate those signals if the relevant logs are being collected into the workspace.
No connector, no table. No table, no query. No query, no detection.
Common mistake
A common mistake is enabling Sentinel and immediately building rules without checking the workspace foundation.
If the wrong data is missing, noisy or retained for too short a time, even a well-written analytics rule may not produce useful incidents.
Agent Foskett investigation tip
Do not connect logs just because they are available. Connect logs because they help answer investigation questions. A good workspace supports useful detections, clear incidents and repeatable SOC workflows.
What this means for KQL
KQL only works against data that exists in the workspace. When you write a Sentinel hunting query, workbook query or analytics rule, you are querying tables inside Log Analytics.
Understanding the workspace makes your KQL more realistic because you know where the data comes from and why some tables may be missing.
Agent Foskett takeaway
Microsoft Sentinel gives analysts the SOC experience.
Log Analytics gives Sentinel the data foundation.
If the workspace is poorly designed, the Sentinel experience will suffer.
Related Agent Foskett learning
Microsoft Sentinel Academy progress
Log Analytics Workspace Basics for Microsoft Sentinel
Microsoft Sentinel uses a Log Analytics workspace to store security data in tables, support KQL queries, manage retention, collect data from connectors and provide a foundation for analytics rules, incidents, hunting and workbooks.
Microsoft Sentinel Lesson 3
This Agent Foskett Microsoft Sentinel Academy lesson explains Log Analytics workspaces, Sentinel tables, data ingestion, retention, cost planning, workspace design and KQL query foundations.
