在AWS Lambda中部署AWS ElastiCache遇连接超时及DNS解析失败问题求助

核心问题分析 #

错误日志中的getaddrinfo ENOTFOUND表明Lambda无法解析ElastiCache的域名，结合30秒超时错误，本质是网络连通性配置问题——Lambda与ElastiCache未处于可互相访问的网络环境，或相关权限/路由配置有误。

分步排查与修复方案 #

1. 确认Lambda与ElastiCache在同一VPC内 #

• ElastiCache Redis默认仅在VPC内部可访问，必须将Lambda函数部署到与ElastiCache完全相同的VPC中。
• 检查Lambda配置：进入Lambda控制台 → 函数配置 → VPC，确认已选择ElastiCache所在VPC，且至少勾选两个该VPC下的子网（建议直接选择ElastiCache使用的子网）。

2. 验证安全组规则 #

• ElastiCache安全组：需允许来自Lambda安全组的6379端口（Redis默认端口）入站流量。
  操作路径：ElastiCache控制台 → 目标集群 → 详情 → 安全组 → 编辑入站规则，添加自定义TCP规则，端口填6379，源选择Lambda函数的安全组ID。
• Lambda安全组：需允许出站流量到ElastiCache的6379端口。
  若使用自定义出站规则，确保包含TCP 6379指向ElastiCache安全组或VPC的CIDR范围；默认出站规则为允许所有流量，此情况下无需额外配置。

3. 检查子网路由表 #

• Lambda所在子网的路由表需保留VPC本地路由（如10.0.0.0/16这类默认路由），确保VPC内部资源互通。无需配置公网网关（除非Lambda需访问公网，但ElastiCache访问不需要）。
• 确认ElastiCache所在子网的路由表同样具备VPC内部连通的路由规则。

4. 代码与DNS配置检查 #

• 确认ElastiCache端点域名完全正确：从ElastiCache控制台复制主节点的完整端点（不要包含端口，代码中已指定6379）。
• 若需排查DNS解析问题，可在代码中临时添加测试逻辑：

  const dns = require('dns').promises;
  
  // 在client.connect()之前插入以下代码
  try {
    const ipRecords = await dns.resolve4(url);
    console.log('ElastiCache DNS解析结果:', ipRecords);
  } catch (dnsError) {
    console.error('DNS解析失败:', dnsError);
  }
  

• 确保VPC的DNS选项设置为AmazonProvidedDNS（默认配置），保证VPC内部域名解析正常。

5. 连通性测试（辅助排查） #

在ElastiCache所在VPC内启动一台EC2实例，安装Redis客户端后执行以下命令测试连接：

redis-cli -h xxxxxxxxxxx.use2.cache.amazonaws.com -p 6379 ping

• 若EC2能正常连接（返回PONG），说明ElastiCache本身配置无问题，问题集中在Lambda的VPC/安全组配置。
• 若EC2也无法连接，优先排查ElastiCache的安全组、子网及路由表配置。

总结 #

绝大多数此类问题源于Lambda未加入ElastiCache所在VPC，或安全组未开放6379端口的互通权限。按上述步骤逐一验证，优先确认VPC归属和安全组规则的正确性。

内容的提问来源于stack exchange，提问作者حمزہ لیاقت