我明白这种卡在pending状态还拿不到日志的感觉真的让人头疼，尤其是刚接触OpsWorks的时候。咱们一步步来拆解这个问题：

1. 先排查网络层面的基础问题 #

• 确认实例所在子网的公网访问能力：如果你的实例没有绑定弹性IP，要检查子网是否开启了自动分配公网IP；如果是私有子网，得确保有NAT网关或者VPC端点能让实例访问AWS的服务（比如S3、OpsWorks管理节点）。OpsWorks实例启动时需要拉取Chef食谱和相关资源，没网络肯定会卡住。
• 检查安全组规则：
  • 出站规则要允许HTTPS（443）流量，这是实例和OpsWorks服务器、S3通信的关键；
  • 入站规则要对你的IP开放SSH（22）端口，确保你能正常连接实例。

2. 查看EC2系统日志（最容易被忽略的关键信息） #

即使实例处于pending状态，EC2控制台也能提供底层启动日志：

• 登录EC2控制台，找到这个实例，切换到监控标签页，点击「获取系统日志」；
• 或者用AWS CLI直接拉取：

  aws ec2 get-console-output --instance-id <你的实例ID> --output text
  

这里面会记录实例启动时的内核日志、初始化脚本输出，能帮你定位是网络初始化失败，还是无法连接到OpsWorks管理节点。

3. 验证IAM角色的权限配置 #

OpsWorks的服务角色和实例角色权限不足也会导致启动失败：

• OpsWorks服务角色：需要有管理EC2实例、弹性IP、安全组等资源的权限，确保它能完成实例的创建和配置操作；
• 实例角色：需要有访问S3（拉取食谱）、CloudWatch（上传日志）、OpsWorks API的权限。你可以在IAM控制台检查角色的权限策略，比如是否包含AmazonOpsWorksInstanceProfileManagedPolicy这个托管策略。

4. 简化栈配置，排查食谱问题 #

虽然你用的是官方PHP食谱，但也可能是配置冲突导致的：

• 先创建一个极简栈：只保留默认层，不加载任何额外食谱，启动实例看是否能正常运行。如果能启动，再逐步添加PHP食谱，排查是哪个步骤触发了失败；
• 检查PHP食谱的配置参数：比如是否指定了兼容的PHP版本，有没有依赖的系统包需要额外的软件源。

5. 确认使用的AMI兼容性 #

确保你选择的是OpsWorks官方支持的AMI，比如Amazon Linux 2或者Ubuntu的OpsWorks优化镜像。自定义AMI可能缺失Chef客户端或者其他依赖组件，导致实例初始化失败。

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