切换至t4g.medium实例后AWS ECS任务卡在Provisioning状态求助

1. AMI架构兼容性问题 #

t2.medium是x86_64架构，t4g.medium是ARM64（Graviton2）架构，这是最常见的适配坑：

• 先查AMI架构：在EC2控制台的AMI详情页看「架构」字段，确认是否为arm64（对应t4g），如果你的自定义AMI是基于x86_64构建的，直接跑在ARM实例上会直接失败。
• 哪怕是Docker容器，若镜像只构建了x86_64版本，在ARM实例上默认无法运行——除非提前安装QEMU模拟，但ECS代理默认不会自动配置这个。如果没做多架构镜像适配（同时支持x86_64和arm64），容器根本启动不了。

2. ECS代理配置缺失 #

t4g实例的AMI必须正确配置ECS代理才能和集群通信：

• 连进t4g实例，执行systemctl status ecs（Amazon Linux 2环境），看代理是否正常运行，有没有启动失败的日志。
• 检查启动模板的UserData：必须包含ECS_CLUSTER=<你的集群名称>，否则代理不知道要注册到哪个集群。示例配置：

  #!/bin/bash
  echo "ECS_CLUSTER=my-ecs-cluster" >> /etc/ecs/ecs.config
  

3. 实例IAM角色权限不足 #

ECS实例得有足够权限拉取ECR镜像、上报任务状态：

• 确认实例绑定的IAM角色是否包含AmazonEC2ContainerServiceforEC2Role托管权限，或者自定义权限覆盖以下关键操作：
  • ecr:GetDownloadUrlForLayer、ecr:BatchGetImage（拉取镜像用）
  • ecs:RegisterContainerInstance、ecs:SubmitTaskStateChange（和ECS集群通信用）
• 检查角色的信任策略，确保允许EC2服务扮演该角色。

4. 资源与网络配置问题 #

• 核对任务定义的资源请求：t4g.medium是2vCPU/4GB内存，若任务请求的CPU/内存总和超过实例剩余可用资源，会导致调度失败。
• 检查实例安全组：必须允许出站访问443端口（ECS、ECR服务都走HTTPS），以及容器所需的业务端口。

5. 自定义AMI的环境缺失 #

你自己构建的AMI可能漏掉了ECS运行必需的组件：

• 对比AWS官方ECS优化AMI（分x86_64和arm64版本），检查你的AMI是否安装了ecs-init、Docker服务，且配置正确。
• 手动验证：在t4g实例上直接拉取ECR镜像运行，看是否能启动：

  docker pull <你的ECR镜像地址>
  docker run <镜像标签>
  

  若失败，看Docker日志就能定位是依赖缺失还是架构不兼容。

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