ECS Service Connect跨子网调用时出现无法解析主机问题求助

1. 先核对Service Connect核心配置 #

• 检查service1的Service Connect设置：必须启用Service Connect，绑定的服务发现命名空间（比如service1.local）要正常生效，且service1的任务定义必须使用awsvpc网络模式——Service Connect仅支持该模式。
• 检查service2的Service Connect设置：需加入同一个命名空间，且已完成对service1端点的访问授权配置，别漏了授权步骤。

2. 确认Service Connect代理在service2中正常运行 #

Service Connect依赖sidecar代理自动更新/etc/hosts，先验证代理状态：

• 进入service2的容器，执行ps aux查看是否存在aws-appmesh-envoy或service-connect-proxy进程（不同ECS版本进程名可能有差异）。
• 如果代理未启动，检查任务定义中是否正确添加了Service Connect的sidecar配置，同时确认容器的CPU/内存配额足够启动代理——资源不足会导致代理无法正常初始化。

3. 检查VPC和子网的DNS配置 #

• 登录VPC控制台，确认DNS resolution和DNS hostnames均设置为Yes，任意一项关闭都会影响Service Connect的DNS解析。
• 查看公有子网的路由表，需指向VPC默认DNS服务器（通常为VPC网段+2，比如10.0.0.2），若使用第三方DNS服务，Service Connect的本地DNS解析会直接失效。

4. 验证端点状态与IAM权限 #

• 进入ECS控制台查看service1的Service Connect端点状态，必须为ACTIVE，状态异常需优先排查端点配置问题。
• 检查ECS任务执行角色的权限：需包含ecs-service-connect:*和servicediscovery:*相关权限，权限缺失会导致代理无法拉取DNS记录。

5. 核对任务网络配置 #

• 确认service2的任务运行在启用Service Connect的目标VPC内，且任务安全组允许与service1的安全组通信，包括Service Connect代理默认使用的15000-15001端口。
• 在service2容器内执行cat /etc/resolv.conf，确认nameserver指向VPC默认DNS，若指向外部DNS服务，本地解析必然失败。

临时解决办法 #

若以上排查均无问题但/etc/hosts仍未自动更新，直接重启service2的任务——重启后代理会重新拉取Service Connect的DNS记录并自动更新/etc/hosts，比手动修改更可靠。

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