Architecture pattern

Design event-driven processing with EventBridge, SNS, SQS, Lambda, and Step Functions

Route events with EventBridge or fan them out with SNS, buffer work in SQS, process messages with Lambda, and orchestrate multi-step work in Step Functions when needed.

Official AWS sources reviewed 2026-07-25.

Architecture flow

  1. Route or fan out: EventBridge filters events by content; SNS publishes messages to subscriptions.
  2. Buffer: SQS absorbs bursts and holds work until a consumer can process it.
  3. Process: A Lambda event source mapping polls the queue in batches.
  4. Orchestrate when needed: Step Functions coordinates multi-step branches, retries, and service integrations.

Text alternative: Producers publish events to EventBridge or SNS. Selected work can be buffered in Amazon SQS, consumed in batches by AWS Lambda, and handed to AWS Step Functions when multi-step orchestration is required. The services are optional roles, not a mandatory linear chain.

How the services connect

Choose EventBridge for event routing and integration, SNS for push-based fan-out, and SQS for durable pull-based buffering. A design may use one or combine them; the diagram does not require every event to cross every service.

Lambda polls SQS through an event source mapping, so processing is asynchronous and at least once. Set visibility timeout, batch-failure behavior, concurrency, dead-letter handling, and idempotency together.

Use Step Functions when coordination, branching, retries, or long-lived state are part of the business process. Do not hide a simple single-step handler behind unnecessary orchestration.

Tradeoffs and caveats

  • Loose coupling improves burst handling and lets consumers evolve independently.
  • Eventual consistency, duplicate delivery, ordering, and cross-service tracing become explicit design concerns.
  • Every hop adds its own request, data, retention, and observability cost.

AWS services in this pattern

Primary AWS sources