当 Spring Boot 应用通过 AWS SDK 在 ECS 任务中调用 Lambda 时，若函数执行时间接近或超过 350 秒，invoke() 方法可能无限挂起——这并非权限或代码逻辑问题，而是 VPC 内 TCP 连接空闲超时机制导致的网络层行为。
当 spring boot 应用通过 aws sdk 在 ecs 任务中调用 lambda 时，若函数执行时间接近或超过 350 秒，`invoke()` 方法可能无限挂起——这并非权限或代码逻辑问题，而是 vpc 内 tcp 连接空闲超时机制导致的网络层行为。
在 Amazon VPC 环境中（ECS 任务默认运行于 VPC 内），底层网络基础设施会对空闲 TCP 连接施加 350 秒（约 5 分 50 秒）的强制中断策略。一旦连接在此时间内无有效数据交换，NAT 设备、安全组或中间网络节点会静默丢弃后续数据包，但操作系统和应用层仍认为连接“存活”，从而导致 AWSLambda.invoke() 阻塞等待永远无法到达的响应——这就是您观察到的“无限挂起”现象。
相比之下，本地开发环境通常直连公网（绕过 VPC 网络路径），不受此限制，因此总能在 Lambda 超时后（如 15 分钟）收到明确的 TimeoutException 或 ExecutionTimeoutException，行为符合预期。
✅ 正确解法：启用并调优 TCP Keep-Alive 机制
Keep-Alive 并非应用层重试，而是由内核周期性发送探测包，主动维持连接活跃状态，从而规避 350 秒空闲超时。需从容器系统参数与HTTP 客户端配置两层协同生效：
-
在 ECS 任务定义中设置内核级 Keep-Alive 参数
在 containerDefinitions 的 linuxParameters.systemControls 中添加（单位：秒）："systemControls": [ { "namespace": "net.ipv4.tcp_keepalive_time", "value": "300" }, { "namespace": "net.ipv4.tcp_keepalive_intvl", "value": "60" }, { "namespace": "net.ipv4.tcp_keepalive_probes", "value": "3" } ]✅ tcp_keepalive_time=300 确保首次探测在 5 分钟内触发（
-
确保 AWS SDK 使用支持 Keep-Alive 的 HTTP 客户端
默认 ApacheHttpClient 已启用 Keep-Alive，但需显式配置连接池与超时（推荐使用 SdkHttpClient 构建器）：ApacheHttpClient.Builder httpClientBuilder = ApacheHttpClient.builder() .connectionTimeout(Duration.ofSeconds(30)) .maxConnections(50) .connectionTimeToLive(Duration.ofMinutes(5)); AWSLambda awsLambda = AWSLambdaClientBuilder.standard() .withHttpClient(httpClientBuilder.build()) .build();⚠️ 注意：仅设置 ClientConfiguration.setRequestTimeout()（如 16 分钟）无法解决根本问题——该超时作用于请求发起阶段，而挂起发生在连接已建立但被中间设备静默失效后的读阻塞阶段。
? 其他关键注意事项：
- 避免依赖 Lambda 同步调用处理长任务：15 分钟是 Lambda 同步调用硬上限，且受 VPC 网络限制。对耗时操作，应改用异步模式（InvocationType = Event）+ Step Functions 或 SQS 回调，解耦执行与响应。
- 验证网络路径：确认 ECS 任务运行在公有子网（含 NAT Gateway）或私有子网（配 NAT），否则 Lambda API 调用本身将失败，而非挂起。
- 监控与告警：通过 CloudWatch 监控 Lambda:Invoke 的 Throttles、Errors 及 Duration 指标，并对 ClientConnectionTimeout 类错误（如 SocketTimeoutException）设置告警。
综上，该问题本质是云网络基础设施的确定性行为，而非缺陷。通过精准配置 TCP Keep-Alive（300 秒触发）并配合健壮的客户端设置，可彻底消除 ECS 环境下 Lambda 同步调用的无限挂起风险，保障服务稳定性与可观测性。
