使用CloudFormation部署后端镜像到AWS Fargate时出现503服务不可用错误

我帮你梳理下Fargate部署后ALB返回503的常见排查方向——毕竟你用官方镜像能正常跑，问题大概率出在自研镜像或配套配置的细节上：

• 先查ALB目标组的健康状态
  503最常见的根源就是目标组里的Fargate任务没通过健康检查。你可以登录AWS控制台，到EC2 -> 负载均衡器 -> 对应ALB -> 目标组页面，看看任务的状态是healthy还是unhealthy。
  如果是unhealthy，先核对健康检查的配置：比如你的应用是不是监听8080端口，但健康检查配置的是80？或者健康检查路径设为/health，但你的应用根本没暴露这个健康端点？另外，Fargate任务启动需要一点时间，刚部署完别急着判断，等个3-5分钟再看状态。

• 验证自研镜像的端口与安全组配置
  对比training/webapp，检查这几个点：

  1. 你的Dockerfile里有没有用EXPOSE声明正确的应用端口？虽然EXPOSE只是声明，但Fargate任务定义里的容器端口要和这个对应上。
  2. 任务定义的容器端口和主机端口是否匹配应用实际监听的端口？比如应用监听8080，那容器端口就得设为8080，主机端口可以留空（Fargate会自动分配）。
  3. 安全组规则：Fargate任务的安全组要允许ALB所在安全组访问你的应用端口；ALB的安全组要允许外部流量（比如0.0.0.0/0）访问它的监听端口（80或443）。

• 查看Fargate任务的CloudWatch日志
  这一步绝对不能跳过！去ECS控制台 -> 集群 -> 对应集群 -> 服务 -> 任务，找到你的Fargate任务，打开CloudWatch日志。看看应用有没有正常启动：是不是依赖缺失、配置文件错误、端口被占用，或者应用启动后只监听127.0.0.1（如果是这种情况，ALB根本访问不到应用）。
  举个例子，要是你的Spring Boot应用硬设了server.address=127.0.0.1，日志里会显示启动成功，但外部完全访问不了，ALB健康检查必然失败。

• 确认VPC与子网的网络配置

  1. 你的Fargate任务是不是部署在有公网访问能力的子网？如果用私有子网，有没有配置NAT网关让任务能拉取镜像、访问外部依赖？要是任务连镜像都拉不下来，肯定启动失败，目标组就会显示unhealthy。
  2. ALB的子网和Fargate任务的子网是不是在同一个VPC？路由表有没有配置正确，确保ALB能路由到Fargate任务所在的子网。

• 本地验证自研镜像的可用性
  先在本地跑一遍你的镜像，确认应用本身没问题：

  docker run -p 8080:8080 your-image:tag
  

  然后访问localhost:8080，看看能不能正常响应。如果本地都跑不起来，那问题肯定出在镜像本身，比如启动命令错误、依赖缺失之类的。

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