AWS EventBridge

🎯What is AWS EventBridge?

AWS EventBridge is a serverless event bus service that enables you to build event-driven applications at scale. It acts as a central hub for routing events between different AWS services, third-party applications, and custom applications, making it easier to build loosely coupled and scalable architectures.

Why EventBridge?

Traditional point-to-point integrations can become complex and difficult to maintain as your system grows. EventBridge solves this by providing a centralized event routing mechanism that decouples event producers from consumers, enabling better scalability, maintainability, and flexibility.

🏗️EventBridge Architecture

The EventBridge architecture consists of three main components working together to provide a robust event-driven system. Event sources generate events, the event bus receives and stores them temporarily, and rules determine where events should be routed based on their content.

✨Key Features

🔧Core Components

Event Bus

An event bus is a pipeline that receives events. EventBridge provides a default event bus for AWS service events, and you can create custom event buses for your applications.

Event Rules

Rules match incoming events and route them to targets for processing. Each rule can have multiple targets and uses event patterns to determine matches.

Event Targets

Targets are AWS services or resources that process events. EventBridge supports over 20 AWS services as targets, including Lambda, SQS, SNS, and Step Functions.

Event Patterns

Event patterns are JSON objects that define which events to match. They support exact matching, prefix matching, and more complex filtering logic.

📊Common Event-Driven Patterns

Fan-out Pattern

One event triggers multiple downstream processes simultaneously.

Event Sourcing Pattern

Store all changes as a sequence of events, enabling audit trails and system rebuilding.

Saga Pattern

Manage distributed transactions across multiple services using compensating actions.

⚙️AWS CLI Configuration

Create Custom Event Bus

# Create a custom event bus
aws events create-event-bus \
  --name "my-application-bus" \
  --tags Key=Environment,Value=Production Key=Team,Value=Backend

Explanation: This command creates a new custom event bus named "my-application-bus". Custom event buses are isolated from the default AWS event bus and allow you to organize events by application or domain. The tags help with resource management and cost allocation, marking this bus as belonging to the Backend team in a Production environment.

Create Event Rule

# Create an event rule with pattern matching
aws events put-rule \
  --name "order-processing-rule" \
  --event-pattern '{
    "source": ["myapp.orders"],
    "detail-type": ["Order Placed"],
    "detail": {
      "state": ["confirmed"]
    }
  }' \
  --state ENABLED \
  --description "Route confirmed orders to processing"

Explanation: This creates an event rule that acts as a filter for incoming events. The rule only matches events from the "myapp.orders" source with detail-type "Order Placed" and where the state is "confirmed". When an event matches this pattern, EventBridge will route it to all configured targets. The rule is immediately enabled and can process events.

Add Rule Targets

# Add Lambda function as target
aws events put-targets \
  --rule "order-processing-rule" \
  --targets '[
    {
      "Id": "1",
      "Arn": "arn:aws:lambda:us-west-2:123456789012:function:ProcessOrder",
      "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeRole"
    }
  ]'

# Add SQS queue as target with DLQ
aws events put-targets \
  --rule "order-processing-rule" \
  --targets '[
    {
      "Id": "2",
      "Arn": "arn:aws:sqs:us-west-2:123456789012:order-queue",
      "SqsParameters": {
        "MessageGroupId": "orders"
      },
      "DeadLetterConfig": {
        "Arn": "arn:aws:sqs:us-west-2:123456789012:order-dlq"
      }
    }
  ]'

Explanation: These commands add targets to the "order-processing-rule". The first command adds a Lambda function that will be invoked when the rule matches an event. The RoleArn specifies the IAM role EventBridge assumes to invoke the Lambda function. The second command adds an SQS queue with FIFO ordering (MessageGroupId) and configures a dead letter queue (DLQ) for messages that fail processing after retries. Each target needs a unique Id within the rule.

Send Custom Events

# Send a custom event
aws events put-events \
  --entries '[
    {
      "Source": "myapp.orders",
      "DetailType": "Order Placed",
      "Detail": "{\"orderId\":\"12345\",\"customerId\":\"67890\",\"amount\":99.99,\"state\":\"confirmed\"}",
      "Time": "2025-07-01T12:00:00Z"
    }
  ]'

Explanation: This command publishes a custom event to EventBridge. The event contains structured data including source (identifying where the event came from), detail-type (what happened), and detail (the actual event payload as JSON). The Time parameter is optional - if omitted, EventBridge uses the current timestamp. This event will match the rule we created earlier because it has source "myapp.orders", detail-type "Order Placed", and state "confirmed".

Event Bus Permissions

# Allow cross-account access to event bus
aws events put-permission \
  --principal "123456789012" \
  --action "events:PutEvents" \
  --statement-id "AllowCrossAccountAccess"

# Create IAM role for EventBridge
aws iam create-role \
  --role-name EventBridgeRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "events.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }'

Explanation: The first command grants permission for another AWS account (123456789012) to send events to your event bus. This enables cross-account event routing, useful for multi-account architectures. The second command creates an IAM service role that EventBridge can assume to invoke targets on your behalf. The assume role policy allows the EventBridge service to take on this role, which you'll then attach policies to grant specific permissions (like invoking Lambda functions or sending messages to SQS).

Schema Registry Operations

# Create a schema registry
aws schemas create-registry \
  --registry-name "MyAppSchemas" \
  --description "Schema registry for my application events"

# Create a schema
aws schemas create-schema \
  --registry-name "MyAppSchemas" \
  --schema-name "OrderPlaced" \
  --type "JSONSchemaDraft4" \
  --content '{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "type": "object",
    "properties": {
      "orderId": {"type": "string"},
      "customerId": {"type": "string"},
      "amount": {"type": "number"},
      "state": {"type": "string"}
    },
    "required": ["orderId", "customerId", "amount", "state"]
  }'

Explanation: These commands set up EventBridge Schema Registry for event governance. The first command creates a registry namespace to organize related schemas. The second command defines a JSON Schema that validates the structure of "OrderPlaced" events. This schema enforces that events must have orderId, customerId, amount, and state fields with specific data types. Schema Registry helps with event discoverability, validation, and code generation for developers consuming events.

Event Archive and Replay

# Create an event archive
aws events create-archive \
  --archive-name "order-events-archive" \
  --event-source-arn "arn:aws:events:us-west-2:123456789012:event-bus/my-application-bus" \
  --description "Archive for order events" \
  --retention-days 30

# Start event replay
aws events start-replay \
  --replay-name "order-replay-2025" \
  --event-source-arn "arn:aws:events:us-west-2:123456789012:archive/order-events-archive" \
  --event-start-time "2025-06-01T00:00:00Z" \
  --event-end-time "2025-06-30T23:59:59Z" \
  --destination '{
    "Arn": "arn:aws:events:us-west-2:123456789012:event-bus/replay-bus",
    "FilterArns": ["arn:aws:events:us-west-2:123456789012:rule/replay-rule"]
  }'

Explanation: The first command creates an archive that automatically stores all events from "my-application-bus" for 30 days. Archives are useful for debugging, compliance, and disaster recovery. The second command initiates a replay of archived events from June 2025, sending them to a "replay-bus" where they can be processed by specific rules without affecting production systems. This is invaluable for testing new features against historical data or recovering from processing failures.

💼Practical Examples

E-commerce Order Processing

Complete workflow for processing e-commerce orders using EventBridge.

# Create rules for order processing workflow
aws events put-rule \
  --name "inventory-check" \
  --event-pattern '{
    "source": ["ecommerce.orders"],
    "detail-type": ["Order Placed"],
    "detail": {"status": ["pending"]}
  }'

aws events put-rule \
  --name "payment-processing" \
  --event-pattern '{
    "source": ["ecommerce.inventory"],
    "detail-type": ["Inventory Reserved"]
  }'

aws events put-rule \
  --name "shipping-creation" \
  --event-pattern '{
    "source": ["ecommerce.payment"],
    "detail-type": ["Payment Processed"]
  }'

Explanation: These commands create a chain of event rules for an e-commerce workflow. The "inventory-check" rule triggers when new orders are placed with pending status. The "payment-processing" rule activates when inventory is successfully reserved. The "shipping-creation" rule fires when payment is processed. This creates a sequential workflow where each step triggers the next, enabling loose coupling between microservices while maintaining order dependencies.

Microservices Communication

Enable loose coupling between microservices using EventBridge.

Real-time Data Processing

Stream processing pipeline using EventBridge and Kinesis.

# Create rule for streaming data to Kinesis
aws events put-rule \
  --name "stream-user-events" \
  --event-pattern '{
    "source": ["myapp.users"],
    "detail-type": ["User Action"]
  }'

aws events put-targets \
  --rule "stream-user-events" \
  --targets '[
    {
      "Id": "1",
      "Arn": "arn:aws:kinesis:us-west-2:123456789012:stream/user-events",
      "KinesisParameters": {
        "PartitionKeyPath": "$.detail.userId"
      }
    }
  ]'

Explanation: These commands set up real-time data streaming from EventBridge to Kinesis. The first command creates a rule that matches all user action events. The second command configures Kinesis as a target, using the "userId" field from the event detail as the partition key. This ensures that all events from the same user go to the same Kinesis shard, maintaining order for per-user event processing while enabling parallel processing across different users.

🎯Best Practices

Event Naming Conventions

• Source: Use reverse DNS notation (com.company.service)
• Detail Type: Use descriptive past-tense verbs (Order Placed, User Registered)
• Schema Evolution: Use versioned schemas and maintain backward compatibility

Error Handling

# Configure dead letter queue for failed events
aws events put-targets \
  --rule "my-rule" \
  --targets '[
    {
      "Id": "1",
      "Arn": "arn:aws:lambda:us-west-2:123456789012:function:MyFunction",
      "DeadLetterConfig": {
        "Arn": "arn:aws:sqs:us-west-2:123456789012:failed-events-dlq"
      },
      "RetryPolicy": {
        "MaximumRetryAttempts": 3,
        "MaximumEventAge": 3600
      }
    }
  ]'

Explanation: This command configures robust error handling for event processing. When EventBridge fails to deliver an event to the Lambda function, it will retry up to 3 times. If the event is older than 3600 seconds (1 hour) or all retries fail, the event is sent to the dead letter queue (DLQ) for manual investigation. This prevents event loss while avoiding infinite retry loops that could impact system performance.

Monitoring and Observability

• Use CloudWatch metrics to monitor event throughput and failures
• Enable CloudTrail for audit logging of EventBridge API calls
• Set up alarms for failed invocations and dead letter queues
• Use AWS X-Ray for distributed tracing across event-driven workflows

Security Considerations

• Use IAM roles with least privilege access
• Enable encryption in transit and at rest
• Implement resource-based policies for cross-account access
• Validate event content and implement input sanitization

Cost Optimization

• Use event filtering to reduce unnecessary target invocations
• Implement batching for high-volume event processing
• Monitor and optimize event bus usage patterns
• Consider using SQS as a buffer for cost-effective processing