Application Integration
Queues, topics, event buses, and workflow orchestration that let distributed components talk to each other without being tightly coupled.
Amazon EventBridge
Serverless event bus that routes events from AWS services, your applications, and SaaS partners to targets based on rules that match event content.
- Producers publish to a bus, rules match on the event's JSON body, matched events fan out to targets — no polling, no consumers to run
- Three bus types: default (AWS service events, free to ingest), custom (your apps), partner (SaaS); rules filter on payload content, not just metadata
- At-least-once delivery, no ordering guarantee — failed deliveries retry ~24 hours / 185 attempts, then drop unless a standard SQS DLQ is attached
- Limits: 1 MB max PutEvents request, 5 targets per rule (hard, not adjustable), 300 rules per bus, 100 buses per Region
Exam triggers
Phrases and scenarios that point here.
- "React to a change in state", "event-driven", "loosely coupled", "serverless integration between AWS services"
- An AWS service action must trigger something — S3 upload, EC2 state change, CloudTrail API call, Config finding → EventBridge, not SNS or SQS
- "Schedule", "cron", "nightly job", "run every N minutes" without a server → EventBridge Scheduler or a scheduled rule
- Ingesting events from a third-party SaaS (Datadog, Zendesk, Auth0, Shopify) → partner event bus; no other AWS service does this
Not this service
- High-throughput fan-out to many subscribers, or push to SMS/email/mobile → SNS (EventBridge caps at 5 targets per rule)
- Multi-step workflow with state, branching, and per-step retries → Step Functions; EventBridge routes single events, it doesn't orchestrate
Use cases
- Reacting to control-plane changes without polling — a security group opening port 22 to the world fires a rule within seconds of the API call and invokes a remediation Lambda, instead of waiting for a scheduled compliance scan
- Retiring cron boxes with EventBridge Scheduler — stopping non-production RDS instances and EC2 fleets at 7pm and restarting at 8am in the team's local timezone, with no server to patch and no drift when DST shifts
- Adding a consumer to an existing domain event without touching the producer — an OrderPlaced event already on the bus picks up a new fraud-scoring target by adding one rule, and the ordering service ships nothing
- Centralizing security signals across accounts — spoke accounts forward GuardDuty findings and Config non-compliance events to a single bus in the security account, so routing and alerting live in one place
- Pushing internal events straight to SaaS tools via API destinations — a deployment-failed event calls the PagerDuty or Slack HTTP endpoint directly, with auth and rate limiting handled by the connection instead of a glue Lambda
Commonly confused with
Verified against AWS documentation · 2026-08-24
Amazon SNS
Fully managed pub/sub messaging for pushing one message to many subscribers at once.
- Push, not poll — publisher sends once, SNS delivers to every subscription; publisher never learns who is listening
- Standard: near-unlimited throughput, at-least-once, best-effort ordering
- FIFO: strict ordering and deduplication by message group; SQS queues only as subscribers
- Subscriber protocols: SQS, Lambda, HTTP/S, email, SMS, mobile push, Kinesis Data Firehose
- Subscription filter policies match on message attributes or body — filtering happens in SNS, before delivery
- No retention or replay on Standard topics: a failed delivery retries, then hits the subscription DLQ or is gone
- Limits: 256 KB max message size, 12.5M subscriptions per topic, 100K topics per account (default)
Exam triggers
Phrases and scenarios that point here.
- "Fan out", "notify multiple systems", "one event, several consumers"
- "Push notification", "immediately notify", "without polling" → SNS, not SQS
- Multiple teams need the same event but must process independently → SNS + one SQS queue each
- Alert an operator by email or SMS when a CloudWatch alarm fires → SNS topic
- Subscribers need different subsets of the same stream → one topic + filter policies, not many topics
- Ordering required across a fanout → FIFO topic into FIFO queues
Not this service
- One message consumed by exactly one worker, with retry until processed → SQS
- Rule-based routing from AWS service events, SaaS partners, or a schema registry → EventBridge
- Marketing or transactional email with templates, bounce handling, and deliverability reporting → SES
- Consumers that need to replay history or read at their own pace → Kinesis Data Streams
Use cases
- Classic fanout: one `order-placed` topic feeding separate SQS queues for billing, inventory, and analytics — new consumers subscribe without the publisher shipping a single line of code
- Operational alerting spine: CloudWatch alarms, Auto Scaling lifecycle events, and Budgets all publish into one topic that fans out to on-call SMS, a team inbox, and an HTTPS webhook into Slack or PagerDuty
- Priority routing with filter policies: a single events topic where the paging subscription filters `severity = critical` and the logging subscription takes everything — one publisher, two very different downstream costs
- Cross-account event hub: a topic in a shared-services account with a resource policy allowing publishes from workload accounts, so audit and security tooling subscribes once instead of per account
- Mobile push at the application layer: publish to a platform endpoint and let SNS handle APNs and FCM delivery rather than maintaining two push integrations
- Fanning a strictly ordered stream: FIFO topic into FIFO queues when several consumers each need the same events in the same sequence — inventory adjustments, ledger entries, state machine transitions
Commonly confused with
Verified against AWS documentation · 2026-08-24
Amazon SQS
Fully managed message queuing service for decoupling distributed components.
- Producers write, consumers poll and delete — neither side needs the other online
- Standard: near-unlimited throughput, at-least-once, best-effort ordering
- FIFO: strict ordering, exactly-once processing, lower throughput
- Limits: 256 KB max message size, 14-day max retention, 20s long polling
Exam triggers
Phrases and scenarios that point here.
- "Decouple", "buffer", "smooth out traffic spikes", "process asynchronously"
- Work must not be lost when a component fails → SQS + DLQ
- Order matters / no duplicates → FIFO, not Standard
- Consumers overwhelmed by bursty producers → SQS between them
Not this service
- One message to many subscribers → SNS
- Replay or multiple independent readers → Kinesis Data Streams
Use cases
- Decoupling microservices so a slow or failed downstream component doesn't take the upstream one down with it
- Buffering work for background/batch jobs — image processing, report generation, order fulfillment — picked up by workers or Lambda
- Fan-out work queues, where a pool of worker instances pulls from one queue to parallelize processing
- Smoothing bursty producers (flash-sale order spikes, IoT telemetry) so downstream capacity is never overwhelmed
- FIFO for workflows where order and no-duplicate-processing are correctness requirements, not nice-to-haves
Commonly confused with
Verified against AWS documentation · 2026-08-24
AWS Step Functions
Serverless orchestration that runs multi-step workflows as visual state machines with built-in retries and error handling.
- Workflows are JSON state machines (Amazon States Language): Task, Choice, Parallel, Map, Wait, Pass, Succeed, Fail
- Standard: up to 1 year, exactly-once, billed per state transition, full visual execution history
- Express: up to 5 minutes, at-least-once, billed per request + duration, no .sync or callback patterns
- Retry, Catch, and Timeout are declarative — orchestration logic leaves your Lambda code
- Limits: 256 KB payload between states, 25,000 history events per Standard execution
Exam triggers
Phrases and scenarios that point here.
- "Orchestrate", "coordinate", "multi-step process", "visual workflow", "state machine"
- Lambda chained to Lambda with hand-rolled retry and error logic → replace with Step Functions
- Process must run longer than Lambda's 15-minute ceiling → Standard workflow holds the state
- A human approval or manual review sits in the middle of the flow → Standard + task token callback
- High-volume, short-lived event processing where audit trail doesn't matter → Express, not Standard
Not this service
- Producer and consumer just need decoupling, no steps to sequence → SQS
- Rule-based event routing to targets with no workflow state to track → EventBridge
- Existing Apache Airflow DAGs you don't want to rewrite → MWAA
Use cases
- Order sagas with compensating actions — charge card, reserve stock, book courier; if the courier call fails, Catch routes to a refund branch instead of leaving the customer charged with nothing shipped
- Refunds above a threshold pause on a task token until a manager clicks an approve link; the execution sits idle for days and costs nothing while waiting
- Wrapping jobs that outlive Lambda — .sync starts a Glue, Batch, or EMR job and the workflow blocks until it finishes, with no polling loop to build or maintain
- Distributed Map over an S3 inventory to re-tag or re-encrypt millions of objects, each batch running as its own child execution with its own 25,000-event budget
- Security response driven by EventBridge — a GuardDuty finding triggers isolate-instance, snapshot-volume, page-on-call as separately auditable steps rather than one opaque Lambda
Commonly confused with
Verified against AWS documentation · 2026-08-24