Sentinel on a Budget: How to Tame Your Log Costs

Alright, class.

You've done it. You've deployed Sentinel, connected your data sources, written some slick analytic rules, and maybe even automated a few things. You feel like a security god, sitting atop your mountain of logs, observing all that happens in your digital kingdom.

Then, the first Azure bill arrives.

And just like that, you're knocked off your mountain. You stare at the number, your eye twitching. You can almost hear your CFO's footsteps approaching your desk. Suddenly, your beautiful security death star feels less like a fortress and more like a money pit.

Welcome to the real endgame of a Sentinel deployment: Cost Optimisation. Don't panic. Taming your Azure bill isn't a dark art; it's a critical engineering skill. Mastering this is what separates the students from the professors.

Step 1: Find the Leak - Where is the Money Going?

Before you can fix the problem, you need to find out who's making all the noise. You don't start ripping wires out of your car's engine; you run a diagnostic first.

• The Easy Way: The Workspace Usage Report Workbook
  Go to the Sentinel Content Hub, search for "Workspace Usage Report," and install it. This workbook is your free, built-in cost dashboard. It will show you, in beautiful, easy-to-read charts, exactly which log tables are the fattest and costliest. Is it SecurityEvent? Syslog? This is your starting point.

The workbook will also show average table usage presented in an easy-to-read way. Can you already spot the spike in data ingestion?

You can also use the Microsoft Sentinel Cost workbook; it gives a bit less information than the previous one, but you will be able to see the actual costs in there.

Lastly, you can open Insights from the Usage and estimated costs in your Log Analytics Workspace, which gives you great visibility over the actual table usage

The KQL Way: The Usage Table
For a more granular view, you can query the Usage table directly in the Logs blade. This table holds the sacred texts on your data ingestion

Usage
| where TimeGenerated > ago(30d) 
| where IsBillable == true 
| summarize IngestedGB = sum(Quantity) / 1024
          by DataType 
| extend EstimatedCostUSD = round(IngestedGB * 5.38, 2)  // 5.38 USD per GB (adjust if needed)
| order by EstimatedCostUSD desc

This simple query displays every billable table and the amount of gigabytes it has consumed over the last 30 days, along with its estimated cost, sorted by the largest offender at the top. Now you have your target list.

Step 2: The Tuning Levers - Easy Cost Controls

Data Retention: Don't Pay for What You Don't Need

In your Log Analytics Workspace, you can set how long you want to keep your data. Here's the golden rule: Microsoft makes you pay for the first 90 days of retention no matter what. It's baked into the Sentinel price. Setting your retention to 30 or 60 days saves you zero money.

Anything above 90 days costs extra. Do you need 180 days of interactive log access? Maybe. Do you need 2 years? Probably not, and that's where you can adjust the slider to save money. You can even set this per-table, keeping your critical SecurityEvent logs for a year but tossing your verbose application logs after 90 days.
(For the full, terrifying details on pricing, see the official Microsoft Sentinel Pricing Page.)

Log Tiers: Not All Logs Are Created Equal

Sentinel gives you different "tiers" for your logs. Think of it like this:

• Analytics Logs (Standard): The VIP section. These logs can be used for everything: analytics rules, live queries, etc. They cost the most.
• Basic Logs: The general admission seats. They're much cheaper to ingest, but you can't run analytics rules on them. Perfect for verbose logs, you only need it for manual searching during an investigation (this tier is going to be discontinued moving forward, as it's not compatible with Defender's table tiers)
• Auxiliary: Long-term, cold storage. Dirt cheap, but you have to "rehydrate" the logs to search them. This is for compliance data you have to keep for a few years, but will hopefully never look at again. They are currently pushed by Microsoft by using a data lake. Cool feature that we will cover in the next blog posts.

A prime candidate for Basic and Aux logs is something like Storage Diagnostic Logs. They can be huge, and you rarely need to fire a real-time alert from them, but they're invaluable when you're investigating a specific incident.

Step 3: Filtering at the Gates - Stop Paying for Garbage

The single best way to save money is to not send useless logs to Sentinel in the first place.

• For Windows SecurityEvent Logs: When you set up the Azure Monitor Agent, you're creating a Data Collection Rule (DCR). In this rule, you can specify an XPath query. This is a powerful filter that tells the agent on the machine what to send. Instead of collecting "All Security Events," you can switch it to "Minimal" or write a custom XPath to exclude notoriously noisy event IDs (looking at you, Event ID 4663).

Example of XPath query:

System!*[System[(Level=1 or Level=2 or Level=3) and (EventID != 6)]]

This XPath filter shows all Critical, Error, and Warning events from the System log, except those with Event ID 6.

• For Syslog and CommonSecurityLog: This is where an intermediary forwarder becomes your best friend. A tool like Logstash or Cribl can act as a bouncer. You send all your firewall/proxy logs to Logstash, it filters out all the "allow" traffic and low-value noise, and then forwards only the important stuff (like "deny" traffic) to Sentinel. For those more knowledgeable; you can achieve the same result using .conf files in a Linux machine that forwards the logs, and, of course, the Data Lake tier is now also an option.

Question - Do You Even Need This Log?

Step back from the keyboard and ask the simple question: Why are we collecting this? I've seen environments with a dozen storage accounts, all dutifully sending diagnostic logs to Sentinel, but only two of them were actually important. The other ten were old dev projects. Turning off data connectors for decommissioned apps or unnecessary resources is pure, easy savings.

Advanced Plays and Free Money

• Azure Data Lake: For the true data hoarders, you can export your logs from Sentinel to Azure Data Lake. This is the endgame for ultra-low-cost, long-term storage, but it's a whole topic on its own.
• The Microsoft 365 E5 Data Grant: This is the "free money" coupon. If your organisation has M365 E5 licenses, Microsoft gives you a data grant of up to 5MB per user/day for ingesting certain Microsoft 365 data sources (like OfficeActivity and Azure Activity logs). It's not a huge amount, but it adds up. Make sure your finance team knows about this!
• The Defender for Servers P2: Microsoft Sentinel offers a free data ingestion benefit of 500 MB per virtual machine per day. I've seen quite a few customers where it was cheaper to buy a P2 license than holding onto the P1 just for that!

Cost management isn't a one-time project; it's a continuous process of tuning and questioning. By using these techniques, you'll not only save your company money but also prove that you understand the business side of security.

Now go forth and slay that Azure bill. Class dismissed.