---
cuppy_hub: gcp
cuppy_path: reference/messaging/eventarc.md
cuppy_section: docs
cuppy_doc: 513Q-8Q8R
cuppy_doc_uuid: 78b44f89-89d7-4036-b435-750aa0f9b560
cuppy_permalink: https://cuppy.io/gcp/d/513Q-8Q8R
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/messaging/eventarc
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: eb1f2fec65e894a345b1312222fa46e93d8ce8d2d8128bab6e84c436a1b46524
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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:

1. **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.
2. **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`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->