Eventarc

Eventarc is the event router that ties the rest of this chapter together. It turns events from 90+ Google Cloud sources — Cloud Storage object created, BigQuery job finished, a Cloud Audit Log entry, a Pub/Sub message on a topic — into invocations of your Cloud Run, Cloud Functions, GKE, or Cloud Workflows workloads. Under the hood Eventarc rides on Pub/Sub, but it abstracts away the per-source plumbing and delivers events in the standard CloudEvents format.

The case for Eventarc is the case for an event router in general: instead of every service writing custom code to subscribe to and parse every source it cares about, one trigger declares the source-destination wiring and the platform delivers the right events to the right handler. The reduction in glue code is large.

Event-Driven Architecture on GCP

Eventarc is the practical entry point for event-driven architecture on Google Cloud. A trigger has three parts: a source (which service produces the event), filters (which subset of events from that source qualify), and a destination (which service receives the matched event). Once a trigger is in place, the workload runs on every matching event automatically — no polling, no manual Pub/Sub subscription setup per source, no parsing of provider-specific event formats.

Trigger Sources and Destinations

Eventarc ships in two editions. Eventarc Standard — the trigger model this page describes — supports two source categories: direct sources (Cloud Storage, Firestore, BigQuery, Cloud Build, Pub/Sub, third-party SaaS providers, and a handful of others — each emits its own native events to Eventarc), and Cloud Audit Logs sources (any service that writes to audit logs — effectively all of Google Cloud — can trigger events on log entries matching specific service names and method names). Eventarc Advanced adds a central message bus with enrollments, pipelines, event transformation, and a Publish API for ingesting custom and third-party events.

Destinations: Cloud Run services (HTTP receivers, most common), Cloud Functions (one-function handlers), GKE workloads (via the GKE Eventarc add-on), and Cloud Workflows (kick off an orchestration on every matching event).

CloudEvents Format

Eventarc delivers events in the CloudEvents format — a CNCF specification that wraps every event in a standard envelope (type, source, time, id, subject) plus a data payload specific to the source. Handlers parse the envelope the same way regardless of which service produced the event; only the data payload varies. This is what makes one handler able to react to events from many sources without rewriting parsing logic for each.

Filtering and Routing

Triggers support filters on event attributes — bucket name for Cloud Storage events, dataset for BigQuery events, method name for audit log events. Apply filters as tightly as possible. Without them, the handler receives every event from the source, must check whether each one is relevant, and pays the runtime and cost for events it ultimately ignores. A trigger that fires on "object created in this specific bucket with this specific prefix" is almost always what you actually want.

Eventarc vs Direct Pub/Sub

If only one source is involved and that source already publishes to Pub/Sub directly (Cloud Build, Cloud Scheduler, Firestore in some modes), a plain Pub/Sub subscription is the lighter-weight choice. Eventarc earns its place when you have multiple sources, want the CloudEvents abstraction, need audit-log triggers, or want destinations other than Pub/Sub-subscribers. For a single-source single-destination wiring with no filter complexity, Pub/Sub is fine. For everything more complex, Eventarc.