Reacting to Blob storage events

Azure Storage events allow applications to react to events, such as the creation and deletion of blobs, by using modern serverless architectures. It does so without the need for complicated code or expensive and inefficient polling services.

Instead, events are pushed through Azure Event Grid to subscribers such as Azure Functions, Azure Logic Apps, or even to your own custom http listener, and you only pay for what you use.

Blob storage events are reliably sent to the Event Grid service which provides reliable delivery services to your applications through rich retry policies and dead-letter delivery.

Common Blob storage event scenarios include image or video processing, search indexing, or any file-oriented workflow. Asynchronous file uploads are a great fit for events. When changes are infrequent, but your scenario requires immediate responsiveness, event-based architecture can be especially efficient.

If you want to try this out now, see any of these quickstart articles:

If you want to use this tool: See this article:
Azure Portal Quickstart: Route Blob storage events to web endpoint with the Azure portal
Azure CLI Quickstart: Route storage events to web endpoint with PowerShell
Powershell Quickstart: Route storage events to web endpoint with Azure CLI

The event model

Event Grid uses event subscriptions to route event messages to subscribers. This image illustrates the relationship between event publishers, event subscriptions, and event handlers.

Event Grid Model

First, subscribe an endpoint to an event. Then, when an event is triggered, the Event Grid service will send data about that event to the endpoint.

See the Blob storage events schema article to view:

  • A complete list of Blob storage events and how each event is triggered.
  • An example of the data the Event Grid would send for each of these events.
  • The purpose of each key value pair that appears in the data.

Filtering events

Blob event subscriptions can be filtered based on the event type and by the container name and blob name of the object that was created or deleted. Filters can be applied to event subscriptions either during the creation of the event subscription or at a later time. Subject filters in Event Grid work based on "begins with" and "ends with" matches, so that events with a matching subject are delivered to the subscriber.

To learn more about how to apply filters, see Filter events for Event Grid.

The subject of Blob storage events uses the format:

/blobServices/default/containers/<containername>/blobs/<blobname>

To match all events for a storage account, you can leave the subject filters empty.

To match events from blobs created in a set of containers sharing a prefix, use a subjectBeginsWith filter like:

/blobServices/default/containers/containerprefix

To match events from blobs created in specific container, use a subjectBeginsWith filter like:

/blobServices/default/containers/containername/

To match events from blobs created in specific container sharing a blob name prefix, use a subjectBeginsWith filter like:

/blobServices/default/containers/containername/blobs/blobprefix

To match events from blobs created in specific container sharing a blob suffix, use a subjectEndsWith filter like ".log" or ".jpg". For more information, see Event Grid Concepts.

Practices for consuming events

Applications that handle Blob storage events should follow a few recommended practices:

  • As multiple subscriptions can be configured to route events to the same event handler, it is important not to assume events are from a particular source, but to check the topic of the message to ensure that it comes from the storage account you are expecting.
  • Similarly, check that the eventType is one you are prepared to process, and do not assume that all events you receive will be the types you expect.
  • As messages can arrive out of order and after some delay, use the etag fields to understand if your information about objects is still up-to-date. Also, use the sequencer fields to understand the order of events on any particular object.
  • Use the blobType field to understand what type of operations are allowed on the blob, and which client library types you should use to access the blob. Valid values are either BlockBlob or PageBlob.
  • Use the url field with the CloudBlockBlob and CloudAppendBlob constructors to access the blob.
  • Ignore fields you don't understand. This practice will help keep you resilient to new features that might be added in the future.
  • If you want to ensure that the Microsoft.Storage.BlobCreated event is triggered only when a Block Blob is completely committed, filter the event for the CopyBlob, PutBlob, PutBlockList or FlushWithClose REST API calls. These API calls trigger the Microsoft.Storage.BlobCreated event only after data is fully committed to a Block Blob. To learn how to create a filter, see Filter events for Event Grid.

Next steps

Learn more about Event Grid and give Blob storage events a try: