AWS EC2上的多站点

我正在研究一个旨在完全运行Amazon Web Services的多站点应用程序。由于它的性质，它会有很大的stream量高峰，其次是长时间的低stream量，所以能够扩展EC2实例是必须的。

到目前为止，我想到的结构是：

_____________________ Elastic Load Balancer _____________________ | V _____________________ [] [] [] [] [] [] [] Autoscaling EC2 With Dynamic Virtual Hosts Global Business Logic _____________________ / | \ / | \ Amazon RDS S3 Site Views? One Per Site for static files

现在我有两个问题：

我应该在哪里保存特定于站点的“视图”或“主题”文件？ S3能够快速处理这些吗？或者每次我需要调整特定网站的主题时，是否真的应该创build新的AMI？
configuration文件。由于每个站点连接到一个单独的数据库，他们每个都需要自己的configuration文件。同样，我是否应该将这些存储在S3上，并且所有EC2实例都会每隔一段时间检查一次S3的更新configuration？

我觉得有一些我不知道的链接。我主要看到的是人们build议你创build一个新的AMI，并closures当前的实例，并用新的替代它们。这似乎是一个沉重的负担，特别是在一个多站点结构中，这些更改可能只针对一个站点。有处理这种types的代码更改的首选方法？

我正在考虑使用的技术是构build自定义AMI，在开始时将下载必要的数据以自行引导。在你的情况下，你可以保持你的网站在S3上，并在启动时下载文件。如果你使用Ubuntu的CloudInit或其他类似的发行版，那么你可以很容易地脚本安装你的网站。我相信它只在第一次启动时运行，所以节点的滚动终止应该得到最新版本的站点。在这种情况下，您不必持续更新AMI。
如果您没有configurationpipe理系统设置，那么使用您需要的configuration将文件保留在S3上非常容易。随着你的成长厨师或木偶可能会更好，但他们需要一些时间来学习。这个文件可以用同样的方式加载，或者使用像Fabric或Capistrano这样的工具来触发。

Fabric和Capistrano可以帮助您触发较小的更新。如果您重复使用CloudInit脚本，则不必对其进行两次编码。 Fabric和Capistrano都可以轻松集成AWS API，以便dynamic查询正在运行的节点，因此您不必维护不断变化的服务器列表。

最近推出的名为“ Packer”的 AMI工具也可能对您有所帮助。在我第一次尝试的时候，我能够在开始教程的30分钟内得到一个新的AMI。它也可以帮助多个地区的AMIs。