EventBridge and Step Functions

Amazon EventBridge is a serverless event bus service that ingests, filters, transforms, and routes events from AWS services, SaaS applications, and custom applications. It replaces Amazon CloudWatch Events, offering a richer set of features such as schema registry, event archiving, and replay. The core concept is the "event"—a JSON object that describes a change in state. Events are published to an event bus, and rules determine which events are forwarded to which targets.

- Event Bus: A pipeline that receives events. There are three types: default bus (receives events from AWS services), custom buses (for your own applications), and partner buses (from SaaS partners). Each account has one default bus per region. - Event: A JSON structure with fields like source, detail-type, detail, resources, time, region, account, and version. Example:

{
    "version": "0",
    "id": "12345678-1234-1234-1234-123456789012",
    "detail-type": "EC2 Instance State-change Notification",
    "source": "aws.ec2",
    "account": "123456789012",
    "time": "2023-01-01T00:00:00Z",
    "region": "us-east-1",
    "resources": ["arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0"],
    "detail": {
      "instance-id": "i-1234567890abcdef0",
      "state": "running"
    }
  }

- Rule: Evaluates events as they arrive. A rule consists of an event pattern (filter) and one or more targets. Event patterns use JSON matching, supporting exact match, prefix, suffix, numeric comparison, exists, and anything-but. Example pattern to match EC2 instance running:

{
    "source": ["aws.ec2"],
    "detail-type": ["EC2 Instance State-change Notification"],
    "detail": {
      "state": ["running"]
    }
  }

When an event is published, it is received by the event bus. The bus evaluates all rules in parallel. Each rule's event pattern is matched against the incoming event. If matched, the event is sent to all targets of that rule. Targets are invoked synchronously or asynchronously depending on the target type. For example, Lambda is invoked asynchronously by default, while Step Functions is invoked synchronously. The event is delivered at least once; duplicate events are possible, so targets should be idempotent. EventBridge uses a payload-based model: the entire event is delivered to the target, but you can use input transformers to modify the payload before delivery.

AWS Step Functions is a serverless orchestration service that lets you coordinate multiple AWS services into a workflow. You define state machines using Amazon States Language (ASL), a JSON-based language. State machines consist of states (tasks, choices, waits, parallels, etc.) and transitions. Step Functions executes the workflow, handling retries, error handling, and timeouts.

When a state machine execution starts, Step Functions creates an execution record. It then traverses states sequentially, performing the action of each state. For Task states, it invokes the specified service and waits for a response. The service's response becomes the input to the next state. If a task fails, the state machine can retry based on Retry configuration (e.g., exponential backoff with jitter). If retries are exhausted, the Catch block can route to a fallback state. Step Functions also supports activity tasks where a worker polls for tasks, useful for long-running activities.

EventBridge can trigger Step Functions state machines directly as a target. The event from EventBridge becomes the input to the state machine. Step Functions can also emit events to EventBridge using the PutEvents API call from a Task state, enabling complex event-driven workflows. For example, a state machine processes an order and emits an "OrderProcessed" event, which EventBridge routes to a notification service.

To create an EventBridge rule via CLI:

aws events put-rule --name "MyRule" --event-pattern '{"source": ["aws.ec2"]}'

To add a target:

aws events put-targets --rule "MyRule" --targets "Id"="1","Arn"="arn:aws:lambda:us-east-1:123456789012:function:MyFunction"

To create a Step Functions state machine via CLI:

aws stepfunctions create-state-machine --name "MyStateMachine" --definition file://definition.json --role-arn arn:aws:iam::123456789012:role/MyRole

To start an execution:

aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MyStateMachine --input '{"key": "value"}'

To list executions:

aws stepfunctions list-executions --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MyStateMachine

In a real-world e-commerce platform, EventBridge and Step Functions are used to orchestrate order processing. When a customer places an order, a custom application publishes an event to a custom EventBridge bus. The event includes order details. An EventBridge rule matches this event and triggers a Step Functions state machine. The state machine first validates the order by calling a Lambda function. If valid, it checks inventory via a DynamoDB query (Task state). If inventory is sufficient, it processes payment via a third-party API (using an activity task or Lambda). Finally, it sends a notification via SNS and updates the order status. This decouples the frontend from backend processing, ensuring resilience. Misconfiguration often occurs when the event pattern is too broad, causing unintended invocations, or when IAM roles lack permissions, leading to failed executions. Another common scenario is in data processing pipelines. For example, a media company ingests video uploads from S3. An S3 event is sent to EventBridge (via S3 Event Notifications). The rule triggers a Step Functions workflow that transcodes the video using Elastic Transcoder, generates thumbnails via Lambda, and stores metadata in DynamoDB. The workflow includes parallel states for transcoding and thumbnail generation, and wait states for long transcoding jobs. Performance considerations include setting appropriate timeouts (e.g., 30 minutes for transcoding) and using Express workflows for high-volume, short-duration tasks. A common issue is forgetting to handle partial failures—if thumbnail generation fails, the entire workflow may fail unless a Catch block redirects to a compensation state. In financial services, EventBridge and Step Functions manage trade settlements. A trade execution event triggers a state machine that validates compliance, checks counterparty risk, settles via clearing house API, and updates ledger. Step Functions' retry mechanism handles transient API failures with exponential backoff. The exam emphasizes understanding execution history retention: Standard workflows retain history for 90 days, useful for audits. Express workflows log to CloudWatch, which is cheaper but less durable.