/amazon-eventbridge-event-bus

name: amazon-eventbridge-event-bus
description: Builds, runs, debugs, and operates event-driven applications using EventBridge Event Bus - a managed, centrally governed publish/subscribe event bus that an organization can share across many teams and accounts. Applicable when workloads need event-driven architectures, decoupling, choreography, asynchronous integration, pub/sub, fan-out, event ordering, delivered in sequence, event router, event broker, event bus, event store, event retention, event replay, deduplication, avro, protobuf, cloudevents, uses events or messages. Designed as a centrally managed event bus platform allowing governance and control - such as subscriber control, revocation, per-account throttling - while giving application owners flexibility across an organization spanning multiple accounts, with end-to-end open-standards observability and cost allocation. Also helps reduce costs in high fan-out scenarios where multi-account forwarding adds cost. A serverless, managed alternative to self-managed event streaming platforms.
version: 2

Building with the new EventBridge custom event buses

Overview

The new EventBridge custom event bus routes events and retains them. You publish with one of two APIs, and subscribers filter, optionally transform, and deliver each matching event to one target.

**Read chapters 5 and 6 before writing any filter, transformer, or target parameter.** The two publish APIs deliver different payload shapes, and an expression written for one silently matches nothing against the other.

Publish metrics are on by default, so you can always tell whether events reached a bus. Subscriber logs are **off** by default, so turn them on before you debug a delivery rather than after (chapter 18).

**Works best with** the [AWS MCP server](https://docs.aws.amazon.com/aws-mcp/), which is recommended for running the CLI calls in this skill: it executes them in a sandboxed environment with audit logging. All guidance also works with standard AWS CLI access.

Conventions

The key words **MUST**, **MUST NOT**, **SHOULD**, and **MAY** in this skill are to be interpreted as described in RFC 2119. They appear only in decision procedures, where following the wrong course either breaks the configuration or loses events silently. **MUST** marks an absolute requirement, **SHOULD** a strong recommendation you may have a specific reason to set aside, and **MAY** a genuine option.

Everything else is ordinary description. A sentence stating how the service behaves carries no keyword, because it is a fact rather than an instruction to you.

When not to use this skill

This skill is only about the new custom event buses, the service you reach with the `eventsv2` CLI and the `eventbridgev2` SDK clients. It does not cover:

• **Classic EventBridge**, meaning the `events` API with rules, targets, archives, and event patterns on

`AWS::Events::Rule`. The two services share the `events:` IAM namespace and some vocabulary, which is exactly why they are easy to confuse. If you are writing a rule, you are not on a new bus. Chapter 3 maps the concepts across if you are migrating.

• **EventBridge Pipes, Scheduler, and Schemas** (the classic schema registry and its discovery feature).

Different APIs.

• **Configuring the Firehose service itself**, such as buffering hints or record transformation. A

Firehose delivery stream is a valid subscriber target; chapter 9 covers that side of it.

Trigger examples

1. "Write a filter so this subscriber only gets orders over $500." 2. "My producer says PUBLISHED but nothing shows up in the queue. What do I check?" 3. "Should I use PutEvents or PutRawEvents for Protobuf payloads?" 4. "Set up a subscriber that reprocesses everything from the last two days." 5. "Write a JSONata expression that pulls the customer id out of the event into a DynamoDB putItem."

Guardrail — where this skill's own files live (MCP vs local install)

This skill can be loaded two ways, and they resolve the skill's own bundled files from different places. Determine how the skill was loaded before reading a reference:

• **Loaded through the AWS MCP `retrieve_skill` tool:** The skill is not

installed on the local filesystem. You MUST fetch each reference via `retrieve_skill` with the `file` parameter (e.g. `file="references/setup-walkthroughs.md"`). Do NOT `file_read` these paths locally — they do not exist on disk.

• **Installed locally** (e.g. `.kiro/skills/amazon-eventbridge-event-bus/` or

`~/.claude/skills/amazon-eventbridge-event-bus/`): Read files from the local skill directory using relative paths.

This distinction applies only to the skill's own packaged files. User data and session artifacts are always read from and written to the user's working directory. Never fetch or write customer data through `retrieve_skill`.

Reference files

The chapters below carry the decisions and the failure modes; the detail lives in these files. Load a file when the task matches its row, and do not load them all by default.

| File | When to load | |---|---| | [setup-walkthroughs.md](references/setup-walkthroughs.md) | standing up a working bus end to end, in one account or shared across accounts with AWS RAM, including prerequisites and teardown | | [code-samples.md](references/code-samples.md) | writing an individual CLI or SDK call (Python, Java, TypeScript): create a bus and subscriber, publish with either API, binary payloads, replay, cross-account grants, waiters, per-entry results, throttling backoff | | [filters-and-expressions.md](references/filters-and-expressions.md) | writing any filter pattern, JSONata expression, or target parameter that reads the event; both delivered envelopes in full | | [target-configuration.md](references/target-configuration.md) | configuring any subscriber target, especially a universal target | | [target-contract.md](references/target-contract.md) | writing an actual `CreateSubscriber` call: required