我想将我的实例移动到一个小实例的微型实例，但是当我尝试启动一个基于我的Micro实例AMI的新AMI时，它只给出了64位实例的选项。
我最初的艾米是基于Ubuntu 10.04的形象。
是不是可以在64位和32位实例之间移动？
是否有可能使用负载平衡器有32位实例和64位实例一起工作？
我有一个网站/networking应用程序，我将上传大量的数据。 我将从65gig的图像开始，然后移动到100 + gig的图像。
我不确定哪个实例types最适合这个。 我打算使用负载均衡器和自动扩展来增加负载较高时的实例数量。
另外，当使用负载均衡器时，其中一个AMI实例是否成为主映像，剩下的就是它的克隆？
您只能在创build它们的相同体系结构（32位或64位）上启动映像。 微型实例可以是32位或64位，但是如果你在创build时使用了64位图像，那么你就会陷入困境。 如果您的预算能够适应，您可以使用“大”实例而不是“小”实例。
您可以使用不同types的实例进行负载平衡（使用Amazon的ELB或使用例如HAProxy，Squid，varnish等的其他实例）。
我想你最大的问题是你打算存储这些数据的地方。 如果你打算有多个实例提供相同的内容（并被上传到），那么你将需要共享存储 。 你可以使用像GlusterFS这样的东西来共享你的实例之间的数据，或者你可以有一个“存储服务器”，你的networking实例NFS挂载。
自动缩放的工作原理是设置“启动图像”，即“主”图像的AMI标识。 然后启动这个图像来响应触发（即负载太高）。 思考这个概念是什么意思很重要 – 这意味着每个启动的实例将基于原始图像，不会有新的数据或更新的configuration等。
所以，总结一下 – 如果你打算使用多个Web服务器，那么你需要某种forms的共享存储。 通常这是数据库（可能在亚马逊的RDS服务上），但是听起来你需要存储大量的“文件”而不是数据，所以你需要分布式存储或存储服务器。
根据Amazon EC2实例描述页面 ，Micro实例可用32位和64位， 而Small实例types仅可用于32位 。 这就是您不能在Small实例types上启动您的初始64位AMI的原因。
关于您的负载均衡问题：这很大程度上取决于您的使用模式 – 32位和64位实例types可以在负载均衡器后面一起工作，没有任何问题。 不过，我会build议坚持一个实例types。 总的来说，如果你只是简单地上传图片而不是上传图片，那么我认为你最关心的应该是I / O和内存。 我会build议只是试一试，使用您的Web应用程序所需的最小设置，并使用两种实例types进行一些负载testing。