What Is Amazon EventBridge? Rules, Targets, and Use Cases

Why EventBridge matters

AWS generates events constantly: EC2 instances changing state, S3 objects being created, GuardDuty detecting threats, CloudTrail recording API calls, CodePipeline stages completing. Without EventBridge, reacting to these events means polling APIs on a loop, writing custom pub/sub infrastructure, or directly coupling services together. All of that adds complexity and fragility.

EventBridge eliminates the glue code. AWS service events arrive on the default event bus automatically with no configuration needed. Rules match events by content. Matching events are delivered to configured targets. The service that generated the event has no knowledge of what processes it.

Custom events work the same way. If your application publishes an OrderCreated event, a fraud-checking Lambda, a fulfilment SQS queue, and a Step Functions workflow can all react to it independently. One event, zero direct service-to-service calls.

How EventBridge works

Every event goes through the same four-step flow:

1. An event source emits an event. This can be an AWS service (EC2, S3, GuardDuty), your own application publishing via the SDK, or a connected SaaS partner (Zendesk, GitHub, Stripe).
2. The event arrives on an event bus. AWS service events land on the default bus automatically. Custom and SaaS events land on custom or partner buses.
3. Rules evaluate the event. Each rule has an event pattern: a partial JSON structure. The event is compared against all active rules on that bus. Rules that match are triggered.
4. EventBridge delivers the event to targets. Each matching rule sends the event to its configured targets: a Lambda function, SQS queue, SNS topic, ECS task, Step Functions state machine, and others.

Key concepts

Event buses

An event bus is the channel that receives events. EventBridge has three types:

• Default bus: Exists in every AWS account. AWS service events arrive here automatically. EC2 state changes, GuardDuty findings, and CloudTrail events all land here with no extra configuration.
• Custom buses: You create these for your own application events. Useful for separating events by domain (e.g., orders-bus, payments-bus) and simplifying IAM policies.
• Partner buses: Receive events directly from SaaS partners that have integrated with EventBridge, such as Zendesk, GitHub, or Salesforce.

Events

Events are JSON objects with a standard envelope. Every event includes metadata fields (source, detail-type, time, account, region) and a detail object with the event-specific payload.

{
  "version": "0",
  "id": "abc-123",
  "source": "aws.ec2",
  "account": "123456789012",
  "time": "2026-03-15T14:00:00Z",
  "region": "us-east-1",
  "detail-type": "EC2 Instance State-change Notification",
  "detail": {
    "instance-id": "i-0abc12345def67890",
    "state": "terminated"
  }
}

Rules

Rules define which events to match and where to send them. Each rule belongs to one event bus and contains an event pattern and one or more targets. You can also configure retry behaviour and a dead-letter queue (DLQ) on the rule itself to handle failed deliveries.

Event patterns

An event pattern is a partial JSON structure. An event matches if every field in the pattern matches the corresponding field in the event. Fields not mentioned in the pattern are ignored. Patterns support exact values, arrays (OR logic), prefix matching, numeric ranges, and anything-but exclusions.

Targets

Targets receive matching events. EventBridge supports over 20 targets, including:

• Lambda functions: the most common target for event-driven processing
• SQS queues: for buffered, consumer-paced processing
• SNS topics: to fan out an event to multiple subscribers
• ECS tasks: to run containerised workloads on demand
• Step Functions state machines: to start multi-step orchestrated workflows
• API Gateway endpoints and Kinesis Data Streams
• Another EventBridge bus: for cross-account event routing

EventBridge Scheduler vs event bus rules

These are two distinct features that are easy to confuse because they both live under EventBridge and both invoke targets:

• Event bus rules react to incoming events. A rule watches for events matching a pattern and routes them to targets as they arrive. The trigger is always an event.
• EventBridge Scheduler runs targets on a time-based schedule: once at a specific datetime, or repeatedly using cron or rate expressions. There is no incoming event. Scheduler generates the invocation itself.

# Run a Lambda function every day at midnight UTC
aws scheduler create-schedule \
  --name daily-cleanup \
  --schedule-expression "cron(0 0 * * ? *)" \
  --target '{
    "Arn": "arn:aws:lambda:us-east-1:123456789012:function:daily-cleanup",
    "RoleArn": "arn:aws:iam::123456789012:role/SchedulerRole"
  }' \
  --flexible-time-window '{"Mode": "OFF"}'

The Scheduler IAM role needs permission to invoke the target (e.g., lambda:InvokeFunction). FlexibleTimeWindow lets the scheduler run within a window around the scheduled time, which smooths traffic when many schedules would otherwise fire at the exact same second.

EventBridge Pipes

EventBridge Pipes connect a single source directly to a single target with optional filtering and enrichment in between. Sources include SQS queues, DynamoDB Streams, Kinesis streams, and Kafka topics. Targets are the same services supported by event bus rules.

A Pipe reads from one source, optionally filters or transforms the data, and delivers it to one target without publishing events to a bus at all. This removes the need for a Lambda function that exists only to pass data between two services.

When to use Amazon EventBridge

• Reacting to AWS service events. EC2 state changes, S3 object creation, GuardDuty findings, CodePipeline transitions: these arrive on the default bus automatically. EventBridge is the intended way to respond to them.
• Triggering serverless workflows. Start Lambda functions, Step Functions executions, or ECS tasks in response to events without polling loops.
• Decoupling microservices. Services publish events to a custom bus. Consumers add rules independently. Neither side knows about the other, so teams can add or change consumers without touching the publisher.
• SaaS and application integrations. Receive events from connected SaaS partners directly on a partner bus and route them into your internal services.
• Scheduled jobs. Use EventBridge Scheduler for cron-based tasks: backups, cache warming, report generation, reminder emails.
• Security and compliance automation. Route GuardDuty findings or CloudTrail events to Lambda functions that automatically remediate misconfigurations or trigger incident workflows.

When not to use EventBridge

That missing persistence makes EventBridge the wrong choice in several scenarios:

• You need guaranteed, consumer-paced processing. If your consumer processes at its own rate and needs messages to wait, use SQS. SQS holds messages in a queue until a consumer polls and processes them, and delivery is guaranteed regardless of consumer speed or temporary failures.
• You need to fan out to many subscribers without filtering. If you want to push the same message to ten services with no routing logic, SNS is simpler. See the SNS push vs pull model for how its delivery works.
• Very high-throughput data streaming. For millions of events per second with strict ordering guarantees, Kinesis Data Streams is more appropriate than EventBridge.
• Simple direct service calls. If Service A always calls Service B synchronously with no routing logic, a direct SDK call is clearer than introducing an event bus.

EventBridge vs SNS vs SQS

All three appear in event-driven architectures but serve different roles. See the SNS vs SQS comparison for more on the difference between the latter two.

Which one should I use? Use EventBridge when you need to route events based on their content, react to AWS service events, or decouple producers from consumers. Use SNS when you need to push the same message to many subscribers at once with minimal filtering. Use SQS when messages need to wait in a queue and be processed at the consumer’s pace. Guaranteed delivery matters here. These services are often combined: EventBridge routes to an SNS topic, which fans out to SQS queues consumed by Lambda. The SNS messaging model page explains how SNS delivery works in that pattern.

Real examples

CLI: create a rule for EC2 termination events

# Create the rule on the default bus
aws events put-rule \
  --name ec2-termination-notification \
  --event-pattern '{
    "source": ["aws.ec2"],
    "detail-type": ["EC2 Instance State-change Notification"],
    "detail": {
      "state": ["terminated"]
    }
  }' \
  --state ENABLED \
  --description "Notify when an EC2 instance is terminated"

# Add the Lambda function as a target
aws events put-targets \
  --rule ec2-termination-notification \
  --targets '[{
    "Id": "lambda-target",
    "Arn": "arn:aws:lambda:us-east-1:123456789012:function:ec2-termination-handler"
  }]'

# Grant EventBridge permission to invoke the function
aws lambda add-permission \
  --function-name ec2-termination-handler \
  --statement-id allow-eventbridge \
  --action lambda:InvokeFunction \
  --principal events.amazonaws.com \
  --source-arn "arn:aws:events:us-east-1:123456789012:rule/ec2-termination-notification"

SDK: publish a custom event from your application

import boto3
import json
from datetime import datetime

events_client = boto3.client('events')

def publish_order_event(order_id: str, amount: float, customer_id: str):
    events_client.put_events(
        Entries=[{
            'Source': 'myapp.orders',
            'DetailType': 'OrderCreated',
            'Detail': json.dumps({
                'orderId': order_id,
                'amount': amount,
                'customerId': customer_id,
                'timestamp': datetime.utcnow().isoformat()
            }),
            'EventBusName': 'myapp-orders-bus'
        }]
    )

Any rule matching source=myapp.orders, detail-type=OrderCreated will route this event to its targets: a fraud-checking Lambda, a fulfilment SQS queue, a Step Functions workflow. All triggered by one put_events call, with no direct coupling between the systems.

Best practices

• Write precise event patterns. Match on source, detail-type, and specific fields in detail. Avoid patterns that route unintended events to targets.
• Use least-privilege IAM. Grant EventBridge only the permissions it needs to invoke your specific target. For Lambda, use a resource-based policy scoped to the rule’s ARN. See monitoring Lambda for observing invocations once policies are in place.
• Configure DLQs and retries on every production rule. EventBridge supports up to 185 retry attempts and an SQS DLQ for failed deliveries. Without a DLQ, events that exhaust retries are permanently lost with no record.
• Monitor with CloudWatch. Track FailedInvocations and ThrottledRules metrics. Set up alarms so failures surface before users notice.
• Use custom buses for application events. Keep domain events on a custom bus, separate from the default bus. This prevents AWS service events from mixing with your application events and simplifies IAM rules.
• Use consistent naming conventions. Prefix rule names with the domain and event type (e.g., orders-OrderCreated-fulfil). This makes rules scannable in the console and in infrastructure-as-code reviews.