Azure Firewall log ingestion – Blob Storage update behavior and alternative ingestion options

Question

Azure Firewall log ingestion – Blob Storage update behavior and alternative ingestion options

Balamurugan, Susinthika 60

Hi Microsoft Team,

We are currently evaluating Azure Blob Storage as an ingestion method for Azure Firewall logs and would like some clarification regarding the blob creation/update behavior and the available alternatives.

1. Azure Firewall logs written to Blob Storage

We understand that Azure Firewall diagnostic logs written to Blob Storage are organized into hourly PT1H.json blobs, and that during the current hour, events are appended to the same PT1H.json blob as they are received.

Could you please confirm the following:

Once a PT1H.json blob is created for an hour, will the same blob continue to be updated/appended throughout that hour?
After the hour is completed, is that blob finalized and no longer updated, with a new PT1H.json blob being created for the next hour?
When new events are appended to an existing PT1H.json blob during the same hour, does Azure Blob Storage generate an Event Grid event/notification for that update?
If so, which Event Grid event type is generated, and can it reliably be used to detect new data appended to the existing hourly blob?
Is there an Azure-supported mechanism to identify when the current hourly blob has received new data or when the blob is ready to be consumed?

We are particularly interested in understanding this behavior because an ingestion consumer needs to avoid reading the hourly blob while it is still being updated and ensure that all events for the hour are eventually processed.

2. Alternative ingestion methods

If Blob Storage is not the recommended approach for this use case, could you please confirm whether Azure Firewall logs can be forwarded/ingested through any of the following mechanisms instead?

Event Hubs
Azure Storage Queues
An Azure Firewall API or other supported API-based ingestion method
Any other Azure-supported mechanism that would allow us to reliably consume Azure Firewall logs incrementally

For each applicable option, could you please provide the relevant Microsoft documentation describing how Azure Firewall logs can be configured to use that destination and any relevant limitations or considerations?

In particular, we would appreciate guidance on which approach Microsoft recommends when the requirement is to reliably consume Azure Firewall logs as they become available, without missing or partially reading events from the hourly Blob Storage files.

Thank you.

Balamurugan, Susinthika 60 Reputation points

2026-09-11T05:51:22.8633333+00:00

Hi Microsoft Team,

Just following up on this question. We would appreciate clarification from the Azure team on the behavior of PT1H.json blobs, specifically whether updates/appends to an existing hourly blob generate Event Grid notifications that can reliably be used to detect newly appended data.

We are currently evaluating the Azure Firewall → Blob Storage ingestion approach, so confirmation of the supported behavior and any recommended alternative would help us proceed with the implementation.

Thank you!

1 answer

Your answer

Balamurugan, Susinthika 60 Reputation points

2026-09-11T05:51:22.8633333+00:00

Hi Microsoft Team,

Just following up on this question. We would appreciate clarification from the Azure team on the behavior of PT1H.json blobs, specifically whether updates/appends to an existing hourly blob generate Event Grid notifications that can reliably be used to detect newly appended data.

We are currently evaluating the Azure Firewall → Blob Storage ingestion approach, so confirmation of the supported behavior and any recommended alternative would help us proceed with the implementation.

Thank you!

Answer 1

Hello @Balamurugan, Susinthika

Yes, your understanding of the basic PT1H.json behavior is correct, but there is an important detail if you're building an ingestion pipeline around it.

When Azure Monitor resource logs are archived to Storage, they're organized into hourly PT1H.json blobs. During the current hour, Azure Monitor appends events to that blob as they're received.

However, don't assume that the previous hour's blob becomes immutable exactly at the hour boundary. When a new hour begins, existing logs can still be written to the previous hour's blob while new logs are also being written to the current hour's blob. Logs are organized by when Azure Monitor receives them, not necessarily when the underlying event occurred.

That means an ingestion process such as:

10:00 -10:59 → PT1H.json

11:00 → read 10:00 PT1H.json once

11:01 → consider it complete

Isn't something I'd rely on for guaranteed ingestion.

Regarding Event Grid, Blob Storage supports events when blobs are created/replaced/deleted through supported Blob APIs, but I don't see any documentation of an Azure Monitor-specific contract guaranteeing that each incremental write to an Azure Monitor PT1H.json blob produces an Event Grid notification you can use as a reliable per-record ingestion signal.

So don't build the consumer around Event Grid notifications from these hourly archive blobs unless Microsoft explicitly confirms that behavior for Azure Monitor diagnostic-log writes.

For your second requirement: consuming Azure Firewall logs incrementally as they become available, Event Hubs is the better fit.

Azure Firewall diagnostic settings support sending logs to:

Log Analytics
Azure Storage
Event Hubs

Event Hubs is a supported Azure Firewall diagnostic destination.

Architecturally, use:

User's image

rather than:

User's image

Event Hubs removes the need to determine when an hourly blob is "complete." Your consumer can process the resource-log events as they're delivered and maintain its progress using the Event Hub consumer offset/checkpoint.

Azure Storage Queues aren't a direct Azure Firewall diagnostic-setting destination, and there isn't a dedicated Azure Firewall log API that I'd use as a replacement for the diagnostic pipeline. If you need a queue downstream, you could consume from Event Hubs and then publish the processed messages to your queue.

You can also configure multiple diagnostic settings/destinations if you need both real-time consumption and archival. For example:

User's image

That would probably be my choice here: Event Hubs for ingestion, Blob Storage for retention/archive.

References:

Azure Monitor resource logs – Storage and PT1H.json behavior

Secure Azure Firewall – diagnostic logging destinations

Azure Blob Storage events with Event Grid

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.