AWS Lambda function 间接性超时

你看一下 log ，看看是不是冷启动了。Log 里面会有 Init Duration 。
不过就算你不停的 ping ，也不能保证它不会冷启动。如果那个可用区负载过高，你的 lambda 也可能被负载均衡搞出去，一样会冷启动。

如果你对这冷启动的时间很敏感，可以试试 Provisioned Concurrency 。或者干脆就用 EKS ，不要用 Lambda 。

就算你每秒都有请求，lambda 觉得自己需要扩容，或者超过最大持续时长了，都会开新的 lambda(需要冷起)
无论如何 15 分钟都会有一次冷启的

lambda 相当于执行你的代码之后，保留运行环境，并输出一个 handler(用于被调用)，这个启动这个环境叫“冷启”。
当 lambda 被调起时，会分配一个 handler （没有可用的会新起一个）执行并返回结果。
它根据自己的设定(不同语言不同逻辑)来判断目前环境是否活跃，不活跃则释放。
lambda 保留的运行环境有最大时间限制(即使活跃也会被销毁)，一般是 15 分钟。
我用的 node 至于 Python 的运行环境应该是同理。

#1 @Mithril 非常感谢回复，看来我对 lambda 的冷启动理解有问题，查了下日志确实是大量 Init Duration

对冷启动时间倒是不是很敏感，敏感的是因为超时带来的请求错误。通过日志冷启动时间不超过 1s ，业务处理逻辑应该在 200 ms 以内，因此设置了 5s 的超时时间应该是足够的。但是错误率确实和超时时间有关，我再定位一下吧，总之十分感谢提供的信息

日志查询 Init Duration：


错误率确实和允许时常有关 ：

#2 #3 @Aygnh136

明白了，我对 lambda 的理解确实有问题，我再去了解一下，十分感谢回复

lz 你的 Lambda 的负载难道只有 1rps ？ 如果大于 1rps 你这做法当然会出现冷启动的问题

但再冷启动，11s 也太长了，Lambda 的冷启动时间撑死也就 2s~3s ，而 11s 的处理时间明显是程序内部哪里的问题，建议打 log 或者启用 xray 看看内部发生了什么

#6 @BeautifulSoap 十分感谢回复，经过排查确实是我的程序内部逻辑问题：在 lambda 内部使用 sdk 调用 secretsmanager client 的 get_secret_value 时候默认未设置超时时间，导致有一定概率会卡住：

```python
session = boto3.session.Session()
client = session.client(
service_name="secretsmanager",
region_name=REGION_NAME,
cOnfig=aws_client_config,
)
respOnse= client.get_secret_value(SecretId=db_secret_id)
```

虽然还不清楚在 lambda 内部使用 sdk 调用 secretsmanager client 会啥可能卡住，目前换了其他的方式来避免调用 secretsmanager client 之后，原来的问题解决了。

@lvhuiyang 原来如此。其实不光是 ssm ，aws 的其他服务比如 dynamodb 之类通过 https 提供服务的都会出现可能性的超时。之前生产环境每几小时报错，查到后来发现是和 dynamodb 的通信超时了。