Whether on pay-as-you-go or a commitment tier, ingesting pointless data to Sentinel is wasteful. You can filter incoming data before it’s stored in the Log Analytics workspace where it would start costing money.  

There are two types of logs that you can opt to ingest. To get the full value of Sentinel as an early warning system, Analytics Logs are the standard.  

The easy yet debatable way to reduce ingestion is by using Basic Logs. Basic logs are best for data with low detection value, but good for forensics. Netflow, TLS certificate monitoring, and cloud storage access logs are good examples. They aren’t going to be the first triggers of an incident but could identify breadcrumbs as you do forensics on a suspected breach. There’s an extra fee to search/analyze basic logs.  

In a nutshell, Basic Logs are an option appropriate for budget-conscious organizations who don’t plan to actively use the SIEM for proactive detection and resolution– but who may need to check a box to have a SIEM for a compliance requirement. SIEM expert Rod Trent wrote a good blog about When to Use and When NOT to Use Basic Logs with Microsoft Sentinel  

Now, back to the standard Analytics Logs. What can be done to manage their costs? A somewhat sophisticated way to streamline ingested data is to ‘transform’ the logs before they hit the Log Analytics workspace. Log Analytics’ custom data ingestion process gives you a high level of control over the data that gets ingested. Transforming could mean removing redundancies (i.e. two firewalls in an HA pair sending similar logs) or truncating logs from the device. For instance, there Syslog has eight levels of severity, ranging from Emergency to Debug. Customers rarely need all eight. You can configure the device itself to send a specific level of logs, and you can use Log Analytics’ Data Collection Rules to filter unwanted logs.