EventBridge Rules, Targets, and Schemas

In the previous lesson, we introduced Amazon EventBridge and its core concepts. Now we go deeper into the three pillars that make EventBridge a powerful event router: rules for matching events, targets for processing them, and schemas for documenting and validating event structure.

---

Advanced Rule Patterns

Combining Multiple Conditions

Event patterns support combining conditions with implicit AND logic. Every field in the pattern must match for the rule to fire.

{
  "source": ["order-service"],
  "detail-type": ["OrderPlaced"],
  "detail": {
    "country": ["UK"],
    "total": [{"numeric": [">=", 50]}],
    "paymentMethod": ["credit-card", "debit-card"]
  }
}

This matches events where:

• Source is order-service AND
• Detail type is OrderPlaced AND
• Country is UK AND
• Total is >= 50 AND
• Payment method is either credit-card or debit-card

OR Logic Within a Field

Within a single field, multiple values act as OR:

{
  "detail": {
    "status": ["shipped", "delivered"]
  }
}

This matches events where status is shipped OR delivered.

Negation with Anything-But

{
  "detail": {
    "environment": [{"anything-but": ["test", "staging"]}]
  }
}

This matches any environment except test and staging — useful for ensuring production-only rules.

Nested Field Matching

You can match on deeply nested fields:

{
  "detail": {
    "shipping": {
      "method": ["express"],
      "address": {
        "country": ["UK", "DE", "FR"]
      }
    }
  }
}

---

Input Transformations

By default, EventBridge sends the entire event JSON to the target. Input transformations let you reshape the event before delivering it, sending only the data the target needs.

Input Path

Extract specific fields from the event:

{
  "orderId": "$.detail.orderId",
  "customer": "$.detail.customerId",
  "total": "$.detail.total"
}

Input Template

Combine extracted fields into a new format:

"Order <orderId> from customer <customer> for £<total> needs processing."

Full Transformation Example

Given this incoming event:

{
  "source": "order-service",
  "detail-type": "OrderPlaced",
  "detail": {
    "orderId": "ORD-12345",
    "customerId": "CUST-789",
    "total": 149.99,
    "items": ["SKU-001", "SKU-042"]
  }
}

With input path:

{"orderId": "$.detail.orderId", "total": "$.detail.total"}

And input template:

{"message": "Process order <orderId>", "amount": <total>}

The target receives:

{"message": "Process order ORD-12345", "amount": 149.99}

This is powerful for integrating with targets that expect a specific payload format — you reshape the event without writing any code.

---

Target Configuration in Depth

Multiple Targets Per Rule

A single rule can route events to up to 5 targets. Each target receives the event independently.

[Rule: order-placed]
     |
     +——> Target 1: Lambda (process order)
     +——> Target 2: SQS (analytics queue)
     +——> Target 3: CloudWatch Logs (audit)

Retry Policy

Each target has a configurable retry policy:

Setting	Description	Default
Maximum age of event	How long EventBridge retries delivery	24 hours
Maximum retry attempts	Number of retries before giving up	185

{
  "RetryPolicy": {
    "MaximumRetryAttempts": 3,
    "MaximumEventAgeInSeconds": 3600
  }
}

Dead-Letter Queue for Failed Deliveries

If EventBridge cannot deliver an event to a target after exhausting retries, it can send the event to an SQS dead-letter queue:

{
  "DeadLetterConfig": {
    "Arn": "arn:aws:sqs:eu-west-2:123456789012:eventbridge-dlq"
  }
}

This ensures no events are silently lost.

Target-Specific Configuration

Different targets accept different configuration: