ECS任务随机失去RDS/Redis访问权限但仍可联网的问题排查请求

一、关于awsvpc模式的已知网络可靠性问题 #

结合你描述的症状，ECS Fargate使用awsvpc网络模式时，确实存在一些偶发的网络相关问题，可能的诱因包括：

• 内网DNS解析异常：awsvpc模式下，任务依赖VPC内置DNS解析RDS/Redis的内网端点。如果VPC DNS配置非AWS默认值（比如自定义DNS服务器），或元数据服务偶发延迟，会导致内网域名解析失败，但公网域名（如Rollbar）不受影响，这和你提到的“能上报错误但无法访问RDS/Redis”完全匹配。AWS官方文档中也提到过Fargate任务偶发的DNS解析超时问题，尤其是在生产环境VPC资源调度压力较大时。
• ENI资源分配偶发异常：Fargate任务的弹性网络接口（ENI）是动态分配的，偶尔会出现ENI初始化不彻底的情况，导致内部网络流量无法正常转发，但公网流量不受限。裸EC2容器使用主机网络模式，不存在ENI动态分配的问题，这也解释了为什么之前的部署没有故障。
• 生产环境专属配置干扰：你提到仅生产环境出现问题，大概率是生产环境有测试环境没有的网络管控配置——比如开启了VPC流量镜像、NACL规则更严格、第三方安全工具（如WAF、入侵检测）拦截了内部流量，或者RDS/Redis的安全组针对生产环境的Fargate子网有隐性限制（即使你设置了0.0.0.0/0，也可能存在VPC端点策略、子网路由表的冲突）。

需要注意的是，同镜像的Worker任务未受影响，可能是因为Worker任务的网络请求模式不同（比如连接池配置、请求频率），或者Worker使用了不同的子网/安全组配置。

二、实现健康检查失败时停止转发流量但不终止任务 #

默认情况下，ECS会在任务健康检查失败后终止任务，但可以通过以下配置调整，实现仅停止流量转发、保留故障任务用于排查：

1. 分离ECS任务健康检查与ALB目标组健康检查
   • 在ECS任务定义中移除任务级健康检查配置，完全依赖ALB目标组的健康检查。这样ALB会自动将不健康的目标从负载均衡池中移除，停止转发流量，但ECS不会主动终止任务。
   • 在ALB目标组中配置符合业务逻辑的健康检查规则（比如检查特定HTTP接口、调整超时时间和失败阈值），确保能准确识别故障节点。
2. 调整ECS服务部署策略
   • 将ECS服务的minimumHealthyPercent设置为100%，maximumPercent设置为200%。这样即使有任务标记为不健康，ECS会先启动新的替代任务，不会立即终止旧任务，避免服务容量下降。
3. 自定义故障节点隔离逻辑
   • 利用CloudWatch Events监控ECS任务的健康状态，当检测到任务不健康时，触发Lambda函数将该任务对应的目标从ALB目标组中移除，同时保留任务运行。这种方式更灵活，还可以添加告警通知，方便及时排查故障。

三、额外排查建议 #

• 开启Fargate任务的网络日志：在任务定义中添加tcpdump命令，将网络流量日志输出到CloudWatch Logs，故障发生时检查DNS解析结果、TCP连接状态，定位具体是解析失败还是连接被阻断。
• 核对生产与测试环境的VPC配置：重点检查DNS服务器设置、子网路由表、NACL规则、VPC端点策略，确认生产环境没有额外的网络限制。
• 检查RDS/Redis的访问日志：查看RDS的数据库日志和Redis的慢查询日志，确认故障发生时是否有来自Fargate任务的连接请求，判断是网络问题还是服务端拒绝连接。

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