以下是我的工作：
我从ec2信息中心选择Launch Instance
我从AMI列表中选择Ubuntu Server 12.04.3 LTS - 64-bit
我选择t1.micro作为我的实例类型
我在第2步（配置实例详细信息）
在第4步，我将卷的大小从8增加到200
我点击Review and Launch并运行实例。
现在我不能ssh到服务器，虽然它的状态是running，状态检查是2/2 checks passed。除了增加音量大小部分之外，我在执行相同步骤时没有任何问题。知道为什么会这样吗？
答案 0 :(得分：3)
具有EBS根卷的新EC2实例从具有一些元数据的可启动硬盘驱动器快照启动，统称为Amazon Machine Image（AMI）。
这个问题促使我意识到这一点：鉴于我们开始使用现有的硬盘驱动器映像，并在其上建立了文件系统，从逻辑上讲，无论文件系统复制到多大的磁盘上都是如此在绑定到我们的新机器之前，文件系统已经被创建，并且它通常不会知道磁盘上可用的额外空间，超出其原始大小。
然而，我已经使用Ubuntu 12.04 LTS AMI为根磁盘选择了大于默认值的大小值，并且从未给出一个时刻，尽管我配置的空间量是“神奇地”可用的， ，从逻辑上讲，它不应该。启动后文件系统应该仍然是8 GB，因为它是最初大小为8 GB的文件系统的副本，并且它的所有内部结构仍然应该表明这一点。
唯一可能的结论是，我们最初启动的快照实际上必须包含自动生成其自己的文件系统的代码，以填充它醒来发现自己运行的磁盘。
这......结果证明是真的。来自Eric Hammond早期关于EC2 / EBS的文章，描述了如何获得更大的根音量：
还有一步。我们需要调整文件系统的大小，以便填满整个100 GB的EBS卷。这是ext3的神奇命令。在我的早期测试中，需要2-3分钟才能运行。 [更新：对于Ubuntu 11.04及更高版本，此步骤在AMI启动时自动执行，您无需手动运行。] [强调添加]
但是，你显然需要等待它，磁盘越大，等待时间越长。实例可达性检查sounds like a ping test。如果是这样，可以想象网络堆栈可以启动并响应，但sshd可能在调整大小操作期间可能无法接受连接，这将导致“连接被拒绝”响应 - 这是IP堆栈的主动拒绝，因为目标套接字没有监听。
实例可达性检查并不意味着实例已“准备就绪”，因为它意味着它“正在向上，向上，而不是向下运行。”