Following the best practice Take advantage of execution environment reuse to improve the performance of your function, I am investigating if caching the boto3 client has any negative effect while using Lambda Provisioned Concurrency. The boto3 client is cached through @lru_cache decorator and it is lazy-initialized. Now, the concern is that the underlying credentials of boto3 client are not refreshed because Provisioned Concurrency will keep the execution environment alive for an unknown amount of time. This lifetime might be longer than the duration of the temporary credentials that Lambda environment injected.
I couldn’t find any doc explaining how this case is handled. Does anyone know how Lambda environment handles the refreshing of credentials in the above case?
If you're using hardcoded credentials:
You have a bigger security issue than "re-used" credentials and should remove them immediately.
From documentation:
Do NOT put literal access keys in your application files. If you do, you create a risk of accidentally exposing your credentials if, for example, you upload the project to a public repository.
Do NOT include files that contain credentials in your project area.
Replace them with an execution role.
If you're using an execution role:
You're not providing any credentials manually for any AWS SDK calls. The credentials for the SDK are coming automatically from the execution role of the Lambda function.
Even if Boto3 role credentials are shared across invocations under the hood for provisioned concurrency (nobody is sure), what would be the issue?
Let Amazon deal with role credentials - it's not your responsibility to manage that at all.
I would worry more about the application code having security flaws as opposed to Amazon's automatically authenticating SDK requests with execution role credentials.