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

eserved concurrency — It guarantees the maximum number of concurrent instances for the function which can be invoked. When a function has being with a reserved concurrency configuration then no other lambda function within the same AWS account and region can use that concurrency. There is no charge for configuring reserved concurrency for a function. Provisioned concurrency — This concurrency initializes a requested number of execution environments so that they are prepared to respond immediately to your function’s invocations. Note that configuring provisioned concurrency incurs charges to your AWS account.

Provisioned concurrency addresses latency concerns and compute optimizer addresses cost. D is best answer here.

Not a very well written question, but I will go with answer B with this as the deciding factor - The company wants to reduce the compute costs

• Reserved concurrency – This represents the maximum number of concurrent instances allocated to your function. When a function has reserved concurrency, no other function can use that concurrency. Reserved concurrency is useful for ensuring that your most critical functions always have enough concurrency to handle incoming requests. Configuring reserved concurrency for a function incurs no additional charges.

for reserved we don't know the incoming traffic as traffic is increasing so we choose provisioned and as it realted to cpu so compute optimizer.

I vote D instead of B because of constantly increasing number of messages and to maintain service latency for its customer although provisioned concurrency incurs the charges to your AWS account. If the reduce of comput costs is more important than service latency , B is correct.

IMO answer is D. The number of messages in message queue is constantly increasing: then, to maintain service latency you need to configure provisioned concurrency. For cpu-intensive job you can optimize the duration increasing memory

Let's think - Should we increase or decrease memory? Know that CPU resources scale proportionally with memory allocation in AWS Lambda, so increasing memory will help reduce the execution time for CPU-intensive tasks. Shorter execution times lower the overall compute cost. Then, A & C are out. About option D, it ensures performance and prevents cold starts, yes, but it also incurs additional costs to keep Lambda execution environments pre-warmed, even when not in use. Reserved concurrency is more cost-effective for sustained workloads.

Reserved concurrency – This represents the maximum number of concurrent instances allocated to your function. When a function has reserved concurrency, no other function can use that concurrency. Reserved concurrency is useful for ensuring that your most critical functions always have enough concurrency to handle incoming requests. Configuring reserved concurrency for a function incurs no additional charges. Provisioned concurrency – This is the number of pre-initialized execution environments allocated to your function. These execution environments are ready to respond immediately to incoming function requests. Provisioned concurrency is useful for reducing cold start latencies for functions. Configuring provisioned concurrency incurs additional charges to your AWS account.

Provisioned concurrency: For scenarios with predictable high traffic like marketing events, using provisioned concurrency ensures Lambda functions are always ready to process requests, maintaining low latency. Increase memory based on Compute Optimizer recommendations: Since the Lambda functions are CPU intensive, increasing allocated memory based on AWS Compute Optimizer suggestions can often improve performance and reduce costs by allowing the functions to process more data without hitting CPU throttling.

Provioned concurrency will increase cost and we need to maintain latency not to decrease latency. Also, provisioned concurrency cost is very related to memory, so if you use provisioned and increase memory this will affect the cost dramatically.

Also Lambda provisioned concurrency incure additionnal Account charges (https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html), it's the best option because it is stated: - The company wants to reduce the compute costs and to maintain service latency for its customers. So maintaining service latency while reducing compute cost is requested. That being said, Lambda optimization is not a trivial task, that's why one should rely on AWS Compute Optimizer recommendations to analyze usage and find the best fit. Please read following for more insights: https://aws.amazon.com/blogs/compute/optimizing-aws-lambda-cost-and-performance-using-aws-compute-optimizer/

Increase the memory according to AWS Compute Optimizer recommendations --> so we can lower the duration of lambda function to reduce the cost. The ans must be between B & D

Provisioned Concurrency keeps the Lambda functions initialized and ready to process incoming events, reducing the cold start latency associated with spinning up new execution environments.

D is correct

When a large number of messages are in the SQS queue, Lambda scales out, adding additional functions to process the messages. The scale out can consume the concurrency quota in the account. To prevent this from happening, you can set reserved concurrency for individual Lambda functions. This ensures that the specified Lambda function can always scale to that much concurrency, but it also cannot exceed this number. https://docs.aws.amazon.com/lambda/latest/operatorguide/computing-power.html

When a large number of messages are in the SQS queue, Lambda scales out, adding additional functions to process the messages. The scale out can consume the concurrency quota in the account. To prevent this from happening, you can set reserved concurrency for individual Lambda functions. This ensures that the specified Lambda function can always scale to that much concurrency, but it also cannot exceed this number. https://docs.aws.amazon.com/lambda/latest/operatorguide/computing-power.html