05.7 · AWS Lambda 连接数耗尽：CloudHSM 与数据库连接上限、RDS Proxy 及解法

English version GitHub: https://github.com/geekchow/aws-lambda-guide背景本文选自开源学习指南《AWS Lambda 心智模型》中英双语。全书用一个贯穿示例串联网店 ShopFast 的checkout函数周四通过prod别名把 v7 金丝雀发布到 v8周五黑五开售前把预置并发PCProvisioned Concurrency提到 400文中的第 N 步即指该示例中的步骤完整场景见 04 贯穿示例。你在这里第 5 阶段深入 7 / 7。这是示例的一个假设扩展checkout在 CloudHSM 上签名支付令牌并把订单写入 Aurora。涉及第5步v8 提升到 100%、第6步PC 扩到 400、第9步800 个环境的峰值。读完本文你将知道为什么 Lambda 远在用满后端处理能力之前就耗尽了它的连接数上限CloudHSM 与数据库的硬性数字以及两条出路——让每条连接承载更多工作或者干脆不需要持久连接。缩写对照表缩写英文全称中文HSMHardware Security Module硬件安全模块KMSKey Management Service密钥管理服务RDSRelational Database Service关系型数据库服务SDKSoftware Development Kit软件开发工具包PKCS#11Public-Key Cryptography Standards #11公钥密码标准第 11 号HSM 客户端接口ESMEvent Source Mapping事件源映射SQSSimple Queue Service简单队列服务ECS / EC2Elastic Container Service / Elastic Compute Cloud弹性容器服务 / 弹性计算云PCProvisioned Concurrency预置并发RPSRequests Per Second每秒请求数1. 角色回顾它不是 Lambda 的组件——这里是两个组件执行环境05.6与并发05.4撞上一个按连接数配给资源的后端。这样的后端很多关系型数据库max_connections、CloudHSM每集群 900 个客户端连接、Redis、传统消息中间件。出现在第 5、6、9 步的假设版本中。2. 内部设计——为什么连接数先耗尽2.1 规则每个环境一条连接而不是每次调用一条如果客户端在 Init 阶段handler 之外创建并复用——正如 05.6 所建议——Lambda不会每次调用都新建连接而是每个执行环境一条。但标准模式下一个环境一次只服务一个请求因此打开的连接数 ≈ 执行环境数 ≈ 峰值并发再加上闲置环境和泄漏的连接。由此得出三个后果连接数跟随并发而不是跟随工作量。并发 RPS × 时长05.4。一个 150 毫秒的请求只花 5 毫秒访问 HSM却在整整 150 毫秒内占着连接——而且在请求之间环境被冻结的几分钟里也一直占着。每条连接同一时刻只承载一个操作。CloudHSM 和数据库要靠少量连接上的大量并发操作多线程、多会话、流水线才能跑满吞吐。单并发的环境永远不会在自己的连接上放超过一个请求。连接比环境活得更久。Lambda 回收环境时进程没有可靠的机会关闭 socket只有外部扩展能收到SHUTDOWN事件。后端会一直保留这个会话直到自己的空闲超时成为幽灵连接。池化层每连接多个操作标准 Lambda 模式环境 11 条连接, 1 个操作连接上限每集群 900 /max_connections环境 21 条连接, 1 个操作环境 ...各占 1 条连接冻结与幽灵环境仍占着连接HSM / 数据库大部分时间空闲Lambda 环境群代理 / 服务少量连接,大量会话HSM / 数据库接近满吞吐图注连接上限先被触达而后端大部分时间空闲池化层改变了操作数 / 连接数的比例。2.2 硬性数字后端限制CloudHSM 集群每集群最多 900 个并发客户端连接不可调整。使用 Client SDK 5 时一个应用进程 一条连接所以每个 Lambda 环境算一条。每个应用最多 1,024 个 PKCS#11 会话。CloudHSM 吞吐参考6 台hsm2m.medium≈ 每秒 7,000 次 EC P256 签名或 ≈ 5,000 次 RSA-2048 签名——测试方式是一台 EC2 实例上的一个多线程 Java 客户端。RDS / Auroramax_connections未显式设置时按实例内存推算每条连接即使空闲也占用数据库内存。KMS CloudHSM 密钥存储每个密钥存储每秒 1,800 次请求不可调整仅支持对称密钥。AWS 自己的基准测试最能说明这种错配集群用一条连接就能跑满而 Lambda 环境群可以把 900 条连接全部占满HSM 却大部分时间空闲。3. 交互——出路修复手段分两类让每条连接承载更多操作或者不再需要持久连接。3.1 基本功必要但不充分在 Init 中连接一次并复用连接池大小设为 1。在标准 Lambda 中更大的连接池只会让连接数成倍增加。预留并发 连接预算05.4后端上限 − 其他客户端 − 部署重叠的余量。SQS 触发的函数要设置 ESM 的最大并发。缩短后端空闲超时wait_timeout、idle_session_timeout让幽灵连接尽快被回收。PC 会提前打开连接每个预置环境都会提前运行 Init05.3。3.2 数据库方案作用注意事项RDS Proxy首选Lambda 连接代理代理把大量客户端连接复用到一个受MaxConnectionsPercent限制的后端连接池上还能吸收连接风暴和故障切换。固定pinning会话状态如SET、临时表会把客户端绑定到一条后端连接复用失效——关注DatabaseConnectionsCurrentlySessionPinned。连接池满时请求最多等待ConnectionBorrowTimeout。Aurora Data API走 HTTPS 调用没有持久连接。仅限 Aurora每次调用有额外开销结果集大小有限制。SQS 缓冲写操作先入队由低并发的消费者批量写入连接数不再随前端流量增长。只适用于可异步的工作。DynamoDBHTTPS API没有连接数限制。需要改数据模型。Lambda Managed Instances2025 年推出一个环境并发处理多个请求一个线程安全的连接池由多个在途请求共享。handler 和客户端必须线程安全计费与容量模型不同。3.3 CloudHSMCloudHSM没有类似 RDS Proxy 的托管代理900 条连接的上限又是固定的——因此架构选择更关键。方案作用注意事项KMS CloudHSM 密钥存储密钥仍在你的集群里Lambda 通过 HTTPS 调用 KMS由 KMS 持有 HSM 连接。仅支持对称密钥每个密钥存储每秒 1,800 次请求同时计入账号的 KMS 配额。不能做 RSA/EC 签名。加密服务层ECS/EC2少量长期运行的进程每个一条连接、多个会话和线程与 AWS 基准测试的方式相同。Lambda 通过 HTTPS/gRPC 调用它。能用上集群的全部吞吐。你需要运维一个服务扩缩、mTLS、可用性。高频非对称签名的正解。信封加密 数据密钥缓存HSM 只负责包装/解包数据密钥大量加解密在进程内用缓存的密钥完成HSM 调用量下降几个数量级。只适用于加密不适用于签名明文数据密钥会在缓存期内留在内存中。SQS 批处理一次调用在同一条连接上签名 N 条数据。只适用于可异步的工作。Lambda Managed Instances一条连接同时服务多个并发请求真正用上客户端的多会话设计。需确认 SDK 绑定支持在单进程内并发使用。用令牌密钥而不是会话密钥令牌密钥在各 HSM 间负载均衡会话密钥会把吞吐钉死在一台 HSM 上。能分摊操作但不减少连接数。RDS / Aurora能不能是CloudHSM是否: 签名或高频可以不可以Lambda 访问受连接数约束的后端哪种后端?工作能否异步处理?SQS 缓冲 低并发消费者RDS Proxy 预留并发上限仍有固定或代理瓶颈?Data API、DynamoDB或 Managed Instances对称加密且低于 1,800 次/秒?KMS CloudHSM密钥存储 信封加密可以异步?SQS 批处理,限制消费者并发ECS/EC2 加密服务层,或 Managed Instances图注按后端类型以及工作能否等待来选择修复方案。4. ⚓ 回到示例——如果checkout用了 CloudHSM 和 Aurora假设 v8 在每次结账时多做两件事在 CloudHSM 上签名支付令牌约 5 毫秒以及把订单插入 Aurora。两个客户端都按 05.6 的建议在 Init 中创建。时刻环境数HSM 连接上限 900出了什么问题周四第 5 步——v8 提升到 100%v7 环境转为空闲但不会立即回收v7 和 v8 的环境在一段时间内同时占着连接部署重叠连接数短暂超过稳态。周五 08:30第 6 步——PC 扩到 400提前运行 400 次 Init第一位顾客到来之前就打开了 400 条连接并持有一整天只要做过预算就没问题。周五 09:06第 9 步——峰值800预留并发900 中占了 800一个批量换密钥任务加上已回收环境留下的幽灵连接占满剩下的 100 条 → 新环境在 Init 中连接失败。峰值时checkout的处理量 ≈ 800 / 0.15 秒 ≈每秒 5,300 个请求也就是每秒约 5,300 次签名——而每条连接每 150 毫秒只忙 5 毫秒约 3%。增加 HSM 只是提高了一个够不着的容量真正限制吞吐的是连接上限。ShopFast 的修复支付签名是非对称、同步的操作于是迁到一个小型ECS 加密服务4 个任务、4 条连接、每条多个会话订单写入改走RDS Proxy预留并发保持 800因为现在设定上限的是数据库的连接预算而不是 HSM。5. 失败行为失败症状应对CloudHSM 连接达到上限新环境在 Init 中连接失败 → 调用报错不是限流做连接预算用 KMS 或服务层挡在集群前面。数据库max_connections达到上限too many connections/remaining connection slots are reserved报错RDS Proxy限制预留并发缩短空闲超时。RDS Proxy 连接池耗尽请求排队等待超过ConnectionBorrowTimeout后失败减少固定提高MaxConnectionsPercent限制并发。缩容或部署后出现幽灵连接流量很低时连接数依然居高不下缩短后端空闲超时可选用扩展在SHUTDOWN时关闭连接。KMS CloudHSM 密钥存储被限流ThrottlingExceptionCloudHSMKeyStoreThrottle指标上升数据密钥缓存保持在每秒 1,800 次以下使用专用集群。结论在标准 Lambda 中连接数随并发增长而不是随工作量增长且每条连接同一时刻只承载一个操作——所以按连接数配给资源的后端会在处理能力远未用满时就撞上连接上限。换更大的 HSM 或数据库没用有效的是让每条连接承载更多操作RDS Proxy、加密服务层、Managed Instances、批处理或者不再需要持久连接Data API、KMS 密钥存储、DynamoDB。配额数值已于 2026-10-15 对照 AWS 文档核实CloudHSM 配额与性能、KMS 请求配额、RDS Proxy 连接设置。下一篇 →06 完整走查 ·返回03 概念地图 返回专栏目录