Amazon DVA-C02: Messaging, Streaming & Event-driven Architectures (SNS, SQS, Kinesis, EventBridge, Step Functions) — Study Guide

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Part of the AWS Developer Associate DVA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

Choosing the right messaging and streaming primitive

Picking between SNS, SQS (standard vs FIFO), Kinesis, EventBridge, and Step Functions starts with the communication pattern: pub/sub, point-to-point, ordered streaming, event bus routing, or workflow orchestration. SNS is a fan-out pub/sub publisher; use Publish (SDK call: Publish/PublishBatch) and subscribe SQS endpoints, Lambda, HTTP/S, or mobile endpoints. SQS is durable point-to-point buffer with ReceiveMessage/DeleteMessage semantics; create queues with CreateQueue and attributes like VisibilityTimeout, ReceiveMessageWaitTimeSeconds (long polling), MessageRetentionPeriod, and redrive policies linking a DLQ. FIFO queues require FifoQueue=true and use MessageGroupId plus MessageDeduplicationId (or ContentBasedDeduplication) for ordering and dedupe. Kinesis Data Streams is ordered, shard-based streaming; producers call PutRecord/PutRecords and consumers use GetShardIterator (TRIM_HORIZON, LATEST, AT_SEQUENCE_NUMBER) then GetRecords. Kinesis Firehose manages delivery to S3/Redshift/OpenSearch and offers BufferingHints (SizeInMBs, IntervalInSeconds) and Lambda transforms. EventBridge routes events with PutEvents and rule-based filtering, supports schema registry and cross-account buses. Step Functions orchestrate complex flows; StartExecution (Standard) or StartSyncExecution for synchronous Express patterns, with Task integrations like arn:aws:states:::lambda:invoke. Consider these tradeoffs when throughput, ordering, delivery guarantees, retention, and orchestration needs conflict.

• SNS: high-throughput fan-out, no ordering, Publish/Subscribe, use MessageAttributes for routing.
• SQS Standard: at-least-once, best-effort ordering, long polling, cheaper for decoupling.
• SQS FIFO: exactly-once ordering within MessageGroupId, use for strict ordering and dedupe.
• Kinesis Data Streams: ordered per-shard, high-throughput streaming, PutRecord/PutRecords, shard scaling required.
• Kinesis Firehose: managed delivery and buffering, supports server-side encryption and Lambda transforms.
• EventBridge: event bus with routing rules, schema registry, archive & replay, PutEvents API.
• Step Functions: stateful orchestration, retries/Catch, Standard vs Express tradeoffs for durability and throughput.

SQS and SNS patterns, deduplication, and consumer scaling

When you need durable decoupling, SQS is the go-to choice; implement SendMessage/SendMessageBatch for producers and use ReceiveMessage with WaitTimeSeconds to enable long polling and reduce empty receives. For strict ordering and deduplication, create a FIFO queue with CreateQueue (FifoQueue=true) and set MessageGroupId for ordered partitions; use MessageDeduplicationId or enable ContentBasedDeduplication so identical payloads within the deduplication window are suppressed. Standard queues may deliver duplicates — therefore make consumers idempotent via database conditional writes (DynamoDB PutItem with ConditionExpression attribute_not_exists(pk)) or RDS unique constraints and upserts within transactions. Configure redrive policies to route failing messages to a DLQ after maxReceiveCount; monitor ApproximateNumberOfMessages and ApproximateNumberOfMessagesNotVisible via GetQueueAttributes. Lambda integrations use CreateEventSourceMapping for SQS: set BatchSize, MaximumBatchingWindowInSeconds, and enable FunctionResponseTypes = [“ReportBatchItemFailures”] to use partial-batch-response semantics and avoid reprocessing succeeded records. Beware FIFO Lambda semantics: message group ordering enforces single-threaded processing per MessageGroupId, limiting per-group concurrency; scale by partitioning into many group IDs or using parallel consumers with SNS to multiple queues. Also mind visibility timeout: set ChangeMessageVisibility when processing takes longer or you risk duplicate processing.

Kinesis Data Streams and Firehose: ordering, retention, and back-pressure handling

Kinesis Data Streams provide per-shard ordering and durable retention for streaming use cases. Producers call PutRecord or PutRecords (batch) with a PartitionKey that maps to a shard; consumers call GetShardIterator and GetRecords, then checkpoint offsets using KCL (Kinesis Client Library) or a custom DynamoDB checkpoint table. Default retention is 24 hours (adjustable to longer windows per stream configuration, and extended retention features where available); plan shard counts with UpdateShardCount to match write throughput and reader parallelism. Consumer scaling is constrained: a single Lambda event source mapping maps one shard to one Lambda concurrency, so increase shards to increase consumer concurrency or enable enhanced fan-out to give each consumer its own 2 MB/sec pipe and independent scaling using SubscribeToShard API (consumer registration). Use PutRecords for efficient batching; back-pressure arises when consumers lag (Monitor GetRecords.IteratorAgeMilliseconds). To handle spikes, buffer on Kinesis or front with SQS, use Producer retries with exponential backoff, and use stream-level encryption with KMS for PII. Kinesis Data Firehose simplifies delivery: configure BufferingHints (SizeInMBs, IntervalInSeconds), CompressionFormat, and a Lambda data transformation. Firehose handles retry/backoff to destinations and can write failed records to a backup S3 bucket. A common trap is under-provisioning shards: consumers starve and latency spikes; measure and scale proactively.

EventBridge and Step Functions for routing and orchestration

EventBridge excels at schema-driven event routing and cross-account/event partner integrations using PutEvents to inject events and PutRule/PutTargets to route to SQS, Lambda, Kinesis, Step Functions, or HTTP endpoints. EventBridge uses event patterns for filtering and supports archiving and replay to rebuild state. Use dead-letter queues for rules (Target with SqsParameters or DeadLetterConfig) and be aware EventBridge provides retries with exponential backoff then DLQ on failure. For orchestration, choose Step Functions: Standard state machines for long-running durable workflows with execution history and built-in retries/Catch, and Express for high-throughput short-lived workflows with lower cost and best-effort execution. Use Task integrations with service integrations (arn:aws:states:::lambda:invoke or arn:aws:states:::aws-sdk:apigateway:invoke) and callback patterns using “waitForTaskToken” to implement asynchronous external approvals. Implement retries and Catch with exponential backoff and use HeartbeatSeconds for long tasks. Use Map state to parallelize large collections, but watch concurrency and downstream throttles. A typical pitfall is mischoosing Express for workflows that require exactly-once durable history — pick Standard for auditability. Also, ensure idempotency in tasks invoked by Step Functions by passing an idempotency token and having target services enforce uniqueness at write time.

Practical Problem: Use-Case Scenario

Scenario: StreamlyGames operates a global gaming backend in a multi-account AWS environment. Players upload 10 MB gameplay clips to S3; a processing pipeline must transcode videos, run ML analysis, and write results to Aurora Serverless with ordered, deduplicated processing and scalable consumers.

Challenge: Ensure each uploaded file triggers exactly-once processing in order per player, handle spikes without losing events, and scale consumers for ML inference while preventing duplicate DB writes.

Recommended Approach:

1. Create an S3 event notification to publish object-created events to an EventBridge custom bus (PutEvents) and also to an SQS FIFO queue (CreateQueue with FifoQueue=true) keyed by PlayerID as MessageGroupId and using MessageDeduplicationId based on S3 ETag.
2. Configure a Lambda consumer with an SQS event source mapping (CreateEventSourceMapping) using BatchSize=1, FunctionResponseTypes=[“ReportBatchItemFailures”], and set VisibilityTimeout > max processing time; use ChangeMessageVisibility when calling third-party ML APIs.
3. Lambda performs idempotent DB writes to Aurora using a deterministic idempotency key (INSERT … ON CONFLICT DO NOTHING or unique constraint) and checkpoints progress; for long ML calls use asynchronous Step Functions with task tokens (arn:aws:states:::lambda:invoke.waitForTaskToken) or Step Functions Express for high throughput.
4. To scale inference, write intermediate events to Kinesis Data Streams per shard per region for high-throughput consumers and enable enhanced fan-out consumers (SubscribeToShard) for dedicated ML worker fleets; monitor IteratorAgeMilliseconds and UpdateShardCount to scale.

Rationale: Use SQS FIFO to guarantee ordering per player and deduplication at ingestion, idempotent DB writes to enforce exactly-once semantics, and Kinesis plus enhanced fan-out or Step Functions to handle bursty, high-throughput ML processing while keeping consumers decoupled and scalable.

← Databases · All domains

Practice these questions → · Timed practice on ExamRoll.io →

Browse Amazon →