Programming | Python | Query

Introducing The New Cloud Storage Trigger In Eventarc

Eventarc now supports a new Cloud Storage trigger to receive events from Cloud Storage buckets! 

Wait a minute. Didn’t Eventarc already support receiving Cloud Storage events? You’re absolutely right! Eventarc has long supported Cloud Storage events via the Cloud Audit Logs trigger. However, the new Cloud Storage trigger has a number of advantages and it’s now the preferred way of receiving Cloud Storage events. Let’s take a look at the details.

As a recap, Eventarc has three types of triggers:

  1. Pub/Sub trigger to receive messages from new or existing Pub/Sub topics.
  2. Cloud Audit Logs trigger to receive Audit Logs from 100+ event sources. 
  3. Cloud Storage trigger (new) to receive events from Cloud Storage buckets.

Previously, the Audit Logs trigger was the only way to receive Cloud Storage events. 

Receiving Cloud Storage events with the Audit Logs trigger

Let’s look at an example that uses the old Audit Logs trigger approach. Here’s an Audit Logs trigger that gets created in the europe-west1 region. It triggers when a new object is created in a Cloud Storage bucket in europe-west1 and the event is routed to a Cloud Run service in us-central1:

gcloud eventarc triggers create trigger-hello-storage \
--destination-run-service=hello \
--destination-run-region=us-central1 \
--location=europe-west1 \
--event-filters="" \
--event-filters="" \
--event-filters="methodName=storage.objects.create" \

This works but it has the following problems:

  1. Audit Logs enablement: For the Audit Logs trigger to work, you need to enable Audit Logs for Cloud Storage. Many users forget to do this.
  2. Latency: There’s a delay between when you save a file, when the Audit Logs event gets generated, and when the Cloud Run service receives the event. 
  3. No filter by bucket in Audit Logs: You need to filter by bucket in your code instead.
  4. No dual-region or multi-region support: An Eventarc location can only be a single region or a special global region for all regions, whereas Cloud Storage supports bucket locations in single, dual, and multi regions. If you want to receive events from a multi-region bucket in the EU, you need to set the Eventarc location to global (since it’s not a single region). You will receive events from all regions and you’ll then need to filter by region in your code. 

Receiving Cloud Storage events with a Cloud Storage trigger

Here’s how you can receive object creation events from a Cloud Storage bucket in  europe-west1 with the new Cloud Storage trigger:

gcloud eventarc triggers create trigger-hello-storage \
--destination-run-service=hello \
--destination-run-region=us-central1 \
--location=europe-west1 \
--event-filters="" \
--event-filters="bucket=friction-log-single-region" \

It is not only simpler than the Audit Logs trigger but better in the following ways:

  1. No Audit Logs means there’s no need to enable them and therefore there is no latency due to Audit Logs. When you create a file in the bucket, you see that event in the Cloud Run service almost immediately.
  2. Filter by bucket is supported. You don’t need to filter by bucket in your code, and Eventarc can perform sanity checks on your bucket’s location against the Eventarc trigger location.
  3. Dual-region and multi-region locations are supported. When working with more than one region, you no longer need to specify a  global location and then filter by region in your code.

The new Cloud Storage trigger may be just what you’re looking for right now, or it might fill a need down the road. If you want to try it out, here are some resources:

Please reach out to me on Twitter @meteatamel for any questions or feedback.

By: Mete Atamel (Developer Advocate)
Source: Google Cloud Blog

For enquiries, product placements, sponsorships, and collaborations, connect with us at We'd love to hear from you!

Our humans need coffee too! Your support is highly appreciated, thank you!

Previous Article

Automate Application Migration With GKE Autopilot And Migrate For GKE

Next Article

Deploying The Cloud Spanner Emulator Locally

Related Posts