事件驅動整合：EventBridge、SQS 與 SNS

Amazon EventBridge is the main character of application integration on the DVA-C02 exam. In the V2.1 exam outline, AWS promoted EventBridge from a supporting cast member to the default answer for "route events, decouple producers and consumers, fan out to many targets with filtering, replay after an incident, or schedule recurring jobs." If you understand Amazon EventBridge in depth — event buses, rules, schema registry, archive and replay, EventBridge Scheduler, and EventBridge Pipes — you already hold the biggest piece of the Domain 2 application integration score. Around Amazon EventBridge orbit three siblings the exam still tests: Amazon SNS for pure pub/sub fan-out, Amazon SQS for durable work queues, and AWS Step Functions for multi-step orchestration with retries. This notes page walks every Amazon EventBridge surface a developer needs, compares Amazon EventBridge to Amazon SNS, Amazon SQS, and AWS Step Functions one by one, and gives you a decision tree for picking the right service on exam day.

Amazon EventBridge matters on DVA-C02 because the exam stopped asking "is this SNS or SQS?" and started asking "which Amazon EventBridge feature solves this?" Amazon EventBridge rules replace polling. Amazon EventBridge Scheduler replaces cron. Amazon EventBridge Pipes replaces glue Lambdas. Amazon EventBridge archive and replay replaces "write a DLQ and hope for the best." Amazon EventBridge schema registry replaces hand-maintained JSON contracts. The modern AWS developer is expected to reach for Amazon EventBridge first, then fall back to Amazon SNS, Amazon SQS, or AWS Step Functions only when a specific constraint forces it.

What Is Amazon EventBridge?

Amazon EventBridge is a serverless event bus that ingests events from AWS services, SaaS partners, and your own applications, then routes those events to one or more targets based on rules that match an event pattern. An Amazon EventBridge event is a JSON document with a known envelope: source, detail-type, detail, time, region, and account. A rule is a stored filter that says "when an event on this bus matches this pattern, deliver it to these targets." A target is any of 30+ AWS services Amazon EventBridge can invoke directly — Lambda, Step Functions, SQS, SNS, Kinesis Data Streams, Firehose, ECS tasks, API Gateway, API destinations, and more.

Amazon EventBridge has three types of buses, and knowing which bus to use is a recurring DVA-C02 question:

• Default bus — every AWS account has one default Amazon EventBridge bus per Region, and it automatically receives events from most AWS services (EC2 state changes, S3 object events when enabled, CodePipeline transitions, Health events, etc.). You cannot rename or delete the default bus.
• Custom bus — you create custom Amazon EventBridge buses for your own application events. Put business events like OrderPlaced, UserSignedUp, or InvoicePaid on a custom bus so they do not mix with AWS service events on the default bus. Most real applications publish to a custom Amazon EventBridge bus.
• Partner bus — SaaS partners (Zendesk, PagerDuty, Datadog, Shopify, Auth0, MongoDB Atlas, Stripe via partner integration, etc.) deliver events to dedicated partner Amazon EventBridge buses in your account. You create a rule on the partner bus to forward matching events to your Amazon EventBridge targets or onward.

Amazon EventBridge charges per million events published to a custom or partner bus; events from AWS services to the default bus are free. That pricing detail matters when you architect cost-aware fan-out and the exam asks about it.

白話文解釋 Amazon EventBridge

Three plain-language analogies show why Amazon EventBridge deserves its starring role on DVA-C02.

Analogy 1: Amazon EventBridge as an Airport Control Tower

Picture a big international airport. Hundreds of things happen every minute — planes land, gates change, bags get scanned, weather shifts, fuel trucks move, crews clock in. Amazon EventBridge is the control tower. Every interesting happening is radioed up as an event with a tag ("source: bag-handling, detail-type: bag-scanned"), and the tower has a binder of rules: "if source is weather and detail-type is thunderstorm alert, notify every gate team and push an update to the departures board; if source is gate and detail-type is gate-change for Lufthansa flights, notify ground crew only." The control tower does not do the actual work at each gate; it just routes events based on the rule binder. Amazon EventBridge rules and Amazon EventBridge targets work exactly the same way — a rule matches an Amazon EventBridge event pattern, and each matched event gets delivered to up to five Amazon EventBridge targets.

Analogy 2: Amazon EventBridge Schema Registry as a Library's Book Catalog

Imagine a public library. Every new book arriving gets cataloged — title, author, ISBN, genre, year — in a master catalog (the schema registry). New readers (developers) who want to find books on a topic do not have to open every book to see what is inside; they read the catalog entry first. Amazon EventBridge schema registry is this catalog for events. When you turn on auto-discovery, Amazon EventBridge watches events flowing through your Amazon EventBridge bus, records the shape of each new event type, and generates a schema. Developers then download code bindings — Java, Python, TypeScript — directly from the Amazon EventBridge schema registry into their IDE, so event.detail.orderId autocompletes and the compiler refuses to let them misspell a field. No more chasing JSON fields through Slack threads.

Analogy 3: Amazon EventBridge Archive and Replay as a DVR with a Time-Travel Button

Think about a DVR on a living-room TV. It records every show that comes through a channel, and you can rewind, pause, or replay weeks later. Amazon EventBridge archive is that DVR for an Amazon EventBridge bus. Turn it on, set a retention period (1 day to indefinite), and Amazon EventBridge silently captures every event matching an optional filter. If your consumer Lambda had a bug and mis-processed three days of OrderPlaced events, you deploy a fix, then run an Amazon EventBridge replay that re-sends just those three days of archived events back through the bus — Amazon EventBridge targets receive them as if they were live. This is time-travel debugging for event-driven architectures, and neither Amazon SNS nor Amazon SQS offers it out of the box.

Analogy 4: Amazon EventBridge Pipes as a Pre-Assembled Kitchen Appliance

Before Amazon EventBridge Pipes, hooking an SQS queue to a Step Functions workflow meant writing an intermediate Lambda — poll the queue, parse the message, start the execution, handle errors. You were building a food processor out of spare motor parts. Amazon EventBridge Pipes is the pre-assembled appliance: source on one end (SQS, Kinesis, DynamoDB Streams, MSK, MQ, self-managed Kafka), optional filter, optional enrichment (Lambda, Step Functions, API destination, API Gateway), and target on the other end (any Amazon EventBridge target). Zero glue code. Plug in, press the button, food comes out. That is Amazon EventBridge Pipes.

Amazon EventBridge Event Buses in Depth

Amazon EventBridge buses are where events live. A Region hosts one default Amazon EventBridge bus, zero or more custom Amazon EventBridge buses, and one partner bus per enabled SaaS partner integration. Every Amazon EventBridge event has exactly one bus at a time, although cross-account and cross-Region forwarding can move events between buses.

The Default Bus

Most AWS services automatically emit their events to the default Amazon EventBridge bus in every Region where they run. If you want to react to an EC2 instance state change, an S3 object creation (once enabled on the bucket), a CodeBuild build phase change, a CodePipeline stage transition, a Health event, or an AWS Config rule evaluation, you write a rule on the default Amazon EventBridge bus with a pattern like {"source": ["aws.s3"], "detail-type": ["Object Created"]}. Events from AWS services to the default bus cost nothing, and this is the on-ramp for most "react to AWS" scenarios.

Custom Buses

When your application publishes its own business events, you create a custom Amazon EventBridge bus — for example a bus named orders-prod. Your checkout service calls PutEvents with source: com.example.orders, detail-type: OrderPlaced, and a detail payload containing the order ID, customer ID, and total. Consumers on orders-prod write Amazon EventBridge rules that filter on source and detail-type to receive only the events they care about. Custom Amazon EventBridge buses isolate your domain events from AWS service noise, apply their own resource policies, and make IAM permissions clearer.

Partner Buses

Partner buses receive events from external SaaS applications that have integrated with Amazon EventBridge. After you create a partner event source subscription (done once per partner, per account, per Region), Amazon EventBridge provisions a partner bus like aws.partner/zendesk.com/account/ticket-events. You then write Amazon EventBridge rules on that partner bus to react to Zendesk tickets, PagerDuty incidents, Datadog alerts, Shopify orders, and more. Partner buses are a key reason Amazon EventBridge wins over Amazon SNS for SaaS-heavy workloads.

Cross-Account and Cross-Region Routing

An Amazon EventBridge bus can be a target of another Amazon EventBridge bus — either in the same account (custom bus → custom bus), a different account (via resource policies), or a different Region (via cross-Region targets). A common pattern: each AWS account publishes local events to its own custom bus, then a rule forwards selected events to a central audit bus in a security account. Cross-account Amazon EventBridge routing is the modern replacement for custom SNS cross-account topics and is a recurring DVA-C02 scenario for multi-account architectures.

Amazon EventBridge Rules and Event Patterns

An Amazon EventBridge rule has three parts: the bus it lives on, an event pattern (or a schedule, but modern scheduling goes to EventBridge Scheduler — see later), and up to five targets. When an event hits the Amazon EventBridge bus, the service tests it against every enabled rule's pattern in parallel; every matching rule fires, and every target on those rules receives a copy.

Event Pattern Syntax

An Amazon EventBridge event pattern is a JSON document that mirrors the shape of the event. To match, every top-level field in the pattern must match the corresponding field in the event. Values are arrays — the rule matches if the event's value is in the array. A minimal pattern:

{
  "source": ["com.example.orders"],
  "detail-type": ["OrderPlaced"]
}

Amazon EventBridge supports content filters for richer matching:

• Prefix matching — "region": [{"prefix": "us-"}]
• Suffix matching — "detail-type": [{"suffix": "Created"}]
• Anything-but — "source": [{"anything-but": ["aws.autoscaling"]}]
• Numeric matching — "detail": {"amount": [{"numeric": [">", 1000]}]}
• Exists — "detail": {"customerId": [{"exists": true}]}
• IP address — "detail": {"ip": [{"cidr": "10.0.0.0/8"}]}
• Equals-ignore-case — "detail": {"status": [{"equals-ignore-case": "failed"}]}
• Wildcard — "detail": {"path": [{"wildcard": "/orders/*/refund"}]}

These Amazon EventBridge content filters are dramatically more expressive than Amazon SNS message filter policies, which support only string and numeric equality/range plus exists and anything-but.

Amazon EventBridge Targets — The 30+ Destinations

Amazon EventBridge can invoke more than thirty target types directly, no glue Lambda required. The important ones for DVA-C02:

• AWS Lambda function — invoke with the event as payload. Most common target.
• Amazon SQS queue (standard and FIFO) — durable handoff to a worker fleet.
• Amazon SNS topic — broadcast after Amazon EventBridge routing.
• AWS Step Functions state machine — start a workflow execution.
• Amazon ECS task — run a containerized job.
• Amazon Kinesis Data Streams / Firehose — stream for analytics.
• Amazon EventBridge bus in another account or Region — cross-boundary forwarding.
• API destination — HTTPS endpoint with OAuth/API-key connections, built-in retry with rate limits.
• Amazon SageMaker pipeline, AWS Batch job, CodeBuild project, CodePipeline execution, Systems Manager Run Command and Automation, Redshift cluster data API, EC2 instance CreateSnapshot, and more.

Each Amazon EventBridge target can have its own input transformer that reshapes the event into the exact JSON the target expects, and its own DLQ (an SQS queue) that captures events Amazon EventBridge failed to deliver after retries.

Rule Evaluation Limits

Amazon EventBridge matches events against all rules on a bus in parallel, so adding more rules does not slow down event delivery — a key operational difference from polling-based Amazon SQS architectures. A single Amazon EventBridge rule can have at most 5 targets. The default account-wide limit is 300 rules per bus, but this is a soft quota and AWS raises it on request.

Amazon EventBridge Schema Registry and Auto-Discovery

The Amazon EventBridge schema registry is the feature that most clearly separates Amazon EventBridge from Amazon SNS. It is a versioned catalog of event schemas with code-binding generation, and on DVA-C02 it answers every question about "ensure type safety across teams publishing events."

How Amazon EventBridge Schema Registry Works

A schema in Amazon EventBridge is an OpenAPI 3 or JSONSchema description of an event type — which fields exist, their types, and whether they are required. Amazon EventBridge organizes schemas into registries. AWS maintains one built-in registry, aws.events, containing schemas for every AWS service event. You can also create custom registries for your own event types.

Auto-Discovery

Turn on schema discovery on an Amazon EventBridge bus and Amazon EventBridge watches events for about five minutes, infers the JSON shape of each distinct source + detail-type pair, and writes a schema into the discovered-schemas registry. When a new field appears or an existing field's type changes, Amazon EventBridge creates a new schema version automatically. You no longer hand-maintain an events wiki.

Code Bindings

From any schema, Amazon EventBridge generates downloadable code bindings for Java, Python, TypeScript, Go, and C#/.NET. A developer running aws schemas get-code-binding-source receives a ready-to-import class for that event type. IntelliSense now autocompletes event.detail.orderId, and the compiler rejects event.detail.orderld (lowercase L vs lowercase I typo) at build time. The AWS Toolkit for IntelliJ, PyCharm, VS Code, and Visual Studio downloads Amazon EventBridge code bindings directly from the IDE.

Why This Matters for DVA-C02

Any exam scenario that mentions "multiple teams publishing and consuming shared events need a contract," "downstream service keeps breaking when producers add fields," or "generate strongly typed event classes in the IDE" points to the Amazon EventBridge schema registry. Amazon SNS and Amazon SQS have no comparable feature — they treat payloads as opaque strings.

Amazon EventBridge Archive and Replay

Amazon EventBridge archive and replay is the second feature that Amazon SNS and Amazon SQS simply do not have. It is the time-travel DVR analogy made real.

Creating an Amazon EventBridge Archive

You create an archive on a specific Amazon EventBridge bus. Archive configuration includes:

• A retention period (1 day to indefinite).
• An optional event pattern — only events matching this pattern are archived, letting you archive just OrderPlaced events and skip chatty heartbeat events.
• KMS encryption (default AWS-managed key or customer-managed CMK).

Once active, the Amazon EventBridge archive silently captures every matching event. Archives charge per GB stored.

Replaying Archived Events

A replay re-sends archived events back through the Amazon EventBridge bus within a chosen time window. You pick an archive, a start and end time, and optionally a subset of rules to re-trigger (you can replay to just one rule, leaving the rest untouched). Amazon EventBridge replays at up to the rate the archive was ingested.

Replays are the correct exam answer for:

• "A downstream Lambda had a bug for 48 hours; how do you reprocess the events it mishandled?" — Amazon EventBridge replay.
• "You need to seed a new analytics pipeline with 30 days of historical events." — Amazon EventBridge replay.
• "Audit required: reproduce the exact sequence of events that led to the outage." — Amazon EventBridge replay.

Replayed events carry a marker (replay-name in the event metadata) so target code can behave differently on replays if needed (e.g., skip sending customer emails on replay).

Amazon EventBridge Scheduler — The Cron Replacement

Historically, Amazon EventBridge let you create scheduled rules using cron or rate expressions that fired events to targets on a timer. That feature still exists for backwards compatibility, but AWS extracted scheduling into a dedicated service called Amazon EventBridge Scheduler in late 2022, and DVA-C02 expects you to know it.

Why EventBridge Scheduler Exists

Scheduled rules on Amazon EventBridge have real limits: maximum 300 schedules per account (with the bus's rule quota), no one-time schedules, limited target types, and no built-in retry policy tuning. Amazon EventBridge Scheduler removes all of these:

• Millions of schedules per account (compared to hundreds of rules).
• One-time schedules with at(2026-12-25T09:00:00) expressions — no more "create rule, fire once, delete rule" hacks.
• Flexible time windows that let Amazon EventBridge Scheduler pick any minute in a window to spread load.
• Time zones including daylight-saving awareness — cron(0 9 * * ? *) in America/New_York actually runs at 9am New York time.
• Per-schedule retry policy and DLQ.
• Over 270 target types via the AWS SDK universal targets mechanism.

Schedule Types

Amazon EventBridge Scheduler supports three expression types:

• Rate — rate(5 minutes), rate(1 hour), rate(7 days).
• Cron — standard cron with six fields plus a time zone.
• One-time — at(yyyy-mm-ddThh:mm:ss) for fire-and-forget scheduling.

Targets and Input

Each Amazon EventBridge Scheduler schedule points to exactly one target and can pass a fixed JSON input. Lambda, SQS, SNS, Step Functions, ECS RunTask, EventBridge PutEvents, and any AWS SDK call are valid targets.

Exam-Worthy Scenarios

• "Run a cleanup Lambda every Sunday at 3am New York time" → Amazon EventBridge Scheduler cron with time zone.
• "Schedule a reminder email exactly one hour after a user action" → Amazon EventBridge Scheduler one-time schedule.
• "Trigger 50,000 schedules per day across customers" → Amazon EventBridge Scheduler (not scheduled rules).
• "Spread invoice processing across a 30-minute window to avoid thundering-herd" → Amazon EventBridge Scheduler flexible time window.

Amazon EventBridge Pipes — Producer to Target Without Glue Code

Amazon EventBridge Pipes is the fourth Amazon EventBridge capability that the V2.1 outline elevated. A pipe is a point-to-point integration: one source → optional filter → optional enrichment → one target.

Pipes Sources

Amazon EventBridge Pipes sources are polling sources that previously required Lambda event source mappings or custom consumers:

• Amazon SQS queues.
• Amazon Kinesis Data Streams.
• Amazon DynamoDB Streams.
• Amazon MSK (Managed Streaming for Kafka) and self-managed Apache Kafka.
• Amazon MQ brokers (ActiveMQ and RabbitMQ).

Pipes Filter

A filter uses the same pattern syntax as Amazon EventBridge rules, so only matching messages continue through the pipe. Filtering happens before the pipe bills you for enrichment or target invocation — cost-efficient by design.

Pipes Enrichment

An optional enrichment step calls an enrichment target to transform or augment the message before it hits the final target:

• AWS Lambda — arbitrary code.
• AWS Step Functions (Express workflows only) — short orchestrations.
• Amazon API Gateway — hit your own HTTP endpoint.
• Amazon EventBridge API destinations — hit a third-party HTTPS endpoint with authentication.

Pipes Targets

Pipes targets are the same universe as Amazon EventBridge rule targets — Lambda, Step Functions, SQS, SNS, Kinesis, Firehose, ECS, EventBridge bus, API destination, and more.

When to Use Amazon EventBridge Pipes

The clearest DVA-C02 scenario for Amazon EventBridge Pipes: "You have an SQS queue feeding a Lambda that filters messages, calls an internal API to enrich them, and starts a Step Functions workflow." Without Amazon EventBridge Pipes, that is a Lambda with three responsibilities and a pager. With Amazon EventBridge Pipes, it is one managed pipe with filter + enrichment + target — no Lambda code to maintain.

Amazon SNS — Simple Pub/Sub at Scale

Amazon SNS is still on the DVA-C02 exam — but its role has narrowed to "simple fan-out at very high throughput without Amazon EventBridge features." Understanding Amazon SNS as comparison to Amazon EventBridge is the fastest way to answer the "SNS or EventBridge?" questions.

Amazon SNS Topics

An Amazon SNS topic is a pub/sub channel. Publishers call Publish with a message and optional attributes. Subscribers are SQS queues, Lambda functions, HTTPS endpoints, email addresses, SMS numbers, mobile push endpoints (APNs, FCM), Kinesis Data Firehose streams, or another AWS account's resources. One message published to an Amazon SNS topic fans out to every subscriber in parallel — this is the definition of fan-out.

Amazon SNS supports two topic types:

• Standard topics — at-least-once delivery, best-effort ordering, nearly unlimited throughput, supports all subscriber types.
• FIFO topics — exactly-once delivery, strict ordering per message group, up to 300 publishes per second (or 3,000 with batching), subscribers limited to SQS FIFO queues.

Amazon SNS Message Filtering

Amazon SNS subscription filter policies let each subscriber receive only a subset of the topic's messages based on message attributes (or, with payload-based filtering, the JSON body). Operators include string equality, prefix, anything-but, numeric ranges, exists, and CIDR. Important: Amazon SNS filter policies are simpler than Amazon EventBridge event patterns — no suffix, no wildcard, no equals-ignore-case. If a scenario needs any of those, it is an Amazon EventBridge scenario.

Amazon SNS Fan-Out to Amazon SQS

The canonical pattern: publisher → Amazon SNS topic → multiple Amazon SQS queues, one per downstream microservice. Each microservice polls its own queue at its own pace, with its own DLQ and visibility timeout. This pattern decouples producers from consumers and is still a right answer on DVA-C02 when the scenario emphasizes durability, independent consumer pace, and "every consumer gets every message." If the scenario instead emphasizes content-based routing, schemas, or replay, switch to Amazon EventBridge.

When Amazon SNS Still Wins Over Amazon EventBridge

• Mobile push, SMS, email — Amazon EventBridge cannot deliver to those channels. Amazon SNS is the only option.
• Maximum raw throughput at lowest cost — Amazon SNS standard topics cost $0.50 per million publishes; Amazon EventBridge custom bus costs $1.00 per million. At billions of events/month, the delta matters.
• Ultra-simple fan-out — every subscriber gets every message, no filtering needed, no schema registry. Amazon SNS is simpler.

Amazon SQS — The Durable Work Queue

Amazon SQS is the oldest AWS integration service and remains the right answer for durable, decoupled work queues. On DVA-C02 the exam tests four Amazon SQS mechanics in particular: visibility timeout, dead-letter queues, long polling, and the Standard-vs-FIFO choice.

Standard vs FIFO Amazon SQS Queues

• Standard queues — at-least-once delivery, best-effort ordering, unlimited throughput. Duplicates and out-of-order delivery are possible and your consumer must be idempotent.
• FIFO queues — exactly-once processing (5-minute deduplication window), strict FIFO ordering per message group, up to 3,000 messages/second with batching (or 300/second without). Use when order matters or duplicates are catastrophic.

Amazon SQS Visibility Timeout

When a consumer calls ReceiveMessage, Amazon SQS hides the message from other consumers for the visibility timeout (default 30 seconds, max 12 hours). The consumer must call DeleteMessage before the timeout expires; otherwise the message becomes visible again and another consumer will pick it up — and now the first consumer might also complete, processing the same message twice. Tuning visibility timeout to "a bit longer than your worst-case processing time" is the developer's job. For long jobs, call ChangeMessageVisibility to extend the lock.

Amazon SQS Dead-Letter Queues (DLQ)

A DLQ is a separate Amazon SQS queue that receives messages a source queue failed to process after maxReceiveCount attempts. DLQs let you inspect poisoned messages without losing them and prevent one bad message from blocking the queue forever. Always configure a DLQ on production Amazon SQS queues — this is a DVA-C02 best-practice question every cycle. A DLQ's type must match its source queue (FIFO source → FIFO DLQ).

Amazon SQS Long Polling

Amazon SQS supports short polling (default — ReceiveMessage returns immediately, possibly with zero messages) and long polling (WaitTimeSeconds 1–20; the call waits up to that many seconds for a message to arrive). Long polling reduces empty responses, reduces API cost, and reduces consumer CPU waste. Configure long polling at the queue level (ReceiveMessageWaitTimeSeconds) or per-request. Exam rule: "reduce polling cost" → long polling.

Amazon SQS Integration with Amazon EventBridge

Amazon SQS is one of Amazon EventBridge's most common targets. Pattern: Amazon EventBridge rule matches events, routes them to an SQS queue, downstream consumer (Lambda, ECS) processes from the queue with its own visibility timeout and DLQ. Amazon SQS also shows up as an Amazon EventBridge target DLQ — when Amazon EventBridge cannot deliver an event to a target after retries, it drops that event into the configured Amazon SQS DLQ.

AWS Step Functions — Orchestration with Retry

AWS Step Functions is the right answer whenever the DVA-C02 scenario describes "multi-step workflow," "retry on failure," "wait for human approval," "parallel branches," or "long-running process." Amazon EventBridge routes events; AWS Step Functions orchestrates processes.

Standard vs Express Workflows

• Standard workflows — up to 1 year duration, exactly-once execution, full execution history in CloudWatch Logs, at most 2,000 executions/second started. Best for business processes, order fulfillment, human approvals.
• Express workflows — up to 5 minutes duration, at-least-once execution, very high throughput (100,000 executions/second), minimal history unless explicitly logged. Best for high-volume event processing, IoT pipelines, streaming transformation.

Amazon States Language (ASL)

Workflows are defined in ASL, a JSON-based DSL. Core state types:

• Task — does work (invoke Lambda, run ECS task, call AWS SDK, call API destination).
• Choice — branch on input fields.
• Parallel — run multiple branches concurrently, wait for all.
• Map — iterate over an array, optionally in parallel (Distributed Map mode supports up to 10,000 concurrent executions and processes up to 100 million items from S3).
• Wait — pause for a duration or until a timestamp.
• Pass — no-op (testing, data reshaping).
• Succeed / Fail — terminal states.

Error Handling — Retry and Catch

Every Task and Parallel state can declare:

• Retry — list of error matchers with per-matcher backoff, max attempts, and jitter. Example: retry States.Timeout up to 3 times with 2-second initial interval and backoff factor 2.0.
• Catch — list of error matchers that route the execution to a fallback state on failure. Example: catch CustomError.InsufficientFunds and transition to SendApologyEmail.

This built-in retry/catch is why Step Functions beats "just chain Lambdas with SQS." You get declarative error handling without writing retry loops, and every retry is visible in the execution history.

Service Integrations and .sync / .waitForTaskToken

Step Functions integrates natively with 200+ AWS services via optimized integrations (shortcut ARNs like arn:aws:states:::lambda:invoke). Two special invocation modes matter on DVA-C02:

• .sync — Step Functions calls the service and waits for it to finish. Example: arn:aws:states:::ecs:runTask.sync runs an ECS task and waits for the task to exit before the next state begins.
• .waitForTaskToken — Step Functions pauses the execution and emits a task token; downstream code (human approval UI, external system, another Lambda) calls SendTaskSuccess or SendTaskFailure with that token to resume the workflow. This is the canonical pattern for human approval and callback-style integrations.

Step Functions as an Amazon EventBridge Target

Amazon EventBridge rules can start a Step Functions state machine directly as a target. The event becomes the workflow input. This is the clean DVA-C02 pattern: Amazon EventBridge handles routing, Step Functions handles the multi-step logic. You do not need a Lambda in between.

Amazon EventBridge vs SNS vs SQS vs Step Functions — The Decision Tree

Here is the decision tree DVA-C02 expects you to apply on every application-integration question.

Step 1 — Is It an Event or a Message?

• Event (something happened; receivers decide what to do) → Amazon EventBridge or Amazon SNS.
• Message (work for someone to do; recipient is specific) → Amazon SQS.
• Multi-step process (sequence of actions with state) → AWS Step Functions.

Step 2 — Event Path: Do You Need Filtering, Schemas, Replay, or SaaS Sources?

• Yes, any of those → Amazon EventBridge.
• No, just fan out to many subscribers at high throughput → Amazon SNS.
• Need mobile push / SMS / email delivery → Amazon SNS (Amazon EventBridge cannot).

Step 3 — Message Path: Ordering and Duplicates Critical?

• Yes, strict order and no duplicates → Amazon SQS FIFO.
• No, throughput matters more → Amazon SQS Standard.
• Connecting SQS to a target without writing Lambda glue → Amazon EventBridge Pipes.

Step 4 — Workflow Path: How Long and How Fast?

• Up to 1 year, exactly-once, audit-ready → Step Functions Standard.
• Under 5 minutes, very high throughput → Step Functions Express.
• Need human approval step → Step Functions .waitForTaskToken.

Step 5 — Scheduling

• Cron-style or one-time schedule → Amazon EventBridge Scheduler.
• "Every 5 minutes" polling-style with a scheduled rule → still works, but prefer Amazon EventBridge Scheduler for new builds.

Cross-Account Amazon EventBridge Routing in Depth

Multi-account architectures are common on DVA-C02. Amazon EventBridge supports cross-account routing two ways: granting another account permission to put events to your bus, or targeting another account's bus from a rule in your bus.

Pattern A — Remote Account Puts Events to Your Bus

Attach a resource policy to your Amazon EventBridge custom bus that grants events:PutEvents to the remote account's principal. The remote account calls PutEvents with EventBusName set to your bus's ARN. Your rules then process those events normally.

Pattern B — Your Rule Targets a Bus in Another Account

Your rule in account A lists an Amazon EventBridge bus in account B as its target. Account B's bus must have a resource policy allowing events:PutEvents from account A's rule role. Account A's rule needs an IAM role Amazon EventBridge can assume to call PutEvents across the boundary.

Typical use case: each workload account publishes local events to its own custom bus; a central security/audit bus in a dedicated account receives a forwarded copy for compliance and observability.

Integration Patterns and Examples

Three canonical DVA-C02 integration patterns put everything together.

Pattern 1 — Order Placed Fans Out via Amazon EventBridge

Checkout service calls PutEvents on custom bus orders-prod with source: com.example.orders, detail-type: OrderPlaced. Rules on that bus:

1. Rule "notify-customer" — target Lambda that sends a confirmation email.
2. Rule "charge-payment" — target Step Functions Standard workflow that calls the payment provider with retry/catch.
3. Rule "analytics" — target Kinesis Data Firehose delivering to S3.
4. Rule "audit" — target Amazon EventBridge bus in the security account.

The Amazon EventBridge schema registry auto-discovers the OrderPlaced schema and hands code bindings to every team. An archive captures OrderPlaced events for 90 days so engineering can replay if a downstream service had a bug.

Pattern 2 — SQS to Step Functions via Amazon EventBridge Pipes

Inbound webhook handler writes work items to an Amazon SQS queue. A pipe has the queue as source, filters out heartbeat messages with an event pattern, enriches each work item by calling an internal pricing API through an API destination, and targets a Step Functions Express workflow that runs the actual work. Zero glue Lambda, filter + enrichment + target all declarative.

Pattern 3 — Scheduled Cleanup with Amazon EventBridge Scheduler

A schedule cron(0 3 ? * SUN *) in time zone America/Los_Angeles fires every Sunday at 3am Pacific, targeting a Step Functions Standard workflow that deletes expired sessions across 12 microservice databases in parallel with per-branch error handling. The schedule has its own retry policy and an SQS DLQ for failures.

Common DVA-C02 Traps

Trap 1 — Assuming Amazon SNS Equals Amazon EventBridge

Amazon SNS does pub/sub; Amazon EventBridge does pub/sub plus schemas, archive/replay, SaaS partner ingestion, content filters with wildcards, API destinations, and Scheduler. Any scenario mentioning schema, replay, SaaS source, or API destination is Amazon EventBridge, not Amazon SNS.

Trap 2 — Forgetting Amazon SQS Long Polling

"Reduce polling cost" is always long polling. Short polling burns money and CPU. Set ReceiveMessageWaitTimeSeconds to 20 for production Amazon SQS consumers unless there is a reason not to.

Trap 3 — Using a Chain of Lambdas Instead of Step Functions

If the scenario describes three Lambdas calling each other with error handling, the right answer is AWS Step Functions, not "SQS between each Lambda." Step Functions gives declarative retry/catch, full execution history, and visual debugging.

Trap 4 — Mixing Up Amazon EventBridge Rules and Amazon EventBridge Pipes

Rules are push-based and live on buses; Pipes are polling-based and connect a single source (SQS, Kinesis, DynamoDB Streams, MSK, MQ) to a single target.

Trap 5 — Using Scheduled Rules Instead of Amazon EventBridge Scheduler

Scheduled rules still work, but Amazon EventBridge Scheduler supports millions of schedules, one-time schedules, flexible time windows, time zones, and 270+ targets. New builds should use Amazon EventBridge Scheduler.

Trap 6 — Missing the DLQ

Every Amazon EventBridge target, every Amazon SQS queue, and every EventBridge Pipes target should have a DLQ configured in production. DVA-C02 loves "why did these events get lost?" scenarios where the correct answer is "configure a DLQ."

Trap 7 — Confusing Visibility Timeout and Message Retention

Visibility timeout is how long a message is hidden after ReceiveMessage (max 12 hours). Message retention is how long unprocessed messages stay in the queue (1 minute to 14 days). They are unrelated numbers.

Key Numbers and Limits to Memorize

• Amazon EventBridge PutEvents max entry size: 256 KB per event.
• Amazon EventBridge max targets per rule: 5.
• Amazon EventBridge default quota: 300 rules per bus (soft).
• Amazon EventBridge Scheduler: millions of schedules per account.
• Amazon EventBridge archive retention: 1 day to indefinite.
• Amazon SQS message size: 256 KB (up to 2 GB with Extended Client Library using S3).
• Amazon SQS retention: 1 minute to 14 days (default 4 days).
• Amazon SQS visibility timeout: 0 seconds to 12 hours (default 30 seconds).
• Amazon SQS long polling max wait: 20 seconds.
• Amazon SQS FIFO throughput: 300 msg/s without batching, 3,000 msg/s with.
• Amazon SNS Standard publish rate: effectively unlimited; FIFO: 300/s (3,000 with batching).
• Step Functions Standard duration: up to 1 year; Express: up to 5 minutes.
• Step Functions Distributed Map: up to 10,000 concurrent child executions, up to 100M S3 items.

Cost Model Quick Reference

• Amazon EventBridge custom/partner bus: $1.00 per million events published.
• Amazon EventBridge default bus: AWS service events are free; cross-Region and API destination invocations still charge.
• Amazon EventBridge Scheduler: $1.00 per million schedule invocations.
• Amazon EventBridge Pipes: $0.40 per million messages processed.
• Amazon SNS Standard: $0.50 per million publishes.
• Amazon SQS Standard: $0.40 per million requests.
• AWS Step Functions Standard: $0.025 per 1,000 state transitions.
• AWS Step Functions Express: per-execution pricing based on duration and memory.

Exact numbers shift — the pattern matters more: Amazon EventBridge costs more per event than Amazon SNS, but Amazon EventBridge replaces Lambda glue you would otherwise pay for, so total-cost-of-ownership often favors Amazon EventBridge.

Frequently Asked Questions

Q1: When should I pick Amazon EventBridge over Amazon SNS?

Pick Amazon EventBridge whenever the scenario needs content-based routing on event attributes, schema validation via the Amazon EventBridge schema registry, event archive and replay, SaaS partner event sources (Zendesk, Datadog, PagerDuty, Shopify), or API destinations for outbound HTTPS calls. Pick Amazon SNS for simple fan-out at maximum throughput, or when subscribers include mobile push, SMS, or email — Amazon EventBridge does not deliver to those directly. On DVA-C02, the modern default is Amazon EventBridge unless the scenario explicitly names an Amazon SNS-only channel or emphasizes raw cost/throughput for trillions of events.

Q2: How does Amazon EventBridge Pipes differ from Amazon EventBridge rules?

Amazon EventBridge rules are push-based and live on an Amazon EventBridge bus — producers call PutEvents, and rules evaluate event patterns on published events, sending matches to up to five targets. Amazon EventBridge Pipes are polling-based — a pipe continuously polls a single source (Amazon SQS, Kinesis Data Streams, DynamoDB Streams, Amazon MSK, self-managed Kafka, or Amazon MQ), optionally filters and enriches messages, and sends each one to a single target. Rules are for event-bus architectures; Pipes are for connecting stream and queue sources to targets without writing Lambda glue code.

Q3: What is the difference between Amazon EventBridge Scheduler and scheduled rules?

Both fire a target on a cron or rate expression. Amazon EventBridge Scheduler is the newer, dedicated service with big advantages: millions of schedules per account (rules are capped in the hundreds per bus), one-time schedules with at(...) expressions, flexible time windows that spread load across a window, time-zone-aware cron with daylight-saving handling, per-schedule retry and DLQ policies, and 270+ target types via the universal targets mechanism. New builds should use Amazon EventBridge Scheduler; scheduled rules remain for backwards compatibility. On DVA-C02, scenarios emphasizing "millions of schedules," "one-time reminder," "time zone," or "flexible window" always point to Amazon EventBridge Scheduler.

Q4: How do Amazon EventBridge archive and replay work, and what are they not?

An Amazon EventBridge archive captures events matching an optional pattern on a specific bus for a configured retention period (1 day to indefinite) with KMS encryption. A replay re-sends archived events through the bus within a chosen time window, to one or more selected rules. Replay is for reprocessing after a bug fix, seeding a new consumer with history, or reproducing an incident. Replay is not a backup of target state, not a way to modify events in flight, and not available on Amazon SNS or Amazon SQS. Replayed events carry a replay-name marker so target code can detect them.

Q5: When do I use AWS Step Functions instead of Amazon EventBridge?

Amazon EventBridge routes events to targets based on rules — it is stateless routing. AWS Step Functions runs a stateful, multi-step workflow with branches, parallel sections, retries, catches, and optional human approval via task tokens. If the scenario is "event happened, invoke one or a few targets," use Amazon EventBridge. If the scenario is "orchestrate 5 Lambdas, wait for a human approval, retry the payment step 3 times, and run this for up to a week," use AWS Step Functions. In practice you combine them: Amazon EventBridge routes events, and one target is a Step Functions state machine that runs the actual workflow.

Q6: How do I handle failures in Amazon EventBridge?

Amazon EventBridge retries target invocation with exponential backoff for up to 24 hours by default. If all retries fail, Amazon EventBridge drops the event unless you configured a dead-letter queue on the target (an Amazon SQS queue). Always configure a DLQ on production Amazon EventBridge targets. For Amazon EventBridge Pipes, both the source poll and the target invocation support retry policies and DLQs. For scheduled rules and Amazon EventBridge Scheduler, configure per-schedule retry and DLQ. Combined with AWS Step Functions retry/catch on each task state, this gives end-to-end failure handling across the whole integration.

Q7: Can Amazon EventBridge replace Amazon SQS and Amazon SNS entirely?

No, and the DVA-C02 exam tests this. Amazon EventBridge is a router, not a durable work queue. If a consumer is offline for hours and must not lose work items, you still need Amazon SQS — messages sit in the queue until the consumer returns. Amazon EventBridge can target an Amazon SQS queue (that is the common pattern), but Amazon EventBridge itself does not store events for slow consumers beyond its own retry window. Similarly, Amazon SNS is still the right answer for fan-out that includes mobile push, SMS, or email — channels Amazon EventBridge does not support as targets. Modern architectures use all three: Amazon EventBridge for routing, Amazon SQS for durable buffering, Amazon SNS for simple fan-out to notification channels.

Q8: What is the cross-account story for Amazon EventBridge on DVA-C02?

Amazon EventBridge supports two cross-account patterns. First, another account can PutEvents directly to your custom bus if your bus's resource policy grants that principal. Second, your rule can target an Amazon EventBridge bus in another account — your rule role needs events:PutEvents on the target ARN, and the target bus's resource policy must trust your role. A common DVA-C02 scenario: each workload account publishes to its own custom bus, and a central security account's audit bus receives forwarded copies via cross-account rules for centralized compliance.

Summary — What to Remember for DVA-C02

Amazon EventBridge is the main character of DVA-C02 application integration. Master its vocabulary — event, rule, target, bus — then layer on schema registry, archive and replay, Amazon EventBridge Scheduler, Amazon EventBridge Pipes, and cross-account routing. Around Amazon EventBridge, keep three supporting actors close: Amazon SNS for simple high-throughput pub/sub and mobile/SMS/email delivery, Amazon SQS for durable work queues with visibility timeout and DLQ, and AWS Step Functions for stateful multi-step workflows with retry and human approval. Apply the decision tree on every exam question: event or message or workflow, then filter by filtering/schema/replay needs, ordering requirements, or workflow duration. Remember the key numbers — 256 KB event size, 300 rules per bus, 14-day max Amazon SQS retention, 20-second max long poll, 1-year Standard workflow, 5-minute Express workflow. Configure a DLQ everywhere. When in doubt about the modern answer, pick Amazon EventBridge.