EventBridge (Event Router)

Amazon EventBridge is a serverless event bus. Events are published to a bus, rules match them against JSON patterns, and matching events are pushed to targets. There is no polling, no infrastructure to run, and no retention: an event is routed and forgotten unless an archive is configured.

Key features

Event routing

Events flow from AWS services, SaaS applications and custom applications to targets such as Lambda functions, SQS queues, SNS topics, Step Functions state machines and HTTP endpoints. The maximum size of a single event is 256 KB. The rate at which an account can call PutEvents is a per-Region quota — 10,000 per second in US East (N. Virginia), US West (Oregon) and Europe (Ireland), 1,200 in Europe (London), and 400 in many other Regions — and can be raised in the Service Quotas console.

Serverless operation

EventBridge is fully managed, scales with event volume, and is billed per event published. Events delivered from AWS services to the default bus are not charged.

Event pattern matching

Rules filter on the content of the event using JSON patterns: exact values, prefix and suffix matching, numeric and IP address ranges, exists checks, and negation. A rule must specify an event pattern, a schedule expression, or both.

Target management

A rule can have up to five targets, and that limit cannot be raised. Targets include most AWS services, plus API destinations for calling external HTTP endpoints with managed authentication. Each target carries its own retry policy and, optionally, its own dead-letter queue.

Event buses

Every account has a default event bus, which is where events from AWS services arrive. Custom buses are created per application or domain; partner buses receive events from SaaS providers. Access to a bus is granted with a resource-based policy.

There is no single right number of buses. Events emitted by AWS services can only land on the default bus, so rules that react to infrastructure events belong there. Application events are usually better on one custom bus per bounded context or per domain: a bus is the unit of access control, of archiving, and of the PutEvents and rule quotas, so separating domains keeps one noisy application from consuming another’s quota and keeps cross-account grants narrow.

Schema registry

The schema registry infers schemas from events flowing through a bus, versions them, and generates code bindings for common languages. It also accepts OpenAPI schemas directly.

Integration surface

EventBridge integrates natively with a large catalogue of AWS services as event sources and targets, with SaaS partners such as Zendesk and Datadog, and with anything reachable over HTTP through API destinations. Rules and targets are fully expressible in CloudFormation and other infrastructure-as-code tools.

Cross-account and cross-Region

A bus in one account can be a target of a rule in another, so events can be shared across an organisation with resource-based permissions controlling who may publish and who may subscribe.

Common use cases

• Communication between microservices
• Application monitoring and alerting
• Scheduled and event-triggered workflow automation
• SaaS integration
• Audit and compliance tracking
• IoT data processing and real-time analytics triggers

Delivery of events

EventBridge attempts to deliver a matched event to each target. The target can reject the event or fail to process it — a Lambda function throws, an API endpoint returns an error, a state machine fails to start. By default EventBridge retries a failed delivery for up to 24 hours; a target’s retry policy can shorten that with MaximumRetryAttempts and MaximumEventAgeInSeconds.

Some failures are not retried at all. If the target no longer exists, or EventBridge lacks permission to invoke it, the event goes straight to the dead-letter queue — or is dropped if there is none.

Error handling

A dead-letter queue is configured per target, not per rule, and must be a standard SQS queue. The retry policy sits alongside it in the same target entry:

EventRule:
  Type: AWS::Events::Rule
  Properties:
    Description: Route EC2 state changes to a Lambda function
    EventPattern:
      source:
        - aws.ec2
      detail-type:
        - EC2 Instance State-change Notification
    State: ENABLED
    Targets:
      - Id: MyLambdaTarget
        Arn: !GetAtt MyLambda.Arn
        RetryPolicy:
          MaximumRetryAttempts: 3
          MaximumEventAgeInSeconds: 3600
        DeadLetterConfig:
          Arn: !GetAtt DLQueue.Arn

Messages that land in the dead-letter queue carry the rule ARN, the target ARN, an error code and the retry condition that was exhausted, which is usually enough to tell a permissions problem from a failing target. EventBridge also publishes InvocationsSentToDLQ and InvocationsFailedToBeSentToDLQ to CloudWatch.

The queue needs a resource policy allowing events.amazonaws.com to call sqs:SendMessage on it. The console adds that policy when a dead-letter queue is selected there; a template or API call has to include it.

Practices worth adopting

• Configure a dead-letter queue for every target carrying events that matter.
• Make target processing idempotent — EventBridge delivers at least once, so a target can see the same event twice.
• Alarm on FailedInvocations and on the depth of each dead-letter queue.
• Set retry policies to match the target: a short maximum event age for events that lose their value quickly, a longer one for work that can wait.
• Write rules that cannot re-trigger themselves. A rule that reacts to a change and then makes the same kind of change will loop, and the bill grows quickly.