Q37 — AWS SAP-C02 Ch.2

Question 37 of 75 | ← Chapter 2

Q187. A company runs a microservice as an AWS Lambda function. The microservice writes data to an on- premises SQL database that supports a limited number of concurrent connections. When the number of Lambda function invocations is too high, the database crashes and causes application downtime. The company has an AWS Direct Connect connection between the company's VPC and the on-premises data center. The company wants to protect the database from crashes.Which solution will meet these requirements?

Correct Answer: A. Write the data to an Amazon Simple Queue Service (Amazon SQS) queue. Configure the Lambda function to read from the queue and write to the existing database. Set a reserved concurrency limit on the Lambda function that is less than the number of connections that the database supports

Explanation

Apologies for the confusion in my previous response. You are correct, the solution that will meet the requirements of protecting the database from crashes in this scenario is: A. Write the data to an Amazon Simple Queue Service (Amazon SQS) queue. Configure the Lambda function to read from the queue and write to the existing database. Set a reserved concurrency limit on the Lambda function that is less than the number of connections that the database supports. Here's why this option is the most suitable: 1. Amazon SQS: By writing the data to an SQS queue, you decouple the Lambda function from the on-premises SQL database. The Lambda function can simply put the data into the queue, and the responsibility of processing the data can be offloaded to another component. 2. Lambda Function Concurrency: By setting a reserved concurrency limit on the Lambda function that is less than the number of connections the database supports, you can control the number of concurrent invocations of the Lambda function. This helps prevent overwhelming the database with too many connections and reduces the chances of crashes. 3. Scalability and Fault Tolerance: Amazon SQS is a highly scalable and fault-tolerant messaging service. It can handle a large number of messages and provides durability for the data in case of failures. This ensures that the data is reliably processed even during high traffic periods. Option B (Creating a new Amazon Aurora Serverless DB cluster and migrating data) involves migrating the data to a different database solution, which may not be necessary in this case. It introduces additional complexity and may not directly address the issue of protecting the existing on-premises database. Option C (Creating an Amazon RDS Proxy DB instance) is primarily used for managing connections to Amazon RDS databases, and may not be applicable or directly address the issue of protecting the on-premises database. Option D (Writing data to an Amazon SNS topic and invoking Lambda function to write to the database) is not the most suitable option for protecting the database from crashes caused by a high number of concurrent connections. Therefore, based on the given requirements, option A is the most appropriate choice as it offers a practical and effective solution for protecting the on-premises SQL database by using Amazon SQS to decouple the Lambda function from the database and setting a reserved concurrency limit to control the number of concurrent connections.