Which solution will prepare for the load increase MOST cost-effectively?

Explanations:

Moving the code to read the SSM parameter value outside the Lambda function handler and storing it in a global variable does not account for the potential load increase. In a Lambda execution environment, global variables are shared among invocations, but this can lead to stale or outdated values if the underlying parameter changes. Furthermore, if the Lambda function’s concurrency doubles, it could lead to an overload on the Parameter Store’s GetParameter request limit, causing errors.

Similar to option A, moving the code to read the SSM parameter value outside the Lambda function handler and storing it in an environment variable does not effectively manage the load increase. Environment variables are static and won’t be updated if the underlying parameter changes. Additionally, this approach does not scale with increased concurrency, and it could still exceed the Parameter Store’s GetParameter rate limits.

Requesting a service quota increase for the Systems Manager GetParameter rate quota may allow for more frequent reads but does not prepare for a load increase effectively or cost-efficiently. This option increases costs without ensuring that the Lambda function can handle double the throughput. It’s a reactive rather than proactive measure.

Adding an SSM parameter that resolves the RDS DB cluster endpoint at deployment time using an SSM dynamic reference allows the Lambda function to access the value without incurring additional GetParameter requests during runtime. This method also supports a higher invocation rate as the Lambda function can be invoked concurrently without hitting the Parameter Store’s read limits, effectively preparing for the expected load increase in a cost-efficient manner.