我已经使用 Windows Azure 和 Amazon Web Services EC2 工作了好几个月（几乎达到了几年的范围），而且我一遍又一遍地看到一些似乎令人不安的事情。
当我将 Windows Azure 中的 .NET 构建部署到 Web 角色（或服务角色）中时，它通常需要 6-15 分钟才能启动。在 AWS 的 EC2 中，启动映像所需的时间大致相同，然后将应用程序部署到 IIS 需要一两分钟（当然还有待设置）。
但是，当我使用 SUSE Linux 和 Mono 启动 AWS 实例以运行 .NET 时，我会在大约 2-3 分钟内启动其中一个并将代码部署到其中（同样，等待设置）。
Windows 操作系统映像是怎么回事，导致它们在云中启动需要很长时间？我不想要 FUD，我很好奇导致这种情况的具体细节。任何有关此的具体技术信息将不胜感激！谢谢。
我不认为 EC2 行为特定于云。只需比较本地系统上 Windows 和 Linux 的启动时间 - 根据我的经验，Linux 启动速度更快。通常，这是因为启动的服务/恶魔的数量较少，它们每个人在启动期间需要进行的磁盘访问次数也是如此。
至于 Azure 的启动时间：很难说，也无法与机器启动 (IMO) 相提并论。没有人知道 Azure 在启动应用程序时会做什么。可能是他们需要先组装 VM 映像，或者发生大量日志记录/报告会减慢速度。
正如在 PDC 上宣布的那样，Azure 将很快开始在 Azure Web 角色上提供完整的 IIS。在 Don Box 的主题演讲演示中，他展示了这允许您使用 Visual Studio 中的标准“发布”选项快速部署到云中。
如果我没记错的话，开始一个新的 Azure 角色时会发生的部分事情是配置网络组件，我记得有一次会议上的一些演讲者提到这非常耗时。这也许可以解释为什么向已经运行的角色添加额外的实例通常更快（但并非总是如此：我看到这在某些情况下也需要超过 15 分钟）。
编辑：另见此PDC session。
不要忘记，有一个 Fabric 控制器需要检查故障区域并跨多个故障区域部署您的虚拟机（为您提供高可用性，至少在有两个以上实例时）。我不能肯定地说，但这个逻辑本身可能需要一些额外的时间。这也可以解释为什么网络设置可能有点复杂。
这当然会解释云中的启动时间与本地或亚马逊中 Windows 的启动时间之间的差异（如果有的话）。操作系统的任何差异完全取决于操作系统的构建方式！