我正在使用EC2上托pipe的Web服务，并且需要根据负载情况运行不同数量的实例。 我们已经开始运行基本的服务，但是我们正在努力的一件事是configuration和启动一个Windows实例（我们正在使用一些只能在Windows上运行的第三个prty工具）所花费的时间。 我已经看到这从10分钟到惊人的45分钟。
有没有人有任何提示如何加快启动EC2实例？ 由于Windows服务器的AMI比Linux AMI要大，例如，我想知道是否有一件事可能是确保包含AMI的S3存储桶位于启动实例的同一个区域中，据推测更快地configuration新实例。
我昨晚安装了一个香草Windows 2003服务器的3个实例。 前两天花了大约45分钟，第三天大概一个小时后，花了整整两个小时准备好了！
那些没有任何东西，没有任何S3的使用。 我怀疑除了等待亚马逊部署速度提升之外，还有什么方法可以加速这个基本步骤。 所以，我会得出这样的结论，预计会有一定的延迟，而库尔特的build议是好的，那就是保留已经准备好的1或2个储备。
你可以做的另一件事是几次和时间创build一个AMItypes的新实例。 然后尝试几次你的S3存储，看看它增加了多less时间。 我认为可用区域应该匹配图像和S3，但我不知道会有多less时间差。
一旦确定了最大的configuration时间，在那么多分钟的时间内就要保持在负载/使用状态之前。
亚马逊Windows实例在启动时重新启动，因为“EC2configuration”窗口服务的默认configuration是将您的主机重命名为实例的内部DNS名称。 重命名主机需要在Windows上重新启动。 如果您不需要使用实例的内部DNS名称，则可以通过禁用SetComputerNamefunction来获益。 Windows实例还具有无需初始化启动驱动器的优点，您可能已经将configuration再次捆绑在一起，从而在启动实例时节省了一些时间。 所有这些都可以通过EC2 Windowsconfiguration服务来实现。
Windowsconfiguration服务： http : //docs.amazonwebservices.com/AWSEC2/latest/UserGuide/appendix-windows-config.html
我的Windows小实例通常需要15-18分钟才能启动（更大的更快）。 根据您的要求，您可以将AMI中的所有软件捆绑在一起，并能够在此期间启动并运行所有软件。 我明白没有将所有东西都捆绑到AMI中的保留意见，但是在启动时间上可能需要改进生产AMI以及捆绑的所有AMI。 如果你想在你的构build环境中保持构build脚本的分离。
此外，现在亚马逊已经发布了EBS根卷，而不是实例存储根卷。 运行在EBS卷上的Windows小图像在接近20分钟的时间内启动了将近5分钟。 你也不需要终止 – 你可以停止/启动它们，这取决于你的设置，这可能会在一些启动脚本中再浪费几分钟的时间。
基本上自定义您的Windows EC2configuration服务，您的AMI和潜在的使用EBS启动卷应该减less启动时间近5分钟。 您可以避免在ec2实例启动时运行的sysprep，具体取决于您的应用程序，特别是为了开发目的。 避免启动时更改主机名的非sysprepped m1.large映像可以在大约2分钟内启动，这一点都不错。
就目前而言，就我所知，这是您在Amazon EC2上使用Windows所能做的最好的，但实际上并不算太坏。 如果根据平均使用模式能够预测将近10分钟，则应该能够启动额外的实例并处理额外的负载。
有一个最小的系统，尽可能保持在EBS可能有帮助？ 或者采取一种阿帕奇风格的方法，运行一到两个储备？
我们遇到了这个问题，但是非常严肃 – 我们的新创业公司将Amazon EC2扩展到虚拟实验室环境（多用户，策略，共享等），所以我们需要加快开始时间Windows机器。 我们最大的决定是在我们的应用程序中只支持基于EBS的卷，因为它们是唯一能够在5-10分钟内启动的卷。 在我们的testing中，我们发现实例存储的启动时间变化很大，有时会花费过多的时间，这使得它们对我们无用。
Simon @ LabSlice EC2上的虚拟实验室pipe理