Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 108 discussion

Interesting point that Amazon RDS event notification doesn't support any notification when data inside DB is updated. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.overview.html So subscription to RDS events doesn't give any value for Fanout = SNS => SQS B is out because FIFO is not required here. A is left as correct answer

RDS events only provide operational events such as DB instance events, DB parameter group events, DB security group events, and DB snapshot events. What we need in the scenario is to capture data-modifying events (INSERT, DELETE, UPDATE) which can be achieved thru native functions or stored procedures.

The combination of Amazon SNS and Amazon SQS together with AWS Lambda provides a robust, scalable and efficient solution for distributing RDS events to multiple target systems. This architecture ensures that data is transmitted reliably and that each target system can process the information independently, optimally meeting business requirements.

The requirement is to remove automobile listings from the website after a sale and send the data to multiple target systems in a decoupled, reliable, and scalable manner. Here’s how Option D meets the requirements: Event Notification from RDS: Amazon RDS can publish event notifications to Amazon SNS topics. When a record is updated (e.g., when a sale is recorded), this triggers an event. Fan-out to Multiple SQS Queues: The SNS topic fans out the event notification to multiple SQS queues, allowing parallel processing for different target systems. Each target system consumes messages from its respective queue, ensuring reliable and independent data delivery. AWS Lambda for Target Updates: Lambda functions subscribed to the SQS queues process the messages and perform updates in the target systems. Decoupled Design: The use of SNS for fan-out and SQS for message queuing decouples the systems. This ensures that issues with one target system do not impact the others.

key point: Even though lambda is integrated with RDS, it is not best practices for multiple consumers. SNS + SQS Fan-Out should be chosen https://aws.amazon.com/getting-started/hands-on/send-fanout-event-notifications/?nc1=h_ls

D is correct A and B: AWS Lambda cannot be triggered directly from Amazon RDS. Additionally, FIFO (in B) is not necessary unless there is a strict requirement for order.

Explanation: AWS Lambda: Lambda functions can be used to automatically trigger actions in response to updates in your database. You can create a Lambda function that listens for changes in the RDS database (e.g., when a listing is marked as sold) and sends that information to other systems. Amazon SQS: The Lambda function would send the information to an SQS queue, which allows asynchronous message processing. Multiple target systems (consumers) can then read from the SQS queue and process the data as needed. SQS ensures the delivery of messages and can handle scaling to multiple consumers.

D. Subscribe to an RDS event notification and send an Amazon Simple Notification Service (Amazon SNS) topic fanned out to multiple Amazon Simple Queue Service (Amazon SQS) queues. Use AWS Lambda functions to update the targets.

A for sure

You have to fan out first with SNS

The best design is **D. Subscribe to an RDS event notification and send an Amazon SNS topic fanned out to multiple Amazon SQS queues. Use AWS Lambda functions to update the targets**. - **SNS fan-out** enables sending data to multiple SQS queues for different target systems. - **Lambda** can process messages from each SQS queue and update the targets. ### Why not others: - **A** and **B**: No fan-out mechanism, making it harder to deliver to multiple targets. - **C**: Reverses the typical fan-out pattern (SQS to SNS) and is less efficient. Option D offers better scalability and decoupling.

A and C cannot be correct: "an (one) SQS queue for the targets (multiple) to consume". "an (one) SQS queue fanned out to multiple SNS" That would be one-to-many relationship, which is not supported by SQS. "SQS has a many-to-one relationship. You can send messages to a queue from many different producers but only one consumer can be defined." https://blog.awsfundamentals.com/aws-sns-vs-sqs-what-are-the-main-differences#heading-many-to-many-vs-many-to-one-number-of-consumers

Answer is D, this is a typical scenario for SQS fan-out. A can not send data to multiple targets

Ans C - using SQS means events are time-order preserved and then can be sent to multiple consumers using SNS

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html

RDS Event Notification: Amazon RDS supports event notifications, which can trigger actions when specific events occur, such as a record update or delete operation. In this case, an event would be triggered when a listing is removed. Amazon SNS: SNS allows the event to be published to a topic that can then be fanned out to multiple SQS queues. This is useful when you have multiple target systems that need to receive the data. SNS can push the message to all subscribed SQS queues simultaneously. Amazon SQS: SQS provides reliable message queuing. Each target system can consume messages from its respective SQS queue at its own pace, ensuring that no messages are lost. AWS Lambda: Lambda functions can be triggered by the SQS queues to process the messages and update the target systems accordingly. This approach allows for asynchronous processing and decouples the RDS update from the target system updates, improving scalability and reliability.

Fan out needs SNS