This chapter covers the critical distinction between Microsoft Sentinel's Basic Logs and Analytics Logs — two data storage tiers that directly impact cost, query performance, and security operations. On the SC-200 exam, approximately 10-15% of questions touch on log management and retention, with at least 2-3 questions specifically testing your understanding of these tiers. Mastering this topic is essential for designing cost-effective and operationally efficient Sentinel deployments, a key skill measured in the 'Manage a security operations environment' domain (objective 2.1).
Jump to a section
Imagine a large public library. The library has two types of shelving: the main bestseller shelves near the entrance, and the deep archives in the basement. The bestseller shelves are climate-controlled, well-lit, and organized for quick retrieval. Every book here is fully indexed, with detailed summaries and reviews posted on the side. This is where patrons go for immediate reading. The deep archives, on the other hand, are vast, dimly lit, and books are packed tightly on rolling shelves. There is no detailed index; only a simple log that a book exists and its general location. To retrieve a book from the archives, a librarian must manually search the area, which takes time and costs a small fee. Most patrons never use the archives, but for researchers who need historical data, it's invaluable. The library budgets carefully: each book on the bestseller shelf costs $1 per month in climate control and indexing, while each archived book costs only $0.10 per month. The library decides which books go where based on how often they are checked out. High-demand books stay on the bestseller shelf; old, rarely-requested books are moved to archives. This is exactly how Microsoft Sentinel's Log Analytics tiers work: Analytics Logs are the bestseller shelves — fully indexed for fast queries, higher cost. Basic Logs are the deep archives — no full-text indexing, lower cost, suitable for low-volume investigative queries.
What Are Basic Logs and Analytics Logs?
Microsoft Sentinel ingests data from various sources — Azure Activity, Office 365, AWS CloudTrail, custom logs, etc. — into a Log Analytics workspace. By default, all ingested data is stored as Analytics Logs, which are fully indexed and optimized for interactive queries using the Kusto Query Language (KQL). However, not all data needs to be queried frequently. For example, verbose debug logs from firewalls or raw NetFlow records are rarely accessed after initial investigation. Storing everything as Analytics Logs can be prohibitively expensive.
Basic Logs were introduced in mid-2023 (currently in preview) to address this. They are a lower-cost tier that sacrifices full-text indexing and some query capabilities. Basic Logs are intended for high-volume, low-value data that you want to keep for compliance or occasional forensic analysis but do not need to query in real-time.
How It Works Internally
When data is ingested into a Log Analytics workspace, the ingestion pipeline checks the table's plan (configured per table). Two plans exist: Analytics (default) and Basic. The plan determines how the data is stored and indexed.
Analytics Logs: Data is written to a columnar store with full-text indexing on all string fields. The indexing is done at ingestion time, allowing KQL queries to use search, where, and project operators efficiently. The index supports term searches, phrase searches, and free-text queries. This is similar to a traditional database index.
Basic Logs: Data is written to the same columnar store but with minimal indexing. Only the TimeGenerated column is indexed by default. No full-text index is created for other columns. This means queries on Basic Logs must use where clauses on TimeGenerated and avoid free-text searches. If you try to search a Basic Logs table for a specific string without a time filter, the query will scan the entire table — potentially very slow and expensive in terms of CPU (though not billed per query).
Key Components, Values, Defaults, and Timers
Table plans: Each table in a Log Analytics workspace has a plan property. You can set it to Analytics or Basic via the Azure portal, PowerShell, or ARM templates. The default plan for new tables is Analytics.
Cost: Analytics Logs cost approximately $2.30 per GB ingested (varies by region and commitment tier). Basic Logs cost approximately $0.50 per GB ingested — roughly 80% less. However, Basic Logs also incur a small charge for data scanned during queries (currently $0.005 per GB scanned).
Retention: Both tiers support the same retention settings (30 days to 730 days for interactive retention, plus archive up to 7 years). However, Basic Logs are often used for long-term retention of noisy data.
Query capabilities: Analytics Logs support all KQL operators, including search, summarize, render, and join with other Analytics tables. Basic Logs support a subset: where, project, extend, take, count, summarize (with limited aggregates), and join only with other Basic Logs tables. Notably, search and union across plans are not supported.
Interactive vs. Basic queries: Queries against Analytics Logs are interactive and fast (sub-second). Queries against Basic Logs are optimized for scanning but may take tens of seconds for large datasets.
Configuration and Verification
To configure a table's plan, you can use the Azure portal:
1. Navigate to your Log Analytics workspace > Tables.
2. Select a table (e.g., Syslog).
3. Under 'Table plan', choose 'Basic' or 'Analytics'.
4. Click Save.
Alternatively, using PowerShell:
Update-AzOperationalInsightsTable -ResourceGroupName <RG> -WorkspaceName <Workspace> -TableName 'Syslog' -Plan 'Basic'To verify the current plan:
Get-AzOperationalInsightsTable -ResourceGroupName <RG> -WorkspaceName <Workspace> -TableName 'Syslog' | Select-Object Name, PlanYou can also query the _Logs metadata table to see table plans.
Interaction with Related Technologies
Sentinel Analytics Rules: Most analytics rules (scheduled queries) require Analytics Logs because they use search or complex aggregations. If a rule queries a Basic Logs table, it will fail or produce incomplete results. Always ensure that tables referenced in analytics rules are Analytics Logs.
Hunting: Hunting queries often use search across multiple tables. Since Basic Logs cannot be searched with search, hunters must know which tables are Basic and write targeted queries.
Workbooks and Dashboards: Workbooks that query Basic Logs will work but may be slower. It's best to use Analytics Logs for real-time dashboards.
Data Connectors: Some connectors send data directly to Basic Logs tables (e.g., Azure Firewall logs can be configured to use Basic). Others default to Analytics.
Limitations and Considerations
Basic Logs cannot be used as target for data export to Event Hubs or Azure Data Explorer.
Basic Logs do not support Customer-Managed Keys (CMK) at the table level.
Basic Logs are not available in all regions yet (check documentation).
Changing a table from Analytics to Basic is a one-way operation? No, you can switch back, but note that historical data remains in the original plan. New data after the switch will follow the new plan. However, Microsoft recommends careful planning because query patterns may break.
Basic Logs are ideal for: verbose logs (DNS, firewall, NetFlow), raw event logs with low signal-to-noise ratio, compliance data that must be retained but rarely accessed, debugging logs from applications.
Exam-Relevant Details
The SC-200 exam may ask: 'Which table plan should you use for a custom log that will be queried only once a month for compliance?' Answer: Basic Logs.
'Which KQL operator is NOT supported on Basic Logs?' Answer: search.
'What is the cost difference between Basic and Analytics Logs?' Basic is ~80% cheaper.
'Can you run a search * query on a workspace that contains Basic Logs?' No, search does not scan Basic Logs.
'How do you configure a table to use Basic Logs?' Via the Table plan setting in the portal or PowerShell.
Identify candidate tables for Basic Logs
Begin by analyzing your data ingestion. Look for tables that consume high volumes but are rarely queried. Common candidates include: `Syslog`, `CommonSecurityLog`, `AzureDiagnostics` (if verbose), `Custom Logs` from verbose sources. Use the `Usage` table to find top tables by ingestion volume. Then check query frequency using the `_LogOperation` table or Log Analytics workspace insights. For the SC-200 exam, remember that tables with high ingestion and low query frequency are ideal for Basic Logs.
Assess query requirements for each table
For each candidate table, list the queries that will be run against it. If any query uses `search`, `union` with Analytics tables, or requires full-text indexing, the table must remain Analytics. Also, if the table is used in Sentinel analytics rules or workbooks that need real-time performance, keep it as Analytics. Basic Logs are only suitable for tables queried with simple `where` clauses on `TimeGenerated` and a few columns. This step is critical because moving a table to Basic Logs can break existing detection rules.
Configure the table plan to Basic
Once you've confirmed a table is suitable, change its plan to Basic. This can be done via the Azure portal (Tables blade > select table > Table plan > Basic) or PowerShell: `Update-AzOperationalInsightsTable -ResourceGroupName <RG> -WorkspaceName <Workspace> -TableName 'Syslog' -Plan 'Basic'`. Note that the change applies only to new data; existing data remains in the original plan. The change is immediate and reversible. However, Microsoft recommends monitoring after the change to ensure no operational impact.
Update queries and analytics rules
After changing the plan, review all queries and analytics rules that reference the table. Remove any `search` operators or replace them with `where` clauses on indexed columns (only `TimeGenerated` is indexed). For example, a query like `Syslog | search 'error'` must be rewritten as `Syslog | where TimeGenerated > ago(1d) | where SyslogMessage contains 'error'`. This may cause increased scan time but is acceptable for infrequent queries. Also, ensure that any cross-table joins are only between tables of the same plan.
Monitor cost and performance
After implementation, monitor the ingestion cost reduction using Azure Cost Management. You should see a significant decrease in Log Analytics costs. Also, monitor query performance for the Basic Logs table. Use the `_LogQuery` table to see query execution stats. If queries are too slow, consider adding more specific `where` clauses or moving some data back to Analytics. For the exam, remember that Basic Logs query performance is acceptable for 'occasional' queries but not for real-time alerting.
Enterprise Scenario 1: Firewall Log Optimization
A large enterprise ingests 500 GB/day of firewall logs from 200 firewalls into a single Log Analytics workspace. The logs are stored in the CommonSecurityLog table. The security team needs to retain these logs for 1 year for compliance, but they only query them for forensic investigations about once a month. Previously, all data was Analytics Logs, costing ~$350,000/year. By switching CommonSecurityLog to Basic Logs, the cost drops to ~$73,000/year — a savings of $277,000. The team updated their few monthly queries to use where TimeGenerated > ago(30d) and avoided search. They also created a separate Analytics Logs table for high-priority alerts extracted from firewall logs (e.g., known bad IP hits) to ensure fast detection.
Enterprise Scenario 2: Custom Application Debug Logs
A SaaS company ingests 2 TB/day of verbose debug logs from its microservices into a custom table AppDebugLogs. These logs are used by developers to troubleshoot issues, but only a few times per week. The cost of storing as Analytics Logs was unsustainable. They switched to Basic Logs, reducing cost by 80%. Developers now query with time-bound filters and simple string matches. For urgent debugging, they have a process to temporarily switch the table back to Analytics (or use a separate Analytics table for critical services). The key lesson: Basic Logs are ideal for 'cold' data that is rarely accessed but must be retained.
Common Misconfiguration Pitfalls
Breaking analytics rules: A common mistake is switching a table that powers a scheduled analytics rule to Basic Logs. The rule fails silently or produces no results because search is used. Always audit rules first.
Assuming all tables support Basic Logs: Some tables, like Heartbeat or Usage, are system tables and cannot be changed. Only user-created tables and certain connector tables support Basic Logs.
Ignoring query pattern changes: Even if queries are rewritten, they may become slower. For large Basic Logs tables, scanning can take minutes. Use where clauses on TimeGenerated to limit the scan range.
Not monitoring after change: After switching, verify that the expected cost savings materialize and that no critical queries break. Use Azure Monitor alerts for query failures.
SC-200 Exam Focus on Basic vs Analytics Logs
The SC-200 exam tests this topic under objective 2.1: 'Design and configure a Log Analytics workspace' and 2.2: 'Manage log retention and archiving'. Expect 2-3 questions that directly compare the two tiers. Key exam points:
Cost difference: Basic Logs are approximately 80% cheaper than Analytics Logs. The exact number may be given in a scenario; know that Basic is 'significantly lower cost'.
Query limitations: The most tested limitation is that search and union across plans are not supported. The exam loves to ask: 'Which KQL operator will fail on a Basic Logs table?' Answer: search.
Use cases: Basic Logs are for 'verbose, high-volume, low-value' data. Common examples: firewall logs, DNS logs, NetFlow, debug logs.
Configuration: Know that you set the table plan per table via the portal or PowerShell. The default plan is Analytics.
Retention: Both tiers support the same retention settings. Basic Logs do not have a different retention limit.
Common Wrong Answers and Traps
Trap 1: 'Basic Logs are for long-term retention only.' Reality: Both tiers support long retention. The difference is cost and query capabilities.
Trap 2: 'Basic Logs cannot be queried at all.' Reality: They can be queried, but with limited operators.
Trap 3: 'You can change a table from Basic to Analytics without affecting existing data.' Reality: The change applies only to new data; historical data remains in the original plan.
Trap 4: 'Basic Logs are free.' Reality: They are cheaper but still incur ingestion and scanning costs.
Trap 5: 'All tables support Basic Logs.' Reality: System tables do not.
Edge Cases the Exam Tests
What if a table is used in both an analytics rule and a hunting query? The table must be Analytics because analytics rules require full indexing.
Can you use Basic Logs for a table that feeds a workbook? Yes, but the workbook may be slow. The exam may ask you to recommend a plan based on performance requirements.
What happens if you try to run `union` between an Analytics table and a Basic table? The query fails. The exam expects you to know this.
How to Eliminate Wrong Answers
If the scenario mentions 'real-time alerting' or 'frequent queries', eliminate Basic Logs.
If the scenario mentions 'compliance retention' or 'rarely accessed', Basic Logs is likely correct.
If the question asks about 'cost reduction', Basic Logs is the answer.
If the question asks about 'full-text search', the answer must be Analytics Logs.
Master these points, and you'll confidently answer any SC-200 question on this topic.
Basic Logs are approximately 80% cheaper than Analytics Logs.
Basic Logs do not support the `search` operator or full-text indexing.
Only `TimeGenerated` is indexed in Basic Logs; queries should use time filters.
You can change a table's plan between Basic and Analytics at any time, but changes apply only to new data.
System tables (e.g., Heartbeat, Usage) cannot be changed to Basic Logs.
Basic Logs are ideal for verbose logs like firewall, DNS, and debug logs that are rarely queried.
Analytics rules that use `search` or complex aggregations require Analytics Logs.
Basic Logs support `join` only with other Basic Logs tables.
These come up on the exam all the time. Here's how to tell them apart.
Basic Logs
Cost: ~$0.50/GB ingested (80% cheaper)
Indexing: Only TimeGenerated indexed
Query support: No search, no union with Analytics tables
Use case: High-volume, low-value, rarely queried data
Performance: Slower queries, optimized for scanning
Analytics Logs
Cost: ~$2.30/GB ingested
Indexing: Full-text indexing on all string columns
Query support: All KQL operators, including search and union
Use case: Frequently queried data, real-time alerting, dashboards
Performance: Fast, interactive queries
Mistake
Basic Logs are completely free.
Correct
Basic Logs cost about 20% of Analytics Logs per GB ingested, and there is a small charge for data scanned during queries ($0.005/GB scanned). They are not free.
Mistake
You can run any KQL query on Basic Logs.
Correct
Basic Logs do not support the `search` operator, `union` with Analytics tables, or full-text indexing. Only a subset of KQL operators is allowed.
Mistake
Changing a table to Basic Logs affects all existing data.
Correct
The change applies only to new data ingested after the change. Existing data remains in the original plan (Analytics or Basic).
Mistake
Basic Logs are only for custom logs.
Correct
Basic Logs can be applied to many built-in tables like `Syslog`, `CommonSecurityLog`, and `AzureDiagnostics`, provided they are not system tables.
Mistake
Basic Logs cannot be used in Sentinel.
Correct
Basic Logs can be used in Sentinel, but they cannot be the source for analytics rules that require full indexing. They can be used for hunting and workbooks with limitations.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The main difference is cost and indexing. Basic Logs are about 80% cheaper per GB ingested but only index the TimeGenerated column, so queries are limited to simple `where` clauses and cannot use `search` or full-text search. Analytics Logs are fully indexed, support all KQL operators, and are optimized for fast interactive queries. Choose Basic Logs for high-volume, low-value data that is rarely queried, and Analytics Logs for data that needs real-time alerting or frequent analysis.
No. The `search` operator does not scan Basic Logs tables. It only searches Analytics Logs tables. If you try to run `search *`, you will only get results from Analytics tables. To query Basic Logs, you must explicitly reference the table name and use a `where` clause, typically filtering on TimeGenerated.
You can change the table plan via the Azure portal: go to your Log Analytics workspace > Tables, select the table, and under 'Table plan' choose 'Basic'. Alternatively, use PowerShell: `Update-AzOperationalInsightsTable -ResourceGroupName <RG> -WorkspaceName <Workspace> -TableName 'Syslog' -Plan 'Basic'`. The change takes effect immediately for new data. Existing data remains in the original plan.
No. System tables like `Heartbeat`, `Usage`, and `AzureActivity` cannot be changed to Basic Logs. Only user-created tables and certain connector tables (e.g., `Syslog`, `CommonSecurityLog`, `AzureDiagnostics`) support the Basic plan. Check Microsoft documentation for the full list.
Basic Logs support a subset of KQL operators: `where`, `project`, `extend`, `take`, `count`, `summarize` (limited aggregates like `count()`, `dcount()`, `make_set()`), and `join` only with other Basic Logs tables. They do NOT support `search`, `union` with Analytics tables, `evaluate`, `render`, or full-text search. Queries must include a time filter on `TimeGenerated` for efficiency.
It depends. If the analytics rule uses a simple `where` clause on `TimeGenerated` and does not require `search` or complex joins, it can work with Basic Logs. However, most built-in analytics rules use `search` or cross-table queries, so they require Analytics Logs. If you create a custom rule that only queries a Basic Logs table with simple filters, it will work but may be slower. Microsoft recommends using Analytics Logs for analytics rules.
Yes. Basic Logs support the same interactive retention (30-730 days) and archive retention (up to 7 years) as Analytics Logs. The difference is only in cost and query capabilities. Basic Logs are often used for long-term retention of high-volume data that is rarely accessed.
You've just covered Sentinel Basic Logs vs Analytics Logs — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?