Decoupling Lambda Ingestion and Aurora Writes with SQS
Design scalable and loosely coupled architectures.
Design high-performing and elastic compute solutions.
Design secure workloads and applications.
Answer
Correct answer: D — Decouple the receiving Lambda from the database-loading Lambda with an Amazon SQS queue so incoming data buffers and scales without raising Lambda quotas.
A company is designing an application. The application uses an AWS Lambda function to receive information through Amazon API Gateway and to store the information in an Amazon Aurora PostgreSQL database. During the proof-of-concept stage, the company has to increase the Lambda quotas significantly to handle the high volumes of data that the company needs to load into the database. A solutions architect must recommend a new design to improve scalability and minimize the configuration effort. Which solution will meet these requirements?
Community Insight
The question tests loosely coupled, bufferable serverless design; the trap is picking SNS or a full platform rewrite when only SQS provides pull-based queuing that decouples ingest rate from Lambda concurrency.
The scenario asks how to absorb high-volume data ingestion into Aurora PostgreSQL without inflating AWS Lambda concurrency quotas, while keeping configuration effort low. Splitting ingestion and database loading into two Lambda functions joined by an Amazon SQS queue is the design that meets both scalability and minimal-effort requirements.
Option C is the most common wrong pick because two Lambda functions wired with SNS looks nearly identical to the correct architecture, but SNS pushes messages immediately to the second function and reproduces the same concurrency bottleneck under load.
Community Discussion (44 comments)
samxtruong
👍 1
Selected: D
Without specify the load latency, D is the answer.
nesyto
👍 1
Selected: D
correct answer is D
tgrgopi
👍 2
Selected: D
Using an SQS queue to decouple the API-ingest Lambda from the DB-writer Lambda gives you automatic buffering, smoothing of traffic spikes, and built-in retry/backoff semantics with minimal configuration. It keeps a serverless architecture (no EC2), requires little operational work, and avoids changing the database.
Clouddon
👍 1
Selected: D
Use SQS as a buffer between two Lambda functions to build a scalable, decoupled, and resilient pipeline for ingesting and storing data into Aurora PostgreSQL with minimal configuration effort.
PaulGa
👍 2
Selected: D
It could be C or D, but Ans D wins because –SNS is Push Mechanism - ‘Other Lambda’ function is forced to take message when it might not be ready (or refuse it) –SQS is Pull Mechanism – ‘Other Lambda’ function can take next message when its ready to do so SQS is simple and allows better de-coupling.
rodrigoleoncio
👍 1
Selected: D
uses SQS
JohnZh
👍 3
If the throughput is so high that lambda concurrency needs to go beyond 1000, we need to set up a queue to throttle the request.
TheFivePips
👍 2
Selected: D
D. Set up two Lambda functions, one for receiving information and another for loading data into the database. Integrate them using an Amazon SQS queue. This approach allows for better scalability, maintains the serverless paradigm, and minimizes manual configuration effort. It leverages Amazon SQS as a reliable message queue between Lambda functions. Options A and B introduce complexities and changes in architecture, while Option C introduces an additional service that may not be as suitable for decoupling processes in this scenario.
awsgeek75
👍 5
Selected: D
SQS will help Lambda scale even more. A EC2 + Tomcat will be slower than Lambda for this usecase B is wrong because the problem is with Lambda scaling not the DB C SNS is not the best option for this usecase when SQS is an option
A_jaa
👍 1
Selected: D
Answer-D
ddement0r
👍 1
Selected: D
D : other ones just don’t make sense
pedestrianlove
👍 2
Sorry, but the question does not make sense by itself. What are you asking for more scalability from an already scalable Lambda function? If you're concerned about the concurrency limits of Lambda function, decoupling just doesn't make sense, since it'll keep even more lambda instances running in a given time period(including 2 phases of execution for each request, let alone the cold start issues). If you're concerned about bottleneck database induced, that'll even be more ridiculous since you're supposed to resolve the scalability issue of the database(e.g. Aurora) instead of decoupling the Lambda function to improve the throughput of this entire data flow.
mohamedsambo
👍 3
i think it is clear that he want to enhance the lambda even more than "The default concurrency limit across all functions per region in a given account is 1,000" cause sqs can scale and store the data till new available revoked lambda consume it
Ruffyit
👍 2
Lambda and SQS are serverless. No involvement will be required in execution.
xdkonorek2
👍 2
Selected: B
I think B would be better solution. How splitting one function into 2 increase scalability when company already increased service quota? Effectively they will have same compute time. Changing Aurora to DAX will shorten the time for data loads by ~100x requiring way less time for data loading, and it's most time consuming thing this lambda does. DAX has better scaling than aurora and is better fit with lambda
MakaylaLearns
👍 1
Lambda Functions: A review Run your code in response to events You can build chatbots using Lambda functions to process user input, execute business logic, and generate responses. Scales automatically They can be triggered in response to API events Lambda functions can process files as they are uploaded to S3 buckets. This is often used for tasks like image resizing, data extraction, or file validation.
doujones
👍 2
Do you all have to take the whole practice exam on here, in order to pass AWS SAA C03
TariqKipkemei
👍 1
Increase Lambda quotas = Set up two Lambda functions. Improve scalability = Amazon Simple Queue Service.
TariqKipkemei
👍 1
Selected answer D
miki111
👍 1
Option D is the right answer for this.
Kaab_B
👍 3
Selected: D
Lambda and SQS are serverless. No involvement will be required in execution.
Thornessen
👍 2
This threw me off - because ideally, I see no need for two lambdas. It can be done with one: APIGW -> SQS -> Lambda.
ichwilldoit
👍 2
By, @cookieMr [https://www.examtopics.com/user/cookieMr/] "By dividing the functionality into two Lambda functions, one for receiving the information and the other for loading it into the database, you can independently scale and optimize each function based on their specific requirements. This approach allows for more efficient resource allocation and reduces the potential impact of high volumes of data on the overall system."
cookieMr
👍 5
Selected: D
Option D, setting up two Lambda functions and integrating them using an SQS, would be the most suitable solution to improve scalability and minimize configuration effort in this scenario. By dividing the functionality into two Lambda functions, one for receiving the information and the other for loading it into the database, you can independently scale and optimize each function based on their specific requirements. This approach allows for more efficient resource allocation and reduces the potential impact of high volumes of data on the overall system. Integrating the Lambda functions using an SQS adds another layer of scalability and reliability. The receiving function can push the information to the SQS, and the loading function can retrieve messages from the queue and process them independently. This asynchronous decoupling ensures that the receiving function can handle high volumes of incoming requests without overwhelming the loading function. Additionally, SQS provides built-in retries and guarantees message durability, ensuring that no data is lost during processing.
TienHuynh
👍 1
Selected: D
D is correct, SQS can queue data
Bmarodi
👍 1
Selected: D
To improve scalability and minimize the configuration effort. Solutions architect can choose option D.
Abrar2022
👍 1
To improve scalability and minimize configuration efforts you can set up 2 lambda functions, one to receive the other to load. Then integrate the lambda functions using SQS.
kakka22
👍 1
Is the question wrong? Amazon Aurora use it's own DB not PostgreSQL, you need to provision an rds instance for that..
Freddie26
👍 1
The question ask you to improve scalability and minimize the configuration effort. While SNS is a fair answer, SQS is better. "SQS scales elastically, and there is no limit to the number of messages per queue." See https://aws.amazon.com/blogs/compute/choosing-between-messaging-services-for-serverless-applications/.
PhucVuu
👍 21
Selected: D
Keywords: - Company has to increase the Lambda quotas significantly to handle the high volumes of data that the company needs to load into the database. - Improve scalability and minimize the configuration effort. A: Incorrect - Lambda is Serverless and automatically scale - EC2 instance we have to create load balancer, auto scaling group,.. a lot of things. using native Java Database Connectivity (JDBC) drivers don't improve the performance. B: Incorrect - a lot of things to changes and DynamoDB Accelerator use for cache(read) not for write. C: Incorrect - SNS is use for send notification (e-mail, SMS). D: Correct - with SQS we can scale application well by queuing the data.
linux_admin
👍 3
Selected: D
o improve scalability and minimize configuration effort, the recommended solution is to use an event-driven architecture with AWS Lambda functions. This will allow the company to handle high volumes of data without worrying about scaling the infrastructure. Option C and D both propose an event-driven architecture using Lambda functions, but option D is better suited for this use case because it uses an Amazon SQS queue to decouple the receiving and loading of information into the database. This will provide better fault tolerance and scalability, as messages can be stored in the queue until they are processed by the second Lambda function. In contrast, using SNS for this use case might cause some events to be missed, as it only guarantees the delivery of messages to subscribers, not to the Lambda function.
SilentMilli
👍 1
Selected: D
By using two Lambda functions, you can separate the tasks of receiving the information and loading the information into the database. This will allow you to scale each function independently, improving scalability.
Buruguduystunstugudunstuy
👍 2
Selected: D
The solution that will meet these requirements is D: Set up two Lambda functions. Configure one function to receive the information. Configure the other function to load the information into the database. Integrate the Lambda functions by using an Amazon Simple Queue Service (Amazon SQS) queue. Using separate Lambda functions for receiving and loading the information can help improve scalability and minimize the configuration effort. By using an Amazon SQS queue to integrate the Lambda functions, you can decouple the functions and allow them to scale independently. This can help reduce the burden on the receiving function, improving its performance and scalability.
Buruguduystunstugudunstuy
👍 2
Option A, refactoring the Lambda function code to Apache Tomcat code that runs on Amazon EC2 instances and connecting the database using native JDBC drivers, is not a good choice because it would require significant effort to redesign and refactor the code and would not improve scalability. Option B, changing the platform from Aurora to Amazon DynamoDB and provisioning a DynamoDB Accelerator (DAX) cluster, is not a good choice because it would require significant effort to redesign and refactor the code and would not improve scalability. Option C, integrating the Lambda functions using Amazon SNS, is not a good choice because it does not provide the decoupling and scaling benefits of using an Amazon SQS queue.
Zerotn3
👍 1
It's D (100%)
pazabal
👍 1
Selected: D
improve scalability = SQS
Wpcorgan
👍 1
D is correct
ABCMail
👍 2
Selected: D
Two single responsibility functions offer a better solution.
akosigengen
👍 2
D. Keyword is to handle load which will be taking care of by SQS.
123jhl0
👍 108
Selected: D
A - refactoring can be a solution, BUT requires a LOT of effort - not the answer B - DynamoDB is NoSQL and Aurora is SQL, so it requires a DB migration... again a LOT of effort, so no the answer C and D are similar in structure, but... C uses SNS, which would notify the 2nd Lambda function... provoking the same bottleneck... not the solution D uses SQS, so the 2nd lambda function can go to the queue when responsive to keep with the DB load process. Usually the app decoupling helps with the performance improvement by distributing load. In this case, the bottleneck is solved by uses queues... so D is the answer.
Ajai23
👍 2
Selected: D
Process of elimination, D
BoboChow
👍 1
Selected: D
Atually I'm really confused by those options. A is not right obiously, but the remaining options don't make sense, either...
Vickysss
👍 1
The idea is to avoid bottleneck on processing data by splitting the processes in two stages using two different Lambda and insert an SQS as intermediary so to crate an asynchronous process
Lilibell
👍 2
the answer is D
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option D splits the workload into a receiver Lambda and a loader Lambda connected through an Amazon SQS queue, so API Gateway traffic lands in a durable buffer rather than directly against Lambda concurrency limits. Because SQS is a pull-based event source, the second function scales out according to the queue depth and drains messages at a rate Lambda can actually service, which smooths spikes instead of forcing the company to raise quotas. This preserves the serverless footprint already in place, requires only a queue and an event source mapping, and therefore minimizes configuration effort. The pattern also introduces built-in buffering, retries, and visibility-timeout handling for free, directly satisfying both the scalability and low-effort requirements. It also aligns with the well-architected guidance on loose coupling and elastically scalable compute.Why the Other Options Are Wrong
Option A abandons Lambda for Apache Tomcat on Amazon EC2 with JDBC, which demands load balancers, auto scaling groups, patching, and capacity planning — the opposite of minimizing configuration effort — and it also tends to run slower than Lambda for bursty ingestion. Option B swaps Aurora PostgreSQL for DynamoDB with a DAX cluster, a full data-model and application rewrite that does nothing to relieve the Lambda quota pressure identified as the actual problem. Option C uses the same two-function shape as the correct answer but joins them with Amazon SNS, a push mechanism that forces the second function to accept messages immediately and can still overwhelm its concurrency, reproducing the bottleneck. Only SQS decouples the producer rate from the consumer rate, so messages wait in the queue until capacity exists.Community Comment Notes
Community consensus overwhelmingly favors D, with 123jhl0 observing that "A - refactoring can be a solution, BUT requires a LOT of effort" and that SNS "would notify the 2nd Lambda function... provoking the same bottleneck." PaulGa captured the decisive distinction precisely: "SNS is Push Mechanism" while "SQS is Pull Mechanism," which lets the loader function consume the next message only when ready. tgrgopi added that the queue supplies "automatic buffering, smoothing of traffic spikes, and built-in retry/backoff semantics with minimal configuration," while PhucVuu stressed that Aurora-to-DynamoDB migration is a large-effort detour. JohnZh and mohamedsambo both pointed out the underlying mechanics — once concurrency approaches the 1,000-request regional default, a queue is what throttles and stores data for later consumption.Official Reference
Exam Strategy
On SAA-C03, treat phrases like 'minimize configuration effort' and 'improve scalability' as signals for serverless, loosely coupled patterns; when two options differ only by SNS versus SQS, choose SQS for any work that must be consumed at a controlled rate. Eliminate answers that require a database migration or an EC2 re-platform unless the question explicitly asks to leave serverless.
Frequently Asked Questions
Why is SNS wrong when both options C and D use two Lambda functions?
SNS pushes each message to the second Lambda immediately, so the loader still faces the full ingest rate and can hit concurrency limits. SQS lets the loader pull messages only when capacity is available, creating a real buffer.
Why can't we just migrate Aurora to DynamoDB with DAX to fix the Lambda quota problem?
The bottleneck is Lambda concurrency during ingestion, not database throughput. Switching to DynamoDB would force a NoSQL data-model rewrite and application changes, adding large effort without removing the quota constraint.
Related Analysis
Practice All SAA-C03 Questions
Access 120 questions with complete answers and detailed explanations.
View Full SAA-C03 Practice Test →