AWS Lambda内存查找及ElastiCache Redis访问低延迟方案咨询

问题1：Lambda访问VPC内的ElastiCache Redis是否必须挂载到同一VPC？ #

是的。默认部署的ElastiCache集群没有公网访问端点，仅允许同一VPC内的资源发起访问，因此Lambda必须挂载到与ElastiCache集群相同的VPC下运行。同时需要满足两个前置配置：

• Lambda执行角色需附加AWSLambdaVPCAccessExecutionRole相关权限，允许创建、挂载弹性网络接口（ENI）
• VPC安全组规则需放行Lambda安全组到ElastiCache实例Redis端口（默认6379）的入站流量

问题2：Lambda挂载VPC的ENI创建耗时是否会影响实时响应需求？ #

不会。ENI创建耗时仅出现在Lambda冷启动场景，也就是首次触发函数、或者并发量上涨需要扩容新的执行环境的时候才会发生，温启动的请求会复用已经创建好ENI的执行环境，不会产生额外耗时。
针对你每分钟3000次请求（平均50QPS）的并发规模，只要配置对应量级的预置并发（Provisioned Concurrency） 预留固定数量的预热执行环境，就能完全规避冷启动的ENI创建开销。正常同VPC内访问Redis的延迟仅为1~2ms，完全不会挤占300ms的延迟预算。

问题3：有没有更优的Lambda侧低延迟查找方案？ #

以下方案都能满足你的延迟和并发要求，可根据数据规模灵活选择：

• DynamoDB方案：直接把哈希邮箱到内部ID的映射存在DynamoDB中，按需模式下单键点查延迟稳定在10ms以内，无需将Lambda挂载到VPC，天然支持高并发，3000次/分钟的请求量远低于DynamoDB默认配额，运维成本极低。如果需要更低延迟还可以搭配DynamoDB DAX做缓存层。
• 内存预加载方案：如果映射数据总规模小于100MB，可以在Lambda执行环境的初始化阶段（也就是函数代码外的全局部分）把全量映射数据一次性加载到内存中，后续请求直接走内存哈希表查找，延迟低于1ms。映射数据更新时可以通过更新函数版本、发布新层等方式触发执行环境刷新即可，成本是所有方案中最低的。
• 托管Redis免VPC方案：如果一定要用Redis作为存储，可以开启ElastiCache的公网访问功能（需配置身份鉴权保障安全），或者选用支持公网访问的MemoryDB for Redis，也可以避免Lambda挂载VPC的额外配置开销。

内容的提问来源于stack exchange，提问作者Mithun Manohar