EventBridge & Step Functions: Events and Orchestration

EventBridge and Step Functions solve two different problems that get lumped together as "event-driven AWS."

EventBridge answers "something happened, who needs to know." Step Functions answers "here is a sequence of steps, run them in order, track the state, and handle failure." Both are fully managed and both are driven from the SDK the same way as any other AWS service - a client, an operation, a JSON-shaped input.

This page builds the mental model that separates the two, then shows where they meet.

Summary

• EventBridge is an event bus: producers publish events, rules match on event content, and matched events fan out to independent targets.
• Step Functions is a state-machine orchestrator: you define an ordered workflow (Amazon States Language, or ASL) and it executes each step, tracking state and retrying on failure.
• Key Concepts: event bus, rule, event pattern, target, state machine, execution, ASL.
• When to Use: EventBridge for "react to this happening, however many things care"; Step Functions for "run these steps in order, with branching, retries, and a durable history."
• Limitations/Trade-offs: EventBridge targets are fire-and-forget per rule, with no built-in multi-step sequencing; Step Functions needs an explicit ASL definition and is heavier to set up than a single rule.
• Related Topics: event buses and pattern matching, state-machine types (Standard vs Express), and error handling within a workflow.

Foundations

An event is a small JSON record describing something that already happened - an order was placed, a file landed in a bucket, a deployment finished. EventBridge's job is distribution: a producer calls PutEvents, and any rule whose event pattern matches the event's source, detail-type, or detail fields fires, invoking its configured targets (a Lambda function, an SQS queue, a Step Functions state machine, and dozens more).

A workflow, by contrast, is a sequence you want to run to completion - validate an order, charge a card, reserve inventory, notify the customer, and roll back cleanly if any step fails. Step Functions expresses that as a state machine: a JSON document written in ASL, with named states, transitions, and error handling. Each run of it is an execution, and Step Functions tracks that execution's state, input, and output for you.

# --- Python (boto3) ---
import boto3
 
events = boto3.client("events")
events.put_events(Entries=[{
    "Source": "orders.api",
    "DetailType": "OrderPlaced",
    "Detail": '{"orderId": "ord-1"}',
    "EventBusName": "default",
}])

// --- TypeScript (AWS SDK v3) ---
import { EventBridgeClient, PutEventsCommand } from "@aws-sdk/client-eventbridge";
 
const events = new EventBridgeClient({});
await events.send(new PutEventsCommand({
  Entries: [{
    Source: "orders.api",
    DetailType: "OrderPlaced",
    Detail: JSON.stringify({ orderId: "ord-1" }),
    EventBusName: "default",
  }],
}));

That single PutEvents call is the whole EventBridge side of "something happened." What runs next, and in what order, is a separate question - one Step Functions is built to answer.

Mechanics & Interactions

EventBridge's flow is bus -> rule -> target. A bus (the account's default bus, or a custom event bus you create) receives events. A rule on that bus declares an event pattern, a JSON shape matched against incoming events - for example, only OrderPlaced events from orders.api. Every target attached to a matching rule is invoked independently and in parallel; there is no ordering or dependency between them.

Step Functions' flow is definition -> execution -> states. You register a state machine once with CreateStateMachine, passing an ASL definition and a type (STANDARD or EXPRESS). Each StartExecution call runs that definition against a specific input, moving through states such as Task (do work, often calling another AWS API directly), Choice (branch), Wait, Parallel, and Catch/Retry for error handling. Standard executions keep a full, queryable history for up to a year; Express executions are built for high volume and short duration, logging to CloudWatch Logs instead.

The two connect at exactly one seam: EventBridge can target a Step Functions state machine. A PutTargets call whose target ARN is a state machine turns "an event arrived" into "start an execution," passing the event (or a piece of it) as the execution's input.

# --- Python (boto3) ---
import boto3
 
events = boto3.client("events")
events.put_targets(
    Rule="order-placed-rule",
    Targets=[{
        "Id": "start-fulfillment",
        "Arn": "arn:aws:states:us-east-1:111122223333:stateMachine:FulfillOrder",
        "RoleArn": "arn:aws:iam::111122223333:role/eventbridge-invoke-sfn",
    }],
)

// --- TypeScript (AWS SDK v3) ---
import { EventBridgeClient, PutTargetsCommand } from "@aws-sdk/client-eventbridge";
 
const events = new EventBridgeClient({});
await events.send(new PutTargetsCommand({
  Rule: "order-placed-rule",
  Targets: [{
    Id: "start-fulfillment",
    Arn: "arn:aws:states:us-east-1:111122223333:stateMachine:FulfillOrder",
    RoleArn: "arn:aws:iam::111122223333:role/eventbridge-invoke-sfn",
  }],
}));

From here on, EventBridge is out of the picture - the state machine owns the rest of the process.

Advanced Considerations & Applications

Think of EventBridge as the notification layer and Step Functions as the process layer. A system commonly uses both together: EventBridge decouples "who needs to react" from the producer, and Step Functions owns any reaction that itself has multiple ordered steps with its own failure handling.

A useful test: if a rule's target is a single, idempotent action (send a notification, write a row, invoke one Lambda), EventBridge alone is enough. If that "one action" is actually several dependent steps - call a payment API, then reserve inventory, then notify, rolling back on failure - that belongs in a state machine, not spread across independent EventBridge targets with no shared state or ordering guarantee.

A common mistake is trying to build a multi-step process entirely out of chained EventBridge rules (rule A triggers a Lambda that publishes an event that triggers rule B, and so on). It works, but you lose a single execution history, and debugging "why did step 3 never run" means reconstructing the chain by hand. Step Functions gives you that history for free.

Common Misconceptions

• "EventBridge and Step Functions are competing services." - No, they solve different problems and are frequently used together, with EventBridge starting a Step Functions execution.
• "Step Functions is only for Lambda orchestration." - No, SDK integrations let states call ~200+ AWS service APIs directly, with no Lambda involved for a simple API call.
• "An EventBridge rule can run steps in order." - No, all of a rule's targets are invoked independently; there is no built-in sequencing between them.
• "You need EventBridge in front of every state machine." - No, StartExecution can be called directly by any SDK caller; EventBridge is one of many ways to trigger a workflow.
• "Express workflows are just a cheaper Standard." - No, they trade full execution history and exactly-once semantics for higher throughput and at-least-once delivery; see the Standard vs Express comparison for the full trade-off.

FAQs

Related

• Event-Driven AWS Basics - publish an event and start a state machine end to end.
• Event Buses, Rules & Pattern Matching - the EventBridge side in depth.
• Step Functions State Machines: Standard vs Express - choosing a workflow type.
• Event-Driven AWS via SDK Best Practices - defaults for both services together.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+). pbqrthvqrf.vb|ptvb1175|202607