Forum Discussion

Deleted's avatar
Deleted
Oct 11, 2024

Understanding Data Ingestion for Log Analytics and Sentinel Workspace

I'm trying to understand how data ingestion works for both Log Analytics and Microsoft Sentinel. Every time we notice a spike in data ingestion costs for Log Analytics, we see a similar increase in Sentinel costs as well. It seems like data is being ingested into both workspaces, potentially doubling the ingestion and driving up our costs.

Can someone explain if this is expected behavior, or if there's a way to optimize and avoid duplicate data ingestion between Log Analytics and Sentinel?

1 Reply

  • iaadillatif's avatar
    iaadillatif
    Copper Contributor

    The data ingestion and cost spikes you observe between Microsoft Sentinel and Log Analytics are likely because Sentinel operates as a solution that runs on top of a Log Analytics workspace. Let's break this down:

    Understanding the Data Relationship

    1. Log Analytics Workspace:
      • This is the foundation where logs, metrics, and data from various sources are ingested and stored.
      • Costs are incurred based on the volume of data ingested and retained.
    2. Microsoft Sentinel:
      • Sentinel is a security information and event management (SIEM) and security orchestration automated response (SOAR) tool. It relies on data stored in a Log Analytics workspace.
      • When data is ingested into Log Analytics and used by Sentinel, Sentinel may also apply its own costs for analytics and threat detection queries.

    Key Insights on Cost Behavior

    • Shared Data Store: Sentinel does not maintain a separate workspace for data. All its data comes from the associated Log Analytics workspace.
      • The ingestion into Log Analytics incurs the base ingestion cost.
      • Sentinel’s additional costs stem from security-related features, such as rule processing, alerts, and threat intelligence queries.
    • Cost Spikes Observed: If your organization observes spikes in both Log Analytics and Sentinel ingestion costs, it usually indicates a significant increase in the volume of log data from sources like firewalls, servers, applications, etc.

    Ways to Optimize and Avoid Redundant Costs

    1. Control Data Volume:
      • Apply filters at the data source level to ensure that only relevant logs are sent to Log Analytics.
      • Use the DCR (Data Collection Rule) feature to fine-tune and filter data ingested into Azure Monitor.
    2. Manage Retention Settings:
      • Review and adjust the retention policies of your Log Analytics workspace. Longer retention periods increase costs.
      • Consider exporting older or less frequently queried data to cheaper storage like Azure Blob Storage.
    3. Identify Sentinel Costs Separately:
      • Analyze your billing report to break down costs associated with Log Analytics ingestion versus Sentinel's added services.
    4. Use Sentinel’s Capabilities Judiciously:
      • Evaluate which Sentinel features (custom rules, analytics queries) are actively needed and optimize those processes.
    5. Leverage Sentinel Data Tables:
      • Some Sentinel features come with built-in tables that already correlate data for security analytics. Use these instead of duplicating the data across multiple queries.

    Recommendation

    Examine the logs and ingestion paths thoroughly using Azure Cost Management + Billing tools. You can also use the Azure Monitor pricing calculator to simulate cost adjustments. Additionally, consult Microsoft’s best practices for Azure Monitor and Sentinel workspace design to avoid unnecessary duplication.

    Let me know if you'd like more details on any of these steps!

Resources