AWS Lambda调用SQSClient批量发送消息至DLQ超时问题排查

结合你的代码、配置和日志，以下是核心排查方向和解决方案：

1. VPC网络连通性问题（最可能的根因） #

你的Lambda部署在VPC子网内，默认无法直接访问公网（包括SQS的公网端点）。如果没有配置正确的网络出口，请求会被阻断，最终导致超时。

• 解决方法：
  • 配置NAT网关：确保Lambda所在子网为私有子网，关联的路由表添加指向NAT网关的0.0.0.0/0路由，让Lambda通过NAT网关访问公网SQS端点。
  • 配置SQS VPC端点：在VPC中创建SQS的接口端点，确保Lambda所在安全组允许访问该端点的443端口，同时路由表添加指向该端点的路由（无需公网访问）。

2. 批量消息ID重复（潜在问题） #

代码中所有批量消息的Id都设置为dlqName，违反了SQS SendMessageBatch的要求：同一请求内的每个Entry必须拥有唯一Id。虽然这不是本次超时的直接原因，但会导致请求失败，需修正：

const entries: SendMessageBatchRequestEntry[] = messages.map((message, index) => {
  // 生成唯一ID，结合索引与UUID保证唯一性
  return { Id: `${dlqName}-${index}-${crypto.randomUUID()}`, MessageBody: formatSQSMessage<T>(message) };
});

3. Lambda超时时间过短 #

当前Lambda超时设置为10秒，与日志中超时时间完全吻合。如果网络存在延迟，可能导致请求未完成就被终止。可以临时将超时时间调大到30秒，验证是否能成功发送，以此确认是否是网络连通性导致的请求缓慢。

4. 队列URL验证 #

确认代码生成的QueueURL对应的DLQ确实存在，名称拼写（包括大小写）与AWS控制台中的队列完全一致。虽然日志中的URL格式正确，但仍需验证实际队列是否存在且可访问。

额外优化：错误捕获逻辑 #

你的错误捕获逻辑存在缺陷：await sqs.send(params).catch(...)中，如果请求一直处于pending状态（比如网络阻断），catch不会触发，直到Lambda超时。建议修改为主动抛出错误，便于监控排查：

try {
  const response = await sqs.send(params);
  logger.info({ response }, 'Messages has been sent to dlq !');
} catch (error) {
  logger.error(error, 'Failed to send messages to dlq');
  throw error; // 抛出错误，让Lambda标记为失败，便于监控告警
}

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