How to Reduce Microsoft Sentinel Ingestion Costs Without Losing Detection Coverage

Microsoft Sentinel is one of the most capable SIEM platforms available, and for organisations already invested in Microsoft 365 and Azure it is often the natural choice. It also has a reputation for surprise bills. The cause is almost always the same: data flows into the most expensive tier by default, and nobody revisits the decision as log volumes grow.

The good news is that most Sentinel cost problems are design problems, and they can be fixed without weakening detection. This guide walks through the levers that matter, in the order we usually apply them.

Understand what you are paying for

Sentinel costs are driven mainly by the volume of data ingested and analysed, how long it is retained, and which tier it lands in. Microsoft now organises storage into an analytics tier, used for real-time detection, hunting and dashboards, and a lower-cost data lake tier intended for high-volume, lower-value data that you need to keep for investigation, compliance or occasional hunting. Table plans such as Basic and Auxiliary logs also exist, and Microsoft is folding the Auxiliary plan into the data lake experience, so check current documentation when you design.

The analytics tier can be paid for pay-as-you-go or through commitment tiers, which offer a discount in return for a fixed daily volume. Commitment tiers apply only to the analytics tier.

Lever 1: Make full use of free data sources

Several important data sources are free to ingest into Sentinel, including Azure Activity Logs, Office 365 audit logs (covering SharePoint activity, Exchange admin activity and Teams) and security alerts from Microsoft Defender products. These are high-value sources for detection. Connect them first, and make sure you are not paying to ingest the same information through another route.

Lever 2: Put each log type in the right tier

Not every log needs to be in the analytics tier. Ask of each source: do we run real-time detection rules on this, or do we need it mainly for investigation and retention?

• Analytics tier: identity sign-ins and audit logs, endpoint telemetry, cloud control plane logs, security alerts and anything your detection rules depend on.
• Data lake tier: high-volume network flow, firewall and proxy logs, verbose application logs, and data kept mainly for forensic look-back or compliance. Microsoft's own guidance identifies these high-volume sources as candidates for the data lake.

Data in the lake remains queryable for investigations and can be promoted or summarised when needed, so moving it is not the same as discarding it.

Lever 3: Filter at ingestion

Many log sources contain events and fields that have no security value: heartbeat messages, successful health checks, verbose debug output, repeated identical events. Azure Monitor data collection rules support ingestion-time transformations written in KQL, which can drop rows, remove columns and reshape data before it is stored. Typical candidates are noisy Windows event IDs that no detection uses, allowed traffic from known internal health monitors, and large free-text fields that duplicate structured data.

Be disciplined. Before dropping anything, check whether any analytics rule, workbook or hunting query depends on it, and document the decision. Cost reduction that silently breaks a detection is a false economy.

Lever 4: Use a pre-SIEM pipeline for multi-cloud data

Organisations running AWS, Google Cloud, Cloudflare or other sources alongside Azure face an extra challenge: those logs arrive in different formats and volumes, and connectors often ingest more than you need. A pre-SIEM pipeline normalises, filters and enriches data before it reaches Sentinel. Normalising to a common schema such as OCSF also makes detections easier to write once and apply across clouds.

Lever 5: Right-size commitment tiers and retention

Once ingestion is stable, compare your average daily analytics volume against the commitment tier thresholds. Committing too high wastes money; too low leaves savings on the table. Review retention too: the analytics tier includes an initial retention period, and longer retention is charged. Keeping long-term data in the lake rather than extending analytics retention is usually more economical.

Lever 6: Monitor cost as an operational metric

Treat ingestion volume like any other operational signal. Create an alert for unusual increases in daily ingestion, which can indicate a misconfigured connector or a new noisy source, and sometimes an attack. Report cost per source monthly so owners can see the impact of changes.

What not to cut

Some sources should stay in the analytics tier even when they are expensive, because they are where attacks show up first: identity sign-ins and audit logs, endpoint detection telemetry, privileged activity and cloud control plane changes. If budget is tight, reduce volume within these sources through filtering rather than removing them. Our managed detection and response buyer's guide covers which sources matter most for detection.

A worked approach to a cost review

A Sentinel workspace review usually follows the same process. Start with the Usage table to list billable volume by data type over the past 30 to 90 days. For the largest tables, identify which analytics rules, workbooks and hunting queries reference them, using the rule definitions and query logs. Tables with high volume and few or no detection dependencies are the first candidates for the data lake tier or for filtering.

Next, look inside the largest tables. In Windows security events, a small number of event IDs often account for most of the volume. In firewall logs, allowed traffic between known internal systems is frequently the bulk. In application logs, a single chatty component can dominate. Each finding becomes a proposed change with its expected saving and its detection impact, reviewed by the people who own the detections.

Implement changes in stages and measure the result. Compare ingestion and alert volumes before and after each change, and run a short detection validation, such as replaying known test activity, to confirm important rules still fire. Document every filter so future analysts understand why data is missing if they go looking for it.

How Pyralink helps

PyraLink™ Prove adds signed cloud configuration evidence that can support audits alongside your Sentinel data.

Frequently asked questions

Why is Microsoft Sentinel so expensive?

Costs are driven mainly by ingestion volume and the tier data lands in. Sending high-volume, low-value logs such as firewall and flow data into the analytics tier is the most common cause of high bills.

Which data sources are free in Microsoft Sentinel?

Microsoft lists Azure Activity Logs, Office 365 audit logs (SharePoint activity, Exchange admin activity and Teams), Sentinel health data and security alerts from Microsoft Defender products among the free data sources.

What is the Sentinel data lake tier?

A lower-cost storage tier for high-volume or long-retention security data that does not need real-time analytics. Data remains queryable for investigation and hunting.

Do commitment tiers apply to all Sentinel data?

No. Commitment tiers apply to the analytics tier only.

Can we filter logs before they are stored in Sentinel?

Yes. Data collection rule transformations can filter rows and remove columns at ingestion, and a pre-SIEM pipeline can filter and normalise data from multiple clouds before it reaches Sentinel.

Sources: Microsoft Learn: Plan costs and understand Microsoft Sentinel pricing and billing; Microsoft Learn: Azure Monitor Logs cost calculations; Microsoft Learn: Sentinel data lake log ingestion guidance; Microsoft Learn: Data collection transformations in Azure Monitor; Open Cybersecurity Schema Framework (OCSF).