Answers:
我在2011年至2013年期间在AWS上托管了Magento。在DevOps主题下，与使用云基础架构（而不是传统的专用或共享托管）相比，您获得的许多好处都得到了更相关的描述，DevOps并不是AWS专有的，而是可以通过以下方式轻松启用它的使用。
最小的占用空间将是该域中的1个ELB，2个位于单独AZ中的EC2 Web服务器，1个多Az RDS，Route53托管区域。最初，您可以在ELB上使用粘性会话来简化会话管理，但是随着流量的增加，您需要将媒体移至CDN（S3和CloudFront）中，并将会话移出各个计算机。
我没有看过但仍然很有希望的领域：CloudFormation脚本，用于更轻松地部署Magento堆栈，通过DynamoDB卸载订单创建，以及用于更大结帐吞吐量的工作人员队列（有人已经在一个黑客马拉松上启动了通过MongoDB做到这一点的项目最近），并使用Route53通过基于延迟的路由来建立多区域存在。
我想我有点像云技术的传播者。特定于AWS的c3.large是生产Web服务器的合适的实例大小，但是我会从每个实例类中最小的实例开始，并按照您认为合适的方式衡量性能并扩展或优化代码，这就是为什么我将所有人推荐给xhgui不断。
这是我们在Angrybirds网站上执行的操作：
当前的德语“ PHP Magazin”也有6页的文章（德语），其中包含一些详细信息
阅读了上面多次链接的所有Fabrizio演示文稿后，我认为此答案确实是最好的答案，尽管我同意它可以使用更多的解释并从演示文稿中提取关键思想（特别是因为原始的第一个链接已经在我发布此更新时已被404删除）。
我要添加到演示文稿中的关键概念的唯一一件事是，AWS /竞争对手技术的现代进步会带来一些调整……例如，事实上Cloudfront确实支持gzip来改善CDN性能，尽管它的速度不如以前。是否可以像CloudFlare一样为您提供免费的SSL终止。他们的Route 53 DNS还不如CloudFlares快或功能丰富，AWS也没有类似的Web应用程序防火墙或DDOS保护，所有这些都包含在CloudFlare产品中...
还有其他几种可能的方法可以改善Fabrizio的原始演示文稿，但是如果我在我回答的每一个StackExchange帖子上都放弃了我所知道的一切，那我将不是一个好的顾问。再加上一些最新的产品将大大改变原始演示文稿中的建议，即使使用不同的选项可以从AWS中挤出更多建议，所有这些仍然可以提供出色的性能。
关键概念摘要：
充分了解您的瓶颈：并适当优化。堆栈的每一层都有特定的瓶颈（带宽，cpu，数据库），解决每一层的瓶颈需要针对每个特定挑战优化的不同解决方案，尽管真正的缓存是每个级别的共同要素，这导致...
缓存所有事物：尽可能利用AWS系统（用于Redis / Memcache类型数据缓存的Elasticache，用于缓存映像，js和CSS资产的Cloudfront通过CDN距离最近的用户）和Varnish，以加快服务器实例对初始资产级别的响应速度缓存来自CDN的请求。另外，在部署到CDN之前，请确保压缩和最小化您的部署系统
自动缩放至关重要：需求更改的频率和速度要比您可以手动监视和响应的速度更快。实时适应这些变化需要使用AWS中可用的自动化工具（例如Auto-Scaling Groups）来启动最适合此任务的系统部分。AWS为CloudFront CDN，Route 53 DNS，Elastic Load Balancer和S3 Buckets透明地处理此问题，您必须通过调整EC2实例的大小并自动缩放，以及仅调整RDS和Elasticache层的大小来进行处理。
自动化是将所有这些有效地结合在一起的唯一方法：拥有如此众多相互关联的组件，其中一些必须在部署时进行初始化，某些必须在部署后立即进行初始化，因此，为优化性能而调整的系统的管理需要自动化。利用部署和系统自动化进行缓存清除，缓存预热，图像处理等是管理众多不同子系统并使它们保持良好状态且无问题的唯一合理方法。
但是实际上，如果没有测试自动化，那甚至是不可能的：有了这么多的活动部件，几乎所有的更改都会破坏某些东西。而且您将需要进行更改以跟上Magento和AWS的发展。而且这些将经常发生。因此，为了使变更成本最小化，需要实施和完全自动化所有形式的测试-从单元测试到集成测试，再到在模拟生产环境的实际测试配置中启动的实际站点的基于Selenium的功能测试。现在，您真的很高兴您可以自动化所有部署过程，对吗？
一个稍微简单的（！）解决方案就是像在其他任何VPS上一样进行安装。几年来，我一直在提供免费图片...最近，由于它是本地的，我一直专注于新的悉尼特区- 如果您有更多详细信息，请访问http://www.greengecko.co.nz/magento_on_amazon_ec2对那个感兴趣。几乎零痛苦的入门指南-一键即可到达。将您的浏览器指向实例以获取更多详细信息。这将是一个很好的起点-但是如果您要在/etc/rc.local上构建它，请查看并修改它。
要实现的重要事情是实例的功耗很低。显然，在应用程序上投入很多钱确实可以改善这一点，但是即使对于中等规模的网上商店，中等实例也是绝对最小值，仅用于获得多个内核，而真正大型实例则是最小的必要条件。
此外，Amazon存储速度很慢。因此，从内存中提供可能的所有功能比平时更为重要：调整数据库，内存支持的缓存等势在必行。
排序后，就可以了。如果您想要> 1个IP地址，则在VPC中运行的要求确实很烦人（尤其是如果您在开始时没有意识到这一点！），实际上，您将遇到的唯一难题。
“实时”扩展平台很简单-最终唯一的瓶颈变成了PHP可用的处理能力（不包括效率低下的代码！），并且并行运行多个“引擎”可能是最简单的选择-在运行时将其他功能联机必要。
请享用！
史蒂夫
我们正在运行RDS Multi AZ，两台NGINX优化服务器，两台Varnish服务器+ ELB，并且在同一台Varnish服务器（与Varnish不同的端口）上使用SSL Nginx。我们使用Elasticache，并希望很快将DynamoDB集成到Magento的会话管理中。我们也使用S3和Cloudfront。
我与一家英国托管公司进行了有趣的聊天，我们每月有700英镑的服务器。他们所做的只是让Amazon AWS上榜。通过在所有领域进行正确的设置和优化，包括回带Magento，禁用模块，类别计数功能等（我们已经对NIGNX和Varnish Server进行了微调，使其位于负载均衡的数据库服务器的前面）。
目前，我们可以在首页，类别，产品和CMS页面（清漆页面）上每秒获得2400-3000 +次点击。无光页面，根据商店的不同，我们每秒可以处理400-500个请求。我们现在将RDS Multi与Reads一起使用。
我们还将Magento Admin放在其自己的Node上，以运行cron和管理流量。 http://administraton.mymagestore.com/admin
我们从未回头。我们使用的是英国最好的主机之一，因为它是昂贵的主机。
您几乎可以使用所有基本的AWS服务来使magento工作。最简单的情况是将EC2与Elastic IP和AWS VPC一起用于安全性配置。
明智的方法是进行2个服务器部署：Web服务器+数据库。Web服务器包括Magento + Nginx + PHP +后端缓存（Redis或APC是一个不错的选择），以及在同一子网中的单独MySQL服务器。这些服务器可以通过专用网络（通过VPC配置）中的专用IP彼此可见。Nginx只要可以超快地交付静态文件，便是首选的Web服务器。
数据库服务器应从任何访问中隐藏。Web服务器将在端口80和443上可见。可以为Web服务器分配弹性IP。稍后，配置DNS（例如通过AWS Route 53）或AWS负载平衡将很有用。
如您所述，进行这种配置可能很痛苦。因此，您可以通过Deploy4Me加快设置。它将在几分钟内配置所有提到的安全性，VM和网络。