Microsoft Sentinel Basic Logs vs Analytics Logs: cost and limits

Microsoft Sentinel stores its data in a Microsoft Azure Monitor Log Analytics workspace. Every table in that workspace has a table plan, and Microsoft Azure Monitor offers three plans: Analytics, Basic, and Auxiliary / Lake.

The names get confusing because Microsoft Sentinel in the Microsoft Defender portal uses a second vocabulary: the analytics tier and the data lake tier. In a workspace onboarded to the Microsoft Sentinel data lake, Auxiliary tables become part of the data lake tier. Basic Logs tables are the odd one out: you can view them in the Microsoft Defender portal, but you manage them only from the Log Analytics workspace.

This article uses the Microsoft Azure Monitor plan names because those are the values the CLI, PowerShell, and REST API accept.

Every row below comes from Microsoft’s table feature comparison, the Basic and Auxiliary query documentation, and the table plan page, all checked on 5 October 2026.

Microsoft publishes list prices through the Microsoft Azure Retail Prices API, the same data behind the Microsoft Sentinel pricing page and the Microsoft Azure Monitor pricing page. We pulled the figures below on 5 October 2026 for East US, pay-as-you-go, USD, on Microsoft’s simplified pricing tier. Prices vary by region and agreement, so confirm with the Microsoft Sentinel cost estimator before budgeting.

Two details from the Microsoft Sentinel billing documentation matter here. On the simplified pricing tier, Basic Logs bill as a single Microsoft Sentinel meter named Basic Logs Analysis; classic-pricing workspaces pay a Microsoft Sentinel analysis meter plus a Microsoft Azure Monitor ingestion meter instead. Microsoft Sentinel workspaces retain ingested data at no charge for the first 90 days, which is why the Analytics interactive window can be 90 days rather than the plain Log Analytics default of 30. Microsoft describes 30 days as the default with a free extension to 90, so check that each table’s retention is set to 90.

One caveat on the lake meters. The Microsoft Sentinel pricing page still carries a footnote that calls lake data processing free "during preview". The lake has been generally available since 30 September 2025 and the Retail Prices API bills processing at $0.10 per GB, so we use the API figure.

The cost table is the easy part. These seven limits matter most after the switch.

Microsoft’s guidance splits data into two categories. Primary security data feeds detection rules, hunting, correlation, and behavior analytics, including EDR and antivirus logs, authentication logs, cloud audit trails, threat intelligence, and alerts from other systems. That belongs on Analytics. Secondary security data adds context during an investigation but rarely triggers one, such as cloud storage access logs, NetFlow, TLS/SSL certificate logs, firewall logs, proxy logs, and IoT logs.

Microsoft recommends the data lake tier for secondary data and doesn’t mention Basic. Basic remains a supported plan, and in our view it is the right fit for secondary data when you are not onboarded to the lake, or your investigators need the 30-day interactive window. Five questions settle most tables:

Microsoft Azure tables default to Analytics. You can switch a supported table from the portal, Microsoft Azure CLI, PowerShell, or REST. Microsoft documents all of them on the table plan configuration page. You need Microsoft.OperationalInsights/workspaces/write and workspaces/tables/write permissions, which the Log Analytics Contributor role provides.

Microsoft Azure CLI:

Microsoft Azure PowerShell:

REST, using the Tables - Update operation:

Three things happen on the switch. Data older than 30 days is treated as long-term retention, although total retention doesn’t change. Queries, including summary rules reading the table, start billing per GB scanned. And summary rules using resource query scope break, because Basic tables only support workspace scope. Switch back with --plan Analytics, but remember the one-week limit.

Querying a Basic table works like querying any other table. Microsoft rewrote its Basic and Auxiliary query documentation in September 2026: queries that include these tables now support full KQL across multiple tables, so join and union to other tables now work. If you read about single-table limits in older guides, including Microsoft’s own, they no longer apply to interactive queries. Two constraints remain: workspace scope, and no data past 30 days.

Enriching Basic data with an Analytics table works the same way it does between Analytics tables. This query adds the last successful sign-in for each source IP:

Microsoft bills a mixed query on the data it scans in the Basic and Auxiliary tables. Analytics tables within their retention period don’t add to the scanned volume, so joining a small Basic window to a large Analytics table stays cheap.

If you still want alerting on Basic data, the documented route is a summary rule. It aggregates the Basic table on a schedule into a custom Analytics table that detections can read. Summary rules are the one place the old limits still apply: Microsoft’s summary rule documentation says a rule reading a Basic table must stay on that single table, joining Analytics tables only through lookup. The rule bills on data scanned plus ingestion of the summarized rows.

For anything past the 30-day window, run a search job. It scans Basic or long-term data asynchronously and writes matches to a new _SRCH Analytics table you can query normally:

Microsoft charges search jobs for the data they scan plus ingestion of the matching records they write, so scope the time range tightly.

Table plans set the price per GB. Filtering and routing at the agent set how many GB you ingest and which table each event lands in. The two controls multiply: a Basic table receiving a third of the original volume costs about 8% of the same feed on Analytics at full volume.

Microsoft’s ingestion-time option is a KQL transformation in a data collection rule. It works, but read the cost rules: if a transformation drops more than 50% of incoming data bound for an Analytics or Basic table, Microsoft charges for the filtered volume above 50%. Microsoft Sentinel workspaces are exempt for Analytics tables, not for Basic. Microsoft’s own advice is to filter ingested data by other means before applying transformations, and the log collector on the host is where you do that.

NXLog Agent sends to Microsoft Sentinel through the Microsoft Azure Logs Ingestion output module, which uses the Logs Ingestion API with a data collection endpoint, a DCR, and a stream name. The agent evaluates every event before sending, so one Windows Security channel can feed two custom tables: detection-relevant event IDs go to a table on the Analytics plan, and everything else goes to a table on the Basic plan. Both are DCR-based custom tables, so both plans are supported.

The configuration below combines the Microsoft Azure Logs Ingestion output module setup from NXLog’s Microsoft Sentinel integration guide with the two-output filtering pattern from the NXLog documentation: one input, two outputs, one route. Each output uses an Exec block to drop the events it isn’t responsible for, which keeps flow control intact. A single DCR declares both streams, Custom-WinSecDetect and Custom-WinSecContext, each mapped to its own destination table.

Three details from the module documentation matter:

You can still add a DCR transformation on the Basic stream to drop columns you never query. KQL transformations accept single-row operators only, so where and project work, but summarize doesn’t. Keep the heavy filtering on the agent, and the transformation stays under the 50 percent rule.

If you manage more than a handful of hosts, NXLog Platform stores these configurations centrally. Build the tiered routing once as a configuration, assign it to the agents that need it, and push updates from one place when your event ID list changes.

Four changes affect how you read the comparison above.

Our reading: if your workspace is onboarded to the data lake, evaluate the lake tier before choosing Basic for new secondary data. It is cheaper on every meter, and it is where Microsoft is adding features. If you are not onboarded, or your investigators need the 30-day interactive window, Basic Logs is still a supported plan at under a quarter of the Analytics list price. Either way, keep detection data on Analytics and decide the tier of everything else at the agent.

Ask one question per table: does a detection read it? If yes, keep it on Analytics and accept the price. If no, Basic saves about 77% against pay-as-you-go list price, or about 66% against the 100 GB per day commitment tier. The data lake tier saves more. NXLog Agent then decides which events reach the workspace at all.

Want to try tiered routing on your own Windows hosts? Start a free NXLog Platform trial and use the Microsoft Sentinel integration guide to connect your first agent. Prefer to talk through a design first? We’re happy to help through our contact page.