EC2 实例启动失败这件事，几乎每个用 AWS 的人都会遇到。有时候是权限问题，有时候是容量不够，有时候是配置出了错。大多数情况都不需要慌张，按步骤排查就行。
这篇把常见的启动失败场景和对应的处理方法梳理一下，方便你对号入座。
先确认一下：实例卡在哪个状态？
启动失败之前，实例通常会先进入 pending 状态，然后要么变成 running，要么直接跳到 terminated。如果直接从 pending 变成 terminated，说明启动过程中遇到了无法自动恢复的问题。
在 EC2 控制台的实例列表里，选中实例后可以在详情页的「状态转换原因」里看到具体信息。也可以用 AWS CLI 查：
bash
aws ec2 describe-instances --instance-id i-xxxxxxxxxxxxxxxxx返回的 JSON 里找 StateReason 字段，里面有 Code 和 Message，这两个能告诉你大概是什么原因。
场景一：实例容量不足
错误表现
启动时收到 InsufficientInstanceCapacity 错误，或者实例状态显示 Server.InsufficientInstanceCapacity。
为什么会这样？
AWS 当前在指定的可用区没有足够的按需容量来满足你的启动请求。这不是你账号的问题，是 AWS 那边的资源暂时不够了。
怎么处理？
等几分钟再试一次，容量可能会释放出来
如果是一次请求多个实例，可以拆成几个小批量的请求分别提交
提交新请求时不指定具体的可用区，让 AWS 自动分配
换成其他实例类型（后期可以再调整大小）
场景二：实例被立即终止
错误表现
实例从 pending 直接变成 terminated，没有任何中间状态。常见的终止原因码包括：
Client.VolumeLimitExceeded：EBS 卷数量超限Client.InternalError：启动过程中的客户端错误Client.InvalidSnapshot.NotFound：指定的快照不存在
为什么会这样？
最常见的原因包括：
你超过了当前区域允许的 EBS 卷数量限制，可以删除未使用的卷或者申请提高限制
根 EBS 卷加密了，但你无权访问用于解密的 KMS 密钥，需要确保自己有对应 KMS 密钥的权限
块储存设备映射中指定的快照已加密，同样需要 KMS 权限
对于由实例存储支持的 AMI，可能缺少必要的镜像部分文件
怎么处理？
根据找到的终止原因码来对应对策。如果是卷限制问题，删掉不用的卷；如果是权限问题，检查 IAM 和 KMS 权限配置。
场景三：权限不足
错误表现
启动失败，报错信息类似 You are not authorized to perform this operation.
为什么会这样？
IAM 用户或角色缺少启动实例必需的权限。最常缺的是这两个：
ec2:RunInstancesiam:PassRole
怎么处理？
如果是以 IAM 用户身份操作，检查是否有
ec2:RunInstances对通配符资源"*"的权限如果需要传递角色给实例，检查是否有
iam:PassRole对应角色 ARN 的权限如果权限没问题但仍然报错，可以解码授权失败消息来定位具体缺少哪个权限
场景四：AMI 相关问题
错误表现
启动失败，报错信息包含 AMI 相关的提示。
常见原因及处理
AMI ID 不存在：你用的 AMI 可能已经被删除了，需要换一个有效的 AMI。
AMI 还在等待处理：如果你是刚创建的 AMI，它可能还没完全准备好，需要等一会儿再用。
架构不匹配：这是容易被忽略的问题。如果选的实例类型是 ARM 架构（比如 Graviton），但 AMI 是 x86_64 的，就会启动失败。检查 AMI 的架构和你选的实例类型是否一致。
设备名称无效：给 EBS 卷指定的设备名可能被 AMI 占用了，或者是无效的格式。用下面的命令查 AMI 用了哪些设备名：
bash
aws ec2 describe-images --image-id ami-xxxxxxxxxxxxxxxxx --query 'Images[*].BlockDeviceMappings[].DeviceName'AMI 已禁用：你尝试从一个被禁用的 AMI 启动实例，需要换一个。
场景五：状态检查失败
实例启动后状态显示为 running，但状态检查（Status Checks）显示失败，也属于启动不成功的一种。
状态检查分两类：
系统状态检查失败：问题出在底层物理主机上（网络断连、硬件故障等）。解决方法是停止并重新启动实例，让实例迁移到新的硬件上。
实例状态检查失败：问题出在操作系统层面，比如网络配置错误、内存耗尽、文件系统损坏、内核不兼容等。处理方式包括：
先试着重启实例，很多临时问题重启就能解决
如果重启没用，从「操作」菜单里选择「获取系统日志」，查看启动过程中的错误信息
有些网络配置问题可以通过附加辅助弹性网卡来修复，连上之后在系统内调整网络设置
场景六：Auto Scaling 组里的实例启动失败
如果实例是在 Auto Scaling 组里启动失败的，除了上面提到的原因，还有几种额外的可能：
安全组被删了：启动配置里指定的安全组不存在了，需要重新指定一个有效的
密钥对被删了：启动时用的密钥对不在了，需要换一个
可用区不支持所选实例类型：可以在控制台或通过
describe-instance-type-offerings命令查一下哪些可用区支持你的实例类型
排查步骤总结
不管遇到什么情况，按这个顺序来比较有效率：
看状态转换原因：在控制台查
StateReason，这是第一手线索查系统日志：如果实例还活着，从「获取系统日志」里看启动过程
检查权限配置：确认 IAM 用户/角色有必要的权限
检查 AMI 和实例类型是否匹配：架构、支持情况都要看
确认资源限制：EBS 卷数、实例数是不是超了
等一会儿再试：容量不足这种临时问题，等几分钟可能就解决了
EC2 启动失败的原因虽然五花八门，但绝大多数都能通过状态码和日志定位出来。排查的关键是找对方向——先看报错码，再决定是查权限还是换 AMI。