如何使用缓存的boto3客户端和Lambda提供的并发刷新凭据？
遵循最佳实践利用执行环境重用来提高功能的性能。，我正在研究在使用Lambda提供的并发时缓存boto3客户端是否有任何负面影响。boto3客户端通过@lru_cache装饰器进行缓存，并且是延迟初始化的。现在，需要关注的是，boto3客户端的底层凭据不会被刷新，因为提供的并发性将使执行环境存活一段未知的时间。此生存期可能比Lambda环境注入的临时凭据的持续时间长。
我找不到医生解释这个案子是怎么处理的。在上述情况下，有人知道Lambda环境是如何处理凭证刷新的吗？
回答 2
Stack Overflow用户
发布于 2021-10-15 12:43:40
Stack Overflow用户
发布于 2021-10-15 17:48:31
他们不是。
Boto3文档在描述凭据链方面做得不太好，但是CLI文档显示了各种凭证来源(而且因为CLI是用Python编写的，所以它提供了权威的文档)。
与从实例元数据中检索基于角色的凭据的EC2和ECS不同，Lambda在环境变量中提供凭据。Lambda运行时在启动时设置这些环境变量，而对Lambda运行时的每次调用都使用相同的值。
并发Lambdas接收单独的凭证集，就像对STS AssumeRole进行并发显式调用一样。
提供的并发机制有点棘手。您可能认为相同的Lambda运行时“永远”存在，但实际上并非如此:如果您重复使用提供的并发调用Lambda，您将看到它在某一时刻创建了一个新的CloudWatch日志流。这表明Lambda已经启动了一个新的运行时。Lambda将在新运行时停止向旧运行时发送请求之前完成对新运行时的初始化，因此不会出现冷启动延迟。
更新：
这里有一个Python，它演示了我前面所说的内容。作为初始化代码(在处理程序之外)的一部分，它记录第一次初始化时的时间，然后每当调用时间戳时报告时间戳。它还记录"AWS“环境变量的当前内容，以便查看其中是否有任何变化。
import json
import os
from datetime import datetime
print("initializing environment")
init_timestamp = datetime.utcnow()
def lambda_handler(event, context):
print(f"environment was initialized at {init_timestamp.isoformat()}")
print("")
print("**** env ****")
keys = list(os.environ.keys())
keys.sort()
for k in keys:
if k.startswith("AWS_"):
print(f"{k}: {os.environ[k]}")将其配置为提供的并发性，然后使用此shell命令每45秒调用一次：
while true ; do date ; aws lambda invoke --function-name InvocationExplorer:2 --invocation-type Event --payload '{"foo": "irrelevant"}' /tmp/$$ ; sleep 45 ; done让它运行一个小时或更长时间，您将得到两个日志流。第一个流如下所示(显示开始和结束，省略数百条消息)：
2021-10-19T16:19:32.699-04:00 initializing environment
2021-10-19T16:30:57.240-04:00 START RequestId: a27f6802-c7e6-4f70-b890-2e0172d46780 Version: 2
2021-10-19T16:30:57.243-04:00 environment was initialized at 2021-10-19T16:19:32.699455
...
2021-10-19T17:07:24.853-04:00 END RequestId: dd9a356f-7928-4bf9-be56-86f4c5e1bb64
2021-10-19T17:07:24.853-04:00 REPORT RequestId: dd9a356f-7928-4bf9-be56-86f4c5e1bb64 Duration: 1.00 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 39 MB 如您所见，Lambda是在16:19:32初始化的，当时我启用了提供的并发。第一次请求是在16:30处理的。
但是我想调用的是日志流中的最后一个请求，在17:07:24，或者在Lambda初始化后大约48分钟。
第二个日志流是这样开始的：
2021-10-19T17:04:08.739-04:00 initializing environment
2021-10-19T17:08:10.276-04:00 START RequestId: 6b15ba7c-91e2-4f91-bb6c-99b9877f1ebf Version: 2
2021-10-19T17:08:10.279-04:00 environment was initialized at 2021-10-19T17:04:08.739398 因此，正如您所看到的，它是在第一个流中的最终请求之前几分钟初始化的，但是在第一个流之后开始处理调用。
当然，这是没有保证的行为。这就是Lambda今天的工作方式，将来可能会改变。但改变是不可能的:当前的植入行为符合文档，任何更改都有违反客户代码的风险。
https://stackoverflow.com/questions/69584082
复制相似问题
腾讯云开发者
