Many organizations adopting Sentinel are reducing “time to configure and deploy new connections by 93%, with time saved in configuration valued at $618,000.” But licenses are based on consumption. So while this brings elasticity and flexible pricing, it can also lead to ballooning costs and unexpected invoice surprises as organizations bring more and more systems under the Sentinel umbrella.
What is Sentinel?
Sentinel is a cloud-based SIEM built for modern security operations centers. The platform works with these data types:
- Raw, unprocessed data for detecting and hunting malicious activity
- Security conclusions for alert visibility and opportunity for correlation
- Reference data to add context to optimize threat investigations
- Threat intelligence for historical and current threats
Sentinel offers an overarching view of a business’s entire security posture, along with orchestrating responses to alerts and events. The core purpose is to act like a unified security operations platform when combined with Defender XDR – collecting all security data from the customer, environment and facilitating post-incident response. Sentinel also expects customers to send all logs to the cloud, which, if done without planning, can be an expensive undertaking.
What is central log management?
Let’s stop for a moment to introduce the concept of independent central log management. This approach unifies log collection, processing and routing in a single platform, and can serve all log sources and destinations, like cloud SIEMs, equally – and, more importantly, independently.
There’s growing demand for these types of log management solutions, with the global market expected to rise at a CAGR or 11.4% through to 2030. Drivers include “escalating sophistication of cyberattacks” and “increasing availability of computer-generated log data.” Additionally, a variety of emerging trends impact environments, from the rise in automated log analysis and real-time anomalous situation detection to IoT integrations and immutable blockchain-based log data. While these offer great opportunities, Microsoft customers must take care to avoid Sentinel sticker shock.
That’s because many organizations are using several log management tools and deploying multiple collection agents on hosts. This can lead to silos with complex log data arriving at high volume, variety and velocity. Without stable collection agents, crashes can occur, and logs can go missing. Ultimately it becomes harder to filter, parse, re-write and classify larger semi-structured datasets.
Sentinel sticker shock: Factors and considerations
Without thorough planning and careful execution, fully implementing a Sentinel umbrella over a whole organization is an expensive proposition. The key challenge is the Sentinel licensing: Microsoft like other big cloud SIEM vendors, charges customers based on ingested data volumes, and it gets real expensive real fast.
How to tackle this challenge? The first steps involve examining pricing. So, let’s break down some of these areas to minimize cost overruns and optimize resources.
SIEM pricing
Pricing models are traditionally based on the volume of log messages ingested. This consumption-based approach means that operating costs can vary based on user or app activity. Over time, increased costs may be unavoidable as environments grow and require greater volumes for storage and retention.
You can find savings among the data sources that are free with Sentinel. These include Azure Activity Logs, Microsoft Sentinel Health and Office 365 audit logs, which include all activity in SharePoint, Exchange admin and Teams.
Security alerts are free, but some raw logs for some data types are paid – including Microsoft XDR, Defender for Endpoint/Identity/Office 365/Cloud Apps, Microsoft Entra ID and Azure Information Protection.
Within Sentinel pricing, there’s also a free 31-day trial. Although ‘free’ only includes the first 10GB per day for Log Analytics data ingestion and analysis. After that, pricing depends on your chosen log type and tier. As of January 2025, these ranged from:
- Analytics logs (for high value security data)
$5.22 per GB on a Pay-As-You-Go tier, to $2.36 per GB on a 50,000 GB per day tier – equivalent to $117,990 per day - Basic logs (more for ad hoc queries, investigations, and searches – less commonly used for deep analytics and alerts)
$1.12 per GB with separate charges for Azure Monitor pricing - Auxiliary logs (for high volume, low fidelity logs such as networks and firewalls)
$0.19 per GB with separate charges for Azure Monitor pricing
Across these three log types, Microsoft’s pricing structure also offers multiple data ingestion options. These include KQL querying, query concurrency, interactive queries, alerts support and retention.
The range of Pay-As-You-Go options offer many advantages – as long as you plan for the types of data ingestion sources. Third-party services can easily push up costs, so try comparing tier costs when volumes start rising.
It’s also worth noting that ‘free’ doesn’t include any automation or bring-your-own-machine-learning. And because Sentinel runs on Azure, deploying any new infrastructure-based resources can lead to higher costs. This includes the many Azure services that integrate with Sentinel, such as Azure Logic Apps and Azure Notebooks.
Ways to deliver Sentinel cost control
When SIEM pricing is based on log message volume, the theoretical answer is to send less data and minimize redundancies. In practice, this can be achieved in the following ways:
Filter unnecessary logs
Prevention is better than cure when managing ingested log data in Sentinel. That’s why filtering at the source should be one of the first things you do. Review whether you really need all the logs for infrastructure, networks and devices, or if you only need what’s relevant to security operations. Azure Stream Analytics can filter logs in real-time, so you can categorize logs and determine whether to send them to the Log Analytics workspace.
But if you’re looking for high-performance filtering in Sentinel, Microsoft offers words of caution: “Standard configuration for data collection might not work well for your organization,” and also, for on-prem Windows collection: “While filtering can lead to cost savings, and ingests only the required data, some Microsoft Sentinel features aren't supported.”
Limit verbose logs
You may have configured verbose logs to help with diagnosing pipeline failures and troubleshooting, and you might not need all the captured metrics to be ingested into Sentinel. Review and decide whether to limit metrics such as memory, CPU usage, job tasks to run and available disk space.
Log Analytics workspaces come with Data Collection Rules to help you control what data to ingest. Using basic KQL queries, you can filter verbose logs, enrich ingested data and support compliance by masking sensitive information.
Include less white space
White space can easily creep into logs, from unnecessary spaces or returns to slow down data processing speeds. One method to mitigate this is to implement regex functions that look for the starts and ends of strings. If there are any extraneous white space has been entered, or leading and trailing white space characters found, the regex can strip it out automatically.
Specify different retention settings for each data type
A Log Analytics workspace often contains multiple table types. By default, many tables keep data for at least 90 days without charge, and you can adjust individual tables, for example, separating non-security data into a standalone non-Sentinel workspace to avoid incurring costs.
Sentinel also offers dedicated clusters suitable for 100 GB+ ingestion volumes. Up to 1,000 workspaces in the cluster can share the tier costs, allowing you to retain the ability to run cross-workspace queries, although these are limited to 100 workspaces.
Use Azure services for long-term data retention
Azure Monitor allows you to adjust retention periods in your Log Analytics workspace. By default, tables retain data for 30 days (90 days for Usage and AzureActivity tables) for interactive usage such as visualizations or alerts. You can extend this interactivity for up to two years, and extend total retention for up to 12 years, with data retrieved and made available for interactive queries.
Azure Data Explorer is another option for saving on long-term storage costs. The platform uses KQL for queries and allows for cross-platform queries and visualizations. Configure your ingestion pipeline to export to an Azure Storage Account or Event Hub rather than being directed to the default Log Analytics workspace.
Balancing cost control with security
Naturally, all measures need to be carefully evaluated for reduced visibility and all the associated cybersecurity risks.
But risk is also a factor from a compliance and governance perspective. Logs may need to be retained and surfaced, such as HIPAA’s six-year retention requirements for specific documents or PCI DSS’s requirement to store data “for the minimum time required.” This will also influence pricing considerations, with analytics logs to “typically make up most of your higher value security logs.”
Another factor is where you’re ingesting data from. If sources are outside the Azure cloud, this can push up costs when ingesting high volumes.
Fortunately, help is at hand with what’s been described as the “Swiss army knife of log management.”
The syslog-ng way: Enhancing log management, avoiding sticker shock
Depending on the configuration, hardware and log data, syslog-ng can collect 500,000+ log messages per second from a wide variety of log sources, process them in real-time, and deliver them to your chosen destinations. As its name implies, syslog-ng originally focused on the syslog (system logging) protocol, but now connects with many other logging standards, including sending logs to Microsoft Sentinel. Deploy syslog-ng as an agent on a variety of hosts, route logs to your preferred analytics tools or databases, collect logs from sources including Windows and read log messages from any text file.
Message parsing enhances traditional filtering to focus on extracted information such as usernames and IP addresses. Enrichment and blocklist filtering also optimize filtering rules and transform logs on remote hosts. This leads to reduced log data volume and complexity, helping to control Sentinel and SIEM costs and lower overall TCO.
Logs can be transferred with zero message loss thanks to local disk buffering, client-side failover and application layer management. The Advanced Log Transfer Protocol ensures reliable log transfers with TLS for secure and encrypted transfers. To help with compliance challenges, syslog-ng has a mature LogStore system that enables encrypted, compressed and timestamped log storage suitable for short or long-term archival.
Filtering ingress data and controlling Sentinel costs
There are many ways to minimize Sentinel sticker shock. However, with so many pricing options, it can be hard to know you’re maximizing investment and ROI.
It’s also about implementing the right cost control measures: Filtering unnecessary logs, optimizing data connectors, limiting verbose logs, reducing white space, setting different retention settings for data types and using Azure services for data retention.
After all, you only really know how much Sentinel costs when you start using it. Of course, this is not likely to be enough for securing an effective budget. That’s why central log management with the likes of syslog-ng can play an essential role in starting from the right place, allowing you to filter log data locally and only send security-specific logs to Sentinel. The result is enterprise-grade central log management that covers and unifies the entire environment – without leading to sticker shock.
