AzureFeeds

A common question from customers is whether Azure Firewall supports filtering or selecting which logs are sent to a Log Analytics workspace. This concern usually stems from the high cost of storing large volumes of data — especially in environments where the firewall inspects substantial amounts of network traffic.

Azure Firewall now supports ingestion-time transformation of logs in Azure Log Analytics. This capability introduces selective and advanced filtering, giving customers more control over what data is collected and analyzed.

In this blog post, we’ll explore a major new capability: Azure Firewall now supports ingestion-time transformations in Log Analytics — enabling flexible, cost-efficient logging through selective data collection.

Why does it matter?

For many enterprise customers, the cost of ingesting Azure Firewall logs into Log Analytics — especially at scale — can be significant. Depending on the logging mode (Basic or Analytics), ingestion costs can be substantial, potentially making it challenging to expand logging coverage across additional workloads.

With ingestion-time transformations, users can filter logs by rows, columns, timestamps, and more — and apply transformations before ingestion. This ensures that only relevant and critical data is stored, helping reduce costs while retaining the necessary telemetry for analysis, threat detection, and compliance.

Customer benefits

• Security monitoring: Log only suspicious traffic for more targeted threat detection.


• Cost optimization: Avoid ingesting and storing unnecessary data.


• Compliance: Use DCR (data collection rules) to filter and route logs to meet audit/reporting needs.


• Incident response: Focus on logs that matter, accelerating investigation time.


• Custom alerts: Build insights on top of curated, high-value logs.

What are transformations in Azure Monitor?

Ingestion-time transformations in Azure Monitor allow you to filter or modify incoming telemetry before it reaches your Log Analytics workspace. This happens in the cloud pipeline — after the data source (such as Azure Firewall) sends its logs, but before those logs are ingested and stored.

Transformations are defined using DCR and written in Kusto Query Language (KQL). Each transformation runs against incoming records individually, letting you precisely control what gets stored – and what doesn’t.

For example, you might collect only entries where the action column contains the word “deny”. That filter can be applied at ingestion time, so only those critical logs are stored.

The diagram below shows how this works end-to-end, from data source to filtered ingestion.

To learn more and estimate potential processing charges, refer to the official documentation.

Transforming Azure Firewall logging

In this section, we’ll walk through a few real-world use cases shared by customers — including how to create a DCR based on specific filtering criteria.

Important: Ingestion-time transformations for Azure Firewall logs are supported only when using resource-specific logs. If you’re using legacy diagnostic settings, this capability is not available. To enable transformations, ensure your firewall is configured to send logs using the Azure Firewall resource-specific log schema.

First, navigate to your Log Analytics workspace and locate the table where your Azure Firewall logs are stored (e.g., AZFWApplicationRule). Click the three-dot menu (…) on the right and select “Create transformation”.

Creating a transformation is a 3 steps-process.

• Step 1 – Basics: Create a DCR to define how incoming data is processed and specify where it should be stored.


• Step 2 – Schema and transformation: Use the Transformation Editor to write a KQL query that filters the incoming data based on your criteria.


• Step 3 – Review: Review the table name, DCR name, and KQL query before clicking “Create”. This summary ensures everything is configured correctly.

For more information on how to create a DCR, refer to the official documentation.

Use case 1: Excluding alerts from low priority IDPS signatures

This DCR transformation filters and reshapes incoming Azure Firewall IDPS logs before they’re ingested into a Log Analytics workspace.

source
| where Action !contains “alert” and Severity != 3
| project TimeGenerated, Protocol, SourceIp, SourcePort, DestinationIp, DestinationPort, Action, SignatureId, Description, Severity

Here’s a breakdown of what it does:

1. source: This refers to the incoming data stream — in this case, the AZFWIdpsSignature table (intrusion detection/prevention logs from Azure Firewall).


2. | where Action !contains “alert” and Severity != 3: This line filters out any log entries where the Action contains “alert” (non-blocking detection events). Any entries where Severity equals 3 (which represents low severity events).
   
   The result: We’re keeping only more actionable or higher-severity entries that don’t just raise alerts but may involve blocks or higher-severity behaviors (e.g., deny actions, critical or warning severities).

3. | project …: The project statement selects and forwards only the specified columns to the Log Analytics workspace.

When you run a query in your Log Analytics workspace, you’ll notice that only the specific columns defined in your transformation’s project statement are available — and they appear in the exact order specified in the query.

Use case 2: Filtering out unnecessary logs (trusted or testing networks)

This DCR transformation filters out log entries from specific source IP address ranges before they’re ingested into Azure Monitor. In this scenario, the 10.0.200.x and 10.0.300.x ranges might represent trusted or test network segments that generate high volumes of traffic — traffic that don’t need to be logged. By excluding these IPs at ingestion time, you can significantly reduce unnecessary log volume and associated costs.

source
| where not(
SourceIp startswith “10.0.200.” or
SourceIp startswith “10.0.300.”
)
| project TimeGenerated, Protocol, SourceIp, SourcePort, DestinationIp, DestinationPort, Action, ActionReason, Policy, RuleCollection, Rule

Here’s a breakdown of what it does:

1. source: This refers to the incoming data stream — in this case, the AZFWNetworkRule table.


2. | where not (…): Applies a filter to exclude logs that match the criteria inside.


3. SourceIp startswith “10.0.200.” and SourceIp startswith “10.0.300.”: These conditions match any log where the SourceIp address falls within the 10.0.200.0/24 or 10.0.300.0/24 subnets (i.e., IPs like 10.0.200.1, 10.0.200.45, etc.).


4. | project …: The project statement selects and forwards only the specified columns to the Log Analytics workspace.

Conclusion

By leveraging ingestion-time transformations through DCR, organizations gain full control over which Azure Firewall logs are ingested in Log Analytics. This selective logging capability helps reduce noise, cut costs, and retain only high-value data for security, compliance, and operational insights. As Azure Firewall evolves these enhancements offer greater flexibility and efficiency for managing cloud-native network telemetry.

Resources

• Azure updates | Microsoft Azure


• Monitoring data reference for Azure Firewall | Microsoft Learn


• Transformations Azure Monitor – Azure Monitor | Microsoft Learn


• Create a transformation in Azure Monitor – Azure Monitor | Microsoft Learn