AWSAWS Certified Generative AI Developer - Professional2026-102.3 Design and implement enterprise integration architectures
Select transports by delivery and replay
Completed by the knowledge check
Learning objective
Select EventBridge, SNS, SQS, Kinesis, or Amazon MSK for fan-out, ordering, replay, and throughput requirements
Core idea
An event bus, notification topic, work queue, and retained stream solve different integration problems. Start with the unit of work and the consumer contract. Does every consumer need its own copy? Do workers compete for one task? Must an entity’s events remain ordered? Can a consumer recover by replaying history rather than asking the source to regenerate it?
Specify the scope of each requirement. Ordering by customer differs from one global order; replaying a retained stream differs from retrying a failed delivery. Throughput includes bytes, event count, partition distribution, and consumer speed. A service that handles total volume can still fail your design when one customer concentrates work in one ordered group or partition.
Delivery and processing are separate. Deduplicating publication does not make a consumer’s external writes transactional. Keep the completion and failure contract from 2.3.3 even when the chosen transport advertises stronger ingestion semantics.
How it works
Use EventBridge for event routing
The AWS documentation distinguishes the EventBridge Custom Event Bus from Custom Event Bus - Classic. Classic buses use rules and targets. Custom Event Bus uses subscribers that filter and optionally transform events for a target, and retains events so subscribers can start in the past or pause and resume. Do not treat the Classic rule model as the only EventBridge model.
For Custom Event Bus, subscriber Type is UNORDERED or FIFO. Unordered subscribers deliver in parallel for throughput. FIFO subscribers deliver in publication order within an event group, set through SystemMetadata.EventGroupId. The group is also scoped to the publishing account: identical group identifiers from two accounts do not form a shared ordered sequence.
An undeliverable event blocks later events in its own FIFO group while other groups continue. For a Lambda target, InvocationType: EVENT preserves order only to the hand-off into Lambda’s asynchronous queue. Use REQUEST_RESPONSE when the subscriber must wait for ordered processing. This is a concrete case where selecting FIFO without examining the next boundary is insufficient.
Classic buses archive events with indefinite retention by default or a configured number of days. Replay sends archived events again without removing them. It processes events by event time in one-minute intervals, so replay does not necessarily preserve archive order; do not apply FIFO subscriber guarantees to Classic replay.
Use SNS for topic fan-out and SQS for work
Amazon Simple Notification Service (Amazon SNS) fans out messages to subscribed endpoints. Use an SNS FIFO topic with SQS FIFO queues when independent consumers need ordered delivery. Give each consumer its own queue; workers sharing one queue compete for work.
Amazon Simple Queue Service (Amazon SQS) standard queues provide at-least-once delivery and best-effort ordering. Use them when parallel work and tolerance of duplicates or reordering fit the contract. SQS FIFO queues order messages within each message group. MessageDeduplicationId or content-based deduplication prevents duplicate sends within the service’s deduplication rules; it does not atomically commit a database write performed by a worker.
SQS standard queues support nearly unlimited throughput. For FIFO queues without batching, the documented baseline is 300 API calls per second per API method; batching up to ten messages gives up to 3,000 messages per second per method. High throughput mode raises capacity further. Message-group distribution still bounds concurrency; adding workers cannot parallelize one ordered group.
SNS standard-topic fan-out does not provide a retained stream history. SNS message archiving and replay is available only for application-to-application FIFO topics. Set the topic ArchivePolicy attribute through CreateTopic or SetTopicAttributes, with MessageRetentionPeriod from 1 to 365 days. Consumers can replay archived messages; configure retention for the recovery requirement rather than assuming fan-out alone retains history.
Use Kinesis for a retained AWS stream
Amazon Kinesis Data Streams stores records in shards. Each record has a partition key, sequence number, and data blob. The partition key determines the shard, so key distribution affects both throughput and the processing boundary. Sequence numbers belong to their partition-key and shard context; do not treat them as a global event index.
For provisioned capacity, each shard supports writes up to 1,000 records per second and 1 MB per second, and reads up to 2 MB per second with up to five read transactions per second. Shared-throughput consumers share the shard’s 2 MB/s read budget. Enhanced fan-out instead gives each registered consumer up to 2 MB/s per shard, pushed over HTTP/2 through SubscribeToShard. Use it when independent readers would contend for shared reads. Both record and byte rates matter; extra shards do not by themselves fix hot keys.
Streams retain records for 24 hours by default. IncreaseStreamRetentionPeriod can extend retention up to 8,760 hours, or 365 days; retention beyond 24 hours has additional charges. Match that window to the longest consumer outage and reprocessing need. On-demand capacity manages shards automatically, while provisioned capacity makes shard count an explicit sizing responsibility.
Use MSK for the Kafka integration contract
Amazon Managed Streaming for Apache Kafka (Amazon MSK) fits when the enterprise integration uses Kafka producers, consumers, and topics. Keep Kafka offsets and retained topic replay explicit rather than translating them into queue deletion semantics.
MSK configuration exposes retention settings such as log.retention.ms, log.retention.hours, and log.retention.bytes, plus num.partitions. Size partitioning, retention, and consumer progress together. Byte retention can remove data before a time-based recovery window expires. Throughput depends on cluster capacity and partition design.
Key distinctions and trade-offs
Use the following comparison as a starting point:
| Service | Primary fit | Requirement to make explicit |
|---|---|---|
| EventBridge | Filtered routing across producers and consumers | Custom subscriber versus Classic rule model |
| SNS | Topic fan-out to independent endpoints | Each consumer’s delivery and backlog ownership |
| SQS | Work distribution to consumers | Standard versus FIFO and message-group scope |
| Kinesis Data Streams | Retained stream with partitioned records | Shard/key distribution and retention window |
| Amazon MSK | Kafka-native enterprise streaming | Topic partitions, offsets, retention, and cluster capacity |
No row removes the need for authorization, schema evolution, or processing idempotency. The strongest transport guarantee still ends at a particular hand-off.
Architecture / decision scenario
A manufacturing assistant receives equipment telemetry, maintenance events, and repair commands. High-rate telemetry uses Kinesis with device partition keys, outage-covering retention, and enhanced fan-out for independent readers. An existing Kafka analytics platform uses MSK, keeping its Kafka topic and offset contract rather than rewriting all consumers.
Business maintenance events use EventBridge filtered routing. The team selects Custom Event Bus FIFO subscribers only where per-equipment publication order matters, and uses REQUEST_RESPONSE for a Lambda target that must process in that order. Ordered alert and audit consumers receive SNS FIFO fan-out through separate SQS FIFO queues, with topic archiving enabled for replay. Repair workers consume an SQS FIFO queue grouped by equipment identifier so unrelated repairs can progress independently.
The team load-tests hot devices and slow consumers, not only aggregate event volume. It checks whether replay must reconstruct telemetry history, redeliver business events, or retry uncompleted commands. Each path has a different recovery owner, so one transport does not become the default for all five requirements.
Common exam traps
- Assuming every EventBridge bus has identical ordering and replay behavior.
- Equating fan-out with several workers consuming one SQS queue.
- Treating FIFO as a global ordering guarantee.
- Equating publication deduplication with exactly-once business effects.
- Sizing Kinesis only by bytes or only by record count.
- Choosing MSK without a Kafka contract or retained-stream requirement.
What to remember
Choose routing, fan-out, work distribution, or retained streaming from the consumer’s contract. State the ordering scope and replay window. Verify throughput at the shard, group, partition, and consumer boundaries that can become bottlenecks. Treat EventBridge Custom Event Bus and Classic buses as distinct configuration models.
Knowledge check
Alert and audit services each need every maintenance message, in order per equipment item, and each must keep its own backlog when it falls behind. Which arrangement fits?
A Custom Event Bus FIFO subscriber delivers maintenance events, grouped by equipment, to a Lambda target with InvocationType: EVENT. The function sometimes processes a later event for one machine before an earlier one finishes. What fixes this?
EventGroupId for every event on the busREQUEST_RESPONSEType from FIFO to UNORDEREDEVENT , FIFO order holds only up to the hand-off into Lambda’s asynchronous queue, after which processing can overlap. REQUEST_RESPONSE makes the subscriber wait for each event’s processing. One group for everything only serialises unrelated machines, and the order was already correct at publication.Three independent applications read the same Kinesis data stream. Writes are within shard limits, but every reader falls behind, and together they exceed each shard’s 2 MB per second read rate. Without resharding, which change gives each reader the throughput it needs?
GetRecords more oftenSubscribeToShard . Polling more often hits the same budget, retention only extends the replay window, and partition keys are chosen by producers to place records on shards.Repair commands go to an SQS FIFO queue with one MessageGroupId for all equipment. Only commands for the same machine must stay in order. The backlog keeps growing, and adding workers does not help. What change raises throughput?
An Amazon MSK topic has log.retention.hours set to 168 so that a consumer can replay a week of history from its offset. After a high-volume period, a consumer returning from a two-day outage finds that the records after its offset are already gone. What explains this?
log.retention.bytes limit before 168 hours passednum.partitions was too low for the volumeReferences
- AWS, EventBridge Custom Event Bus and Ordering and deduplicating events on a Custom Event Bus
- AWS, Archiving and replaying events in Amazon EventBridge
- AWS, Message ordering and deduplication strategies using Amazon SNS FIFO topics and Amazon SNS message archiving for FIFO topic owners
- AWS, Amazon SQS queue types
- AWS, Amazon Kinesis Data Streams terminology and concepts and Develop enhanced fan-out consumers with dedicated throughput
- AWS, Amazon MSK configuration properties