我有一个由 EBS 支持的 EC2 实例（即从 EBS 卷启动）。硬件似乎已崩溃。我无法恢复它，这令人沮丧，因为拥有由 EBS 支持的卷的全部意义在于磁盘映像应该能够抵御 CPU 崩溃。
首先，我尝试基于该机器创建一个新的 AMI，但新的 AMI 卡在了待处理状态。使用命令行工具后，我发现机器无法正常停止。所以我这样做了
ec2-stop-instances --force
进而
ec2-detach-volume --force
但后来我无法从分离的卷创建 AMI。我尝试创建一个新实例并将 EBS 卷附加到它（在分离它附带的卷之后），然后启动它，但那个实例启动失败，提示
"State Transition Reason: Server.InternalError: Internal error on launch"
我认为一定有办法让驱动器恢复运行 —— 这就是 EBS 的意义所在，对吧？但该怎么做呢？
答案1
我曾多次遇到实例崩溃的情况，最明显的一次是 AWS 出现“小” EBS 故障时。像您一样，我无法终止实例或分离卷。我最终创建了 EBS 卷的快照（是的，它允许我在不分离的情况下创建快照），从该快照创建卷并将其作为根设备附加到实例上。
请记住，虽然物理驱动器可能没有损坏，但崩溃仍然可能损坏文件系统或数据。
我还成功将该卷附加为普通的非启动卷，运行文件系统检查（例如 e2fsck）并使用 rsync，其过程类似于从 ephemeral/instance-store 迁移到 EBS 的过程：
- 将根 (/) 目录复制到 EBS 设备 (
rsync -aXHv) - （可选，也 rsync 设备（/dev），尽管我认为没有必要）
- 刷新写入并卸载
我最终“带回家”的信息是，即使 EBS 驱动器也要有当前备份 - 因此我现在在数据卷上频繁运行 ec2-consistent-snapshot，并在根卷上（不太频繁地）运行 ec2-prune-snapshots，并使用 ec2-prune-snapshots 进行轮换。
希望上述操作（快照、检查磁盘、rsync）的组合能够帮助您。
（顺便说一句，我见过这种情况的其他几次，都是我运行的某个进程消耗了所有内存 - 而我使用的特定 AMI 没有设置任何交换空间 - 控制台日志（来自 AWS 控制台）适合识别这类问题）
答案2
也许您对 EBS 驱动器本身有问题。例如，一些重要信息被删除了。
查看有关如何创建基于 EBS 的 AMI 的文章。例如这个