Eventarc — CloudEvents from Google Cloud itself, the two editions, and the destinations it can reach
How something that happens in Google Cloud triggers something you wrote. The CloudEvents format, the four source categories including Cloud Audit Logs, the six destination types, and the object-model difference between the Standard and Advanced editions.
markdownreferencev1513Q-8Q8Rstage: designtrust: officialfamily: messagingservice: eventarcinterface: anyeventarcCloudEventstriggerbuspipelinechannelCloud Audit Logseventarc advancedeventarc standardcloud run destinationworkflowsGKE serviceHTTP endpoint
Eventarc
1. What it is
a "fully managed eventing solution that lets you asynchronously route messages from sources to targets using loosely coupled services."
Events travel as CloudEvents, which is an open specification rather than a Google format — so a consumer written for CloudEvents elsewhere understands these.
2. Where events come from
| Source category | Note |
|---|---|
| Google Cloud services publishing directly | through the publishing API |
| Cloud Audit Logs | the broad one. Nearly anything that is audited becomes an event |
| Google providers | |
| third-party services |
The Cloud Audit Logs route is the important one. It is what makes "when a bucket changes", "when an IAM policy changes", "when a VM is created" into triggers without the service needing its own event integration. The compute family's figure makes the scale concrete: Cloud Run functions support "any event type supported by Eventarc, including 90+ event sources through Cloud Audit Logs", where 1st gen functions had 7 direct sources.
3. Where events go
Cloud Run (functions, services and jobs) · Pub/Sub topics · Workflows · HTTP endpoints, in a VPC or public · GKE services · Eventarc Advanced buses.
Two of those are worth pausing on: a Cloud Run job as a destination means an event can start a batch run directly, and a VPC HTTP endpoint means a private internal service can be a target without being exposed.
4. Two editions, two object models
| Edition | Objects | For |
|---|---|---|
| Standard | triggers | one provider to one destination. The straightforward case |
| Advanced | bus and pipelines | multi-source, multi-destination routing, with message transformation, filtering and schema conversion |
Channels appear implicitly in routing.
Choose on the shape of the routing, not on scale. If the requirement includes transforming or converting a message between a source and a destination, that is Advanced, and it is a different object model to build against — not a quota increase.
5. For a migration estimate
Eventarc's counterpart is Amazon EventBridge and Azure Event Grid. The mapping tables pair Pub/Sub with Event Grid, which is a reasonable name match and the wrong layer: Event Grid's routing of platform events is Eventarc's job, and Pub/Sub is the message transport underneath.
Two estimate-bearing readings:
- The Cloud Audit Logs source is the cheapest breadth in the family. A design that needed a custom
watcher per service on another cloud may need none here. Look for those watchers in the source inventory.
- Eventarc Advanced's transformation and filtering compete with a running transformation service. If the
source estate has a Lambda or Function whose only job is reshaping an event between two systems, Advanced may delete it. That is a component removed, not a cost moved.
See guides/parity/messaging.md.