Jonatan Matajonmatum.com
conceptsnotesexperimentsessays
© 2026 Jonatan Mata. All rights reserved.v2.1.1
Concepts

AWS EventBridge

AWS serverless event bus connecting applications using events, enabling decoupled event-driven architectures with rule-based routing.

evergreen#aws#eventbridge#events#serverless#event-driven#integration

What it is

Amazon EventBridge is a fully managed serverless event bus that facilitates building scalable, decoupled event-driven architectures. It acts as an intelligent intermediary that receives events from multiple sources — AWS services, custom applications, and dozens of native SaaS integrations — and routes them to specific destinations based on sophisticated content-based rules.

Unlike traditional messaging systems that require queue or topic configuration, EventBridge uses declarative event patterns that enable granular filtering without additional code. Events are processed asynchronously with delivery guarantees and automatic retry capabilities, eliminating the need to manage messaging infrastructure.

EventBridge integrates natively with the AWS ecosystem and provides a Schema Registry that auto-discovers and versions event structures, facilitating contract evolution between services in microservices architectures.

Core components

ComponentFunctionUse cases
Event BusLogical channel that receives and distributes eventsDefault bus for AWS services, custom buses per business domain
RulesDeclarative filters based on event contentRouting by source, detail-type, or specific payload fields
TargetsDestinations that process filtered eventsLambda, SQS, SNS, Step Functions, API destinations
Schema RegistryVersioned catalog of event structuresAuto-discovery, validation, code generation
EventBridge PipesPoint-to-point connections with transformationStreaming from DynamoDB, Kinesis, SQS with filtering and enrichment

Production event patterns

{
  "version": "0",
  "id": "7bf73129-1428-4cd3-a780-95db273d1602",
  "detail-type": "Order Status Changed",
  "source": "ecommerce.orders",
  "account": "123456789012",
  "time": "2024-03-19T10:30:00Z",
  "region": "us-east-1",
  "detail": {
    "orderId": "order-12345",
    "previousStatus": "processing",
    "currentStatus": "shipped",
    "customerId": "cust-67890",
    "amount": 149.99,
    "items": [
      {
        "sku": "PROD-001",
        "quantity": 2,
        "price": 74.99
      }
    ]
  }
}

Advanced filtering rule

{
  "source": ["ecommerce.orders"],
  "detail-type": ["Order Status Changed"],
  "detail": {
    "currentStatus": ["shipped", "delivered"],
    "amount": [{"numeric": [">", 100]}],
    "customerId": [{"exists": true}]
  }
}

EventBridge Pipes vs Rules

EventBridge Pipes introduce a point-to-point integration model that complements the traditional pub/sub model of EventBridge Rules:

AspectEventBridge RulesEventBridge Pipes
ModelPub/sub (1:N)Point-to-point (1:1)
SourcesEvent buses, scheduled eventsDynamoDB Streams, Kinesis, SQS, MSK
TransformationLimited (input transformer)Complete (filtering, mapping, enrichment)
Use casesFan-out, notificationsETL, streaming analytics, synchronization
CostPer event processedPer pipe + events processed

Event archive and replay

EventBridge provides native archive and replay capabilities that are critical for production systems:

  • Archive: Automatically stores events for a configurable retention period (indefinite by default)
  • Replay: Re-processes historical events to specific targets
  • Use cases: Debugging, testing with real data, failure recovery, retrospective analysis
# Create archive for order events
aws events put-archive \
  --archive-name orders-archive \
  --event-source-arn arn:aws:events:us-east-1:123456789012:event-bus/orders-bus \
  --retention-days 365
 
# Replay events from last month
aws events start-replay \
  --replay-name orders-replay-march \
  --event-source-arn arn:aws:events:us-east-1:123456789012:archive/orders-archive \
  --event-start-time 2024-03-01T00:00:00Z \
  --event-end-time 2024-03-31T23:59:59Z

Decision: EventBridge vs SQS vs SNS

CriteriaEventBridgeAmazon SQSAmazon SNS
RoutingContent-based with complex patternsQueue-based, optional FIFOTopic-based, simple fan-out
SaaS integrationsDozens of native (Shopify, Zendesk, etc.)No native integrationsNo native integrations
Schema managementIntegrated registry with versioningNo native supportNo native support
TransformationInput transformer + PipesNoneNone
Cost$1 per million events$0.40 per million requests$0.50 per million requests
LatencySecondsMillisecondsMilliseconds
Ideal casesEvent-driven architecture, integrationsDecoupling, work queuesNotifications, alerts

Decision framework

Use EventBridge when:

  • You need content-based event routing
  • Integrating multiple AWS services and SaaS
  • You require schema registry and versioning
  • Building complex event-driven architectures
  • Second-level latency is acceptable

Use SQS when:

  • You need strict FIFO guarantees
  • You require sub-second latency
  • Implementing work queues or task processing
  • Cost per message is critical

Use SNS when:

  • Implementing simple notifications
  • You need basic fan-out without filtering
  • Integrating with email, SMS, or mobile push
  • You require minimal latency

Observability integration

EventBridge integrates natively with CloudWatch and AWS X-Ray to provide complete visibility:

  • Rule metrics: Invocations, MatchedEvents, FailedInvocations — monitor event processing volume and detect target failures
  • Delivery metrics: InvocationsSentToDeadLetterQueue, ThrottledRules — identify undelivered events and throttling
  • X-Ray tracing: End-to-end tracing of event flow from source to final target

Common anti-patterns

  • Single event bus: Using the default bus for all domains reduces isolation and complicates governance
  • Synchronous events: EventBridge is asynchronous; don't use for cases requiring immediate response
  • Large payloads: 256KB limit; use S3 for large data and reference in event
  • Over-filtering: Overly specific rules create coupling; prefer filtering in targets when possible

Why it matters

EventBridge represents a fundamental shift toward serverless event-driven architectures that scale automatically and reduce operational coupling. For engineering teams, it eliminates the complexity of managing message brokers while providing advanced capabilities like schema registry, declarative transformations, and native SaaS integrations. The archive and replay capability is especially valuable for critical systems where event auditability and recovery are business requirements. The per-processed-event pricing model aligns costs with generated value, making incremental adoption viable in existing systems.

References

  • Amazon EventBridge User Guide — AWS, 2024. Complete official documentation.
  • EventBridge Event Patterns — AWS, 2024. Filtering pattern syntax and examples.
  • EventBridge Pipes Documentation — AWS, 2024. Point-to-point integration guide.
  • Serverless Land EventBridge Patterns — AWS, 2024. Collection of architectural patterns.
  • EventBridge Schema Registry — AWS, 2024. Schema management and versioning.
  • Event-Driven Architecture — AWS, 2024. Architectural guides and best practices.

Related content

  • Serverless

    Cloud computing model where the provider manages infrastructure automatically, allowing code execution without provisioning or managing servers, paying only for actual usage.

  • Event-Driven Architecture

    Architectural pattern where components communicate through asynchronous events, enabling decoupled, scalable, and reactive systems.

  • AWS Lambda

    AWS serverless compute service that runs code in response to events without provisioning or managing servers, automatically scaling from zero to thousands of concurrent executions.

  • Microservices

    Architectural style structuring an application as a collection of small, independent, deployable services, each with its own business logic and data.

  • Observability

    Ability to understand a system's internal state from its external outputs: logs, metrics, and traces, enabling problem diagnosis without direct system access.

  • From Prototype to Production: A Serverless Second Brain on AWS

    Architecture design for scaling a personal second brain to a production system with AWS serverless — from the current prototype to specialized use cases in legal, research, and community building.

  • Serverless Second Brain

    Production-ready serverless backend for a personal knowledge graph — DynamoDB, Lambda, Bedrock, MCP, Step Functions. The implementation of the architecture described in the 'From Prototype to Production' essay.

Concepts