SAP-C02
Deep Dive
Domain D2 (29%) covers designing new cloud-native solutions. Event-driven architectures are the core pattern for decoupled, scalable systems in AWS at the professional level.
Contents
Fan-out
One event triggers multiple independent consumers in parallel. SNS → multiple SQS queues or Lambda functions.
Order created → notify inventory + billing + customer email
Event Choreography
Each service reacts to events and emits new events. No central orchestrator. More decoupled but harder to observe.
Microservices that publish and consume from EventBridge without knowing about each other
Event Orchestration
A central orchestrator (Step Functions) drives the flow by calling services in sequence. Better visibility but tighter coupling.
Step Functions runs Lambda → DynamoDB → SES → notifies the user
EventBridge is AWS's serverless event bus. It receives events from AWS services, SaaS partners and your own applications, filters them with pattern-based rules, and routes them to targets. Formerly known as CloudWatch Events.
Event Bus
The channel events flow through. There's a "default" bus by default (AWS service events). You can create custom buses for your own apps and SaaS.
Rules
JSON pattern filters that determine which events go to which targets. Supports advanced content-based filtering.
Targets
20+ targets: Lambda, SQS, SNS, Step Functions, Kinesis, ECS Task, SSM, CodePipeline, cross-account event bus and more.
Schema Registry
Registers and versions the schema (format) of events. Auto-generates binding code.
Pipes
Point-to-point integration with transformation and enrichment: source → filter → enrich → target.
| EventBridge | SNS |
|---|---|
| Content-based filtering on the event | Filtering by message attributes (limited) |
| Routing to 20+ target types | Targets: Lambda, SQS, HTTP, email, SMS |
| Schema Registry with code generation | No schema registry |
| Events from 200+ SaaS partners | AWS production events only |
| Cross-account and cross-region natively | Cross-account via resource policy |
| Latency ~1s (slower) | Sub-second latency (faster) |
EventBridge Scheduler
EventBridge Scheduler (not to be confused with cron-type Rules) lets you create one-time or recurring schedules to invoke targets. Supports millions of schedules per account with flexible execution windows. Replaces using CloudWatch Events + Lambda for scheduling.
Step Functions is AWS's orchestration service. It defines workflows (state machines) in Amazon States Language (ASL/JSON) that coordinate multiple AWS services with retry logic, branching, error handling and parallelism.
| Feature | Standard Workflows | Express Workflows |
|---|---|---|
| Max duration | Up to 1 year | Up to 5 minutes |
| Concurrent executions | 2,000 (default) | Over 100,000/sec |
| Execution semantics | Exactly-once | At-least-once |
| Cost model | Per state transition | Per duration + number of executions |
| Auditable history | Yes — CloudWatch and Step Functions console | CloudWatch Logs only |
| Best for | Orders, approvals, critical flows | IoT, streaming, high concurrency |
Task
Invokes an AWS service (Lambda, ECS, DynamoDB, etc.) or runs activities.
Choice
Conditional branching based on state variables.
Parallel
Runs multiple branches in parallel and waits for all to complete.
Map
Iterates over an array, processing each item in parallel.
Wait
Pauses the workflow until a date/time or external signal.
Pass/Fail/Succeed
State manipulation, error handling and termination.
SDK Integrations (Optimized) vs Lambda Invoke
Step Functions has native integrations with 200+ AWS service APIs without needing Lambda as a go-between. For example, invoking DynamoDB:PutItem directly from a Task state. This reduces latency and cost vs using Lambda just to call another service.
| Service | Model | Retention | Consumption | Best for |
|---|---|---|---|---|
| Kinesis Data Streams | Pub/Sub streaming | 24h–365 days | KCL, Lambda, SDK — you manage the consumers | Real-time processing with full consumer control. Multiple consumers of the same stream. |
| Amazon Data Firehose | Managed ETL | None (direct delivery) | Automatic — delivers to S3, Redshift, OpenSearch, Splunk | Automatic ingestion and delivery to analytics destinations with no code. |
| Managed Service for Apache Flink | Streaming queries | Processes in real time | Flink (Java, Python, or Flink SQL) over KDS or MSK | Analysis and transformation of streams with SQL or Apache Flink. |
| Kinesis Video Streams | Video streaming | Configurable | SDK, HLS, DASH, WebRTC | Ingesting and processing video from cameras/IoT devices. |
Kinesis Data Streams — capacity concepts
Kinesis vs SQS — design decision
Do multiple consumers need to read the same data?
→ Kinesis (native fan-out)
Do you need guaranteed order within a key?
→ Kinesis (same shard)
Do you need to replay historical data?
→ Kinesis (retention up to 365 days)
Must each message be processed exactly once?
→ SQS (exactly-once with deduplication)
Simple point-to-point decoupling?
→ SQS (simpler to manage)
Real-time time-series analysis?
→ Managed Service for Apache Flink + KDS
SNS — advanced patterns for SAP-C02
SNS Message Filtering
Each SQS/Lambda subscription can have a JSON filter policy. It only receives messages matching the message attributes. Avoids routing every message to every consumer.
SNS FIFO + SQS FIFO
For fan-out with guaranteed order and exactly-once delivery. SNS FIFO → multiple SQS FIFO queues. Each queue receives messages in the same order.
SNS + DLQ
SQS subscriptions can have a Dead Letter Queue for messages that can't be delivered after multiple attempts.
SQS — high-level features
| Scenario | Recommended service | Reason |
|---|---|---|
| Decouple microservices with independent workers | SQS | Simple queue, at-least-once, easy to scale with Lambda or ASG |
| Fan-out: one event → multiple parallel processors | SNS + SQS (fan-out pattern) | SNS distributes the same message to multiple SQS queues |
| React to AWS service events (EC2 stop, S3 upload) | EventBridge (default bus) | Default bus receives native events from 200+ AWS services |
| Integrate with Salesforce, Zendesk, Datadog | EventBridge (SaaS bus) | EventBridge has native integrations with 200+ SaaS partners |
| Orchestrate a multi-step process with retry and compensation | Step Functions | Flow visualization, automatic retry, exactly-once with Standard |
| Process a real-time clickstream/IoT stream | Kinesis Data Streams | Retention, replay, multiple consumers, order by partition key |
| Deliver logs/events to S3 or Redshift without code | Amazon Data Firehose | Managed delivery with optional Lambda transformation |
| Analyze a real-time stream with SQL | Managed Service for Apache Flink | Managed Flink SQL over KDS or MSK |
Trap: "EventBridge and CloudWatch Events are different services"
Reality: They're the same service. EventBridge is the evolution of CloudWatch Events. The concepts are identical; EventBridge just has more features.
Trap: "Step Functions Standard always guarantees exactly-once"
Reality: Standard guarantees exactly-once for activity and Lambda invocations. Express is at-least-once. Both have configurable retries.
Trap: "Amazon Data Firehose supports multiple consumers like Kinesis Streams"
Reality: FALSE. Firehose delivers to a single destination (S3, Redshift, OpenSearch, etc.). For multiple consumers of the same stream, use Kinesis Data Streams.
Trap: "SQS FIFO always guarantees exactly-once"
Reality: FIFO guarantees exactly-once within the 5-minute deduplication window using MessageDeduplicationId. Without that ID configured, duplicates can occur.
Did you get this topic?
Test what you just learned
An e-commerce company processes 50,000 orders per hour. When an order is created, they need to: (1) update inventory, (2) generate the invoice, (3) send a confirmation email, and (4) publish the event to the Data Warehouse. All in parallel. Operations must be idempotent. What is the most appropriate architecture?
Put what you learned to the test with original SAP-C02 exam questions.
Start SAP-C02 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.