Microsoft Sentinel on a budget: SIEM design choices that control ingestion costs

Microsoft Sentinel is a genuinely capable cloud-native SIEM and SOAR platform, and the single biggest blocker to adopting it is not capability — it is the fear of the bill. That fear is well-founded: Sentinel is priced substantially on data ingestion, so a naive deployment that pipes everything into the analytics tier can produce an invoice that gets the whole project cancelled. But the cost is a design problem, and design problems have design solutions. Done deliberately, Sentinel delivers enterprise SOC capability at a cost that survives budget review.

Here are the choices that decide the bill.

Understand what you actually pay for

Sentinel's dominant cost is data ingestion and retention — you pay largely by the volume of logs flowing in and how long they are kept. This single fact should drive every design decision: the question for each data source is not "can we collect this?" but "is the security value of this data worth its ingestion cost, and in which tier?" A SOC that treats all data as equally worth full-price ingestion is the one whose costs spiral. Commitment tiers (pre-purchasing capacity at a discount) then optimise the volume you have deliberately chosen — but they optimise a decision you still have to make well first.

The design levers that control cost

• Use table tiers deliberately. Not all data needs to sit in the premium, fully searchable, real-time analytics tier. Sentinel's pricing model now spans an Analytics tier for primary security data that must be queryable at speed, Auxiliary and Basic logs for high-volume, low-fidelity sources (verbose network, firewall and proxy data) at materially lower cost with reduced query capability, and a data lake tier built for very low-cost long-term retention of secondary data that stays accessible for historical hunting and compliance. Routing the right tables to the right tier is the largest single cost lever in Sentinel. Confirm current tier names, capabilities and rates before designing — this part of the platform has moved twice in two years.
• Filter at the source with Data Collection Rules. Do not ingest and then discard — filter before ingestion. DCRs drop the noise (routine informational events with no security value) at collection, so you never pay to bring it in. Most raw log streams are substantially noise from a detection standpoint; filtering at source is free savings.
• Be disciplined about connectors. Every connector is a cost commitment. Enable the ones that feed actual detections and investigations; resist enabling connectors "for completeness." A connector whose data no analytics rule uses and no analyst queries is pure cost.
• Send security-relevant data, keep operational data elsewhere. Sentinel is a security tool. Operational and performance telemetry that belongs in a monitoring platform should not be paying SIEM ingestion rates — a common and expensive category error.
• Tune retention by data type. Different data has different useful lifespans for security. Match retention to genuine investigative and compliance need rather than applying one long retention period to everything.

What you must not cut

Cost control must not become blindness. The identity, endpoint, email and cloud telemetry that feeds your core detections is exactly the data worth paying analytics-tier rates for — the signals that catch AiTM, ransomware and BEC. The discipline is not "ingest less of everything"; it is "ingest the high-value security signals at full capability, route the high-volume low-value data cheaply, and drop the noise before it costs anything." A Sentinel deployment that saved money by cutting endpoint or identity logs saved money by removing its own reason to exist.

The E5 economics footnote

If you hold Microsoft 365 E5, E7 or the E5 Security add-on, factor in the data grant: these entitlements include an allowance of up to 5 MB per user per day of eligible Microsoft 365 data ingestion into Sentinel at no ingestion cost, applied automatically to your bill. The eligible sources are ones you would want anyway, Entra ID sign-in and audit logs among them. For an organisation of any size this materially changes the economics and can make Sentinel dramatically cheaper than it first appears, which is why the licensing and SIEM decisions belong in the same conversation rather than in separate silos.

Design the SOC, then the pipeline

The right sequence is detection-led: decide what you need to detect (your threat model and priority use cases), which determines what data those detections require, which determines what you ingest and at what tier. Deployments that spiral did the reverse — connected every available source first, then discovered the bill and the noise together. Start from the detections you actually need aligned to your Zero Trust priorities, and the data pipeline — and its cost — follows from a security decision rather than a default.

Practical steps

Before enabling a single connector, list the detections you actually need and work backward to the minimum data that powers them. Route high-volume, low-value tables to the Auxiliary, Basic or data lake tiers and filter noise at source with DCRs. If you hold E5 or E7, account for the 5 MB per user per day data grant in the maths. QG designs and builds Microsoft Sentinel deployments — workspace architecture, tiered ingestion, connectors, analytics rules and playbooks — engineered for the detections that matter at a cost that survives the second-year budget review.