5.4 Log Types: Analytics vs Basic vs Archive

90 minutes · Module 5

Log Types: Analytics vs Basic vs Archive

By the end of this subsection, you will understand the three log tiers, their cost and query implications, and be able to assign the correct tier to each data source in your environment.

Not all log data has the same value to security operations. Sign-in logs need to be instantly queryable. Heartbeat data from 200 devices does not. Microsoft’s three-tier log model lets you match storage cost to operational value.

The three tiers

Tier	Cost	Query speed	Retention	Analytics rules	Best for
Analytics	Highest (~$2.76/GB/day)	Full KQL, instant	90 days interactive + archive	Yes — full support	Security tables you query daily (sign-in, email, alerts)
Basic	~~65% cheaper (~~$1.00/GB/day)	Limited KQL (no join, no summarize)	30 days interactive + archive	Limited — basic queries only	High-volume, low-value data (network flow, verbose endpoint telemetry)
Archive	Lowest (~$0.02/GB/month)	Search jobs only (minutes to hours)	Up to 12 years	No	Long-term compliance, cold investigation data

Basic logs save money but limit your detection capability

Basic log tables do not support join, summarize, or let statements. This means you cannot build meaningful analytics rules against them — most detection logic requires aggregation or correlation. Assign Basic tier only to tables you will never build detection rules against.

Which tables go in which tier

Analytics tier (default — keep these here):

These tables drive detection rules, investigation queries, and hunting. They must support full KQL.

SigninLogs / AADNonInteractiveUserSignInLogs — every investigation starts here
SecurityAlert / SecurityIncident — your alert pipeline
EmailEvents / EmailUrlInfo / UrlClickEvents — email investigation
DeviceProcessEvents / DeviceNetworkEvents — endpoint investigation
CloudAppEvents — cloud app activity (inbox rules, OAuth)
AuditLogs — directory changes, app consents
OfficeActivity — mailbox access, file activity
ThreatIntelligenceIndicator — IOC matching

Basic tier (move these to save cost):

High-volume tables that provide context during investigation but rarely drive automated detection.

DeviceFileEvents — file creation/modification on endpoints (extremely high volume)
DeviceRegistryEvents — registry changes (high volume, mostly noise)
DeviceImageLoadEvents — DLL loading events (very high volume)
Heartbeat — agent health data
AzureActivity — Azure management plane (unless you build Azure-specific detections)
AADProvisioningLogs — user provisioning events

Changing a table from Analytics to Basic is irreversible for 30 days

Once you change a table's plan to Basic, you cannot change it back for 30 days. Any analytics rules that reference the table will fail. Test the impact on your existing rules before making the change — run a dependency check first.

Archive tier

Data older than the interactive retention period (90 days for Analytics, 30 days for Basic) can be archived. Archive data costs ~$0.02/GB/month — orders of magnitude cheaper than interactive storage.

Archived data is not directly queryable with standard KQL. To access it:

Search jobs: Submit a KQL query against archived data. Results are delivered to a new table in your workspace (minutes to hours depending on data volume).
Restore: Temporarily restore a time range of archived data back to the interactive tier for full KQL querying. Costs the Analytics ingestion rate for the restored data.

1
2
3
4
5
6
7
// Check your current table plans and volumes
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize GB = round(sum(Quantity) / 1024, 2) by DataType
| sort by GB desc
| take 20

Expected Output

DataType	GB
DeviceFileEvents	48.7
DeviceProcessEvents	22.3
DeviceNetworkEvents	18.1
SigninLogs	8.4
EmailEvents	5.2
AADNonInteractiveUserSignInLogs	4.8
DeviceRegistryEvents	41.2
DeviceImageLoadEvents	37.5

What to look for: The three highlighted tables (DeviceFileEvents, DeviceRegistryEvents, DeviceImageLoadEvents) account for ~127 GB of your 30-day ingestion. Moving them to Basic tier saves ~65% on those tables alone. SigninLogs and EmailEvents at 8.4 GB and 5.2 GB must stay on Analytics — they drive your detection rules.

Try it yourself

Run the Usage query above in your workspace. Identify your top 3 highest-volume tables. For each one, determine whether it should stay on Analytics (drives detection rules) or move to Basic (contextual data only). Write down your reasoning.

Ask two questions for each table:

1. Do I have (or plan to build) analytics rules that query this table? If yes, it must stay on Analytics. Basic tier does not support the KQL operators that detection rules need (join, summarize, let).

2. Do I query this table regularly during investigations? If yes but you do not build detection rules against it, Basic is acceptable — you can still run simple queries during ad-hoc investigation, just without join/summarize. If you rarely touch it, Basic or even Archive is appropriate.

Check your understanding

1. You want to build an analytics rule that joins SigninLogs with DeviceFileEvents. Can you move DeviceFileEvents to Basic tier?

Yes — Basic supports all KQL operators

Yes — the join runs on the Analytics table, not the Basic table

No — Basic tier does not support join. Your analytics rule would fail. Either keep DeviceFileEvents on Analytics, or redesign the rule to not require the join.

Basic tier restrictions apply to ANY query that touches the table, including analytics rules. If a detection rule joins against a table, that table must be on Analytics tier. This is why you check rule dependencies before changing table plans.

2. DeviceRegistryEvents uses 41 GB/month in your workspace. You have no analytics rules that query it. What is the cost-optimized approach?

Move it to Basic tier. You save ~65% on 41 GB/month. You can still run simple investigative queries (where, project, take) when needed. If you later need to build detection rules against it, you can move it back to Analytics after 30 days.

Delete the data

Reduce retention to 7 days

Basic tier is the right balance: significant cost savings, still queryable for investigation, and reversible (after 30 days). Deleting data or reducing retention creates gaps you cannot recover from during an investigation.

← 5.3 Creating Your First Workspace 5.5 Cost Management and Optimization →