AWS / Heroku 都适用于小型爱好项目（起步阶段免费）。

如果你想要马上启动一个应用而不需要太多架构的自定义，那么选择 Heroku。

如果你想要专注于架构并且能够使用不同的 Web 服务器，那么选择 AWS。AWS 根据你选择的服务/产品而耗时更长，但是值得。AWS 还带有许多插件服务和产品。

Heroku

• 作为服务的平台（PAAS）
• 有良好的文档
• 有内建的工具和架构。
• 在设计应用程序时架构的控制力有限。
• 部署已处理好（通过 GitHub 自动化或通过 Git 命令或 CLI 手动执行）。
• 耗时不长。

AWS

• 作为基础架构的服务（IAAS）
• 多功能性——有许多产品，例如 EC2、LAMBDA、EMR 等。
• 可以使用专用实例，以便更好地控制架构，例如选择操作系统、软件版本等。有不止一个后端层。
• Elastic Beanstalk 是类似于 Heroku 的 PAAS 的功能。
• 可以使用自动化部署或自己实现。

首先，AWS和Heroku是不同的。AWS提供基础设施即服务（IaaS），而Heroku提供平台即服务（PaaS）。

两者有什么区别？大致而言，IaaS为您提供构建应用程序所需的组件，而PaaS为您提供运行应用程序所需的环境，您只需要推送代码和一些基本配置即可。IaaS可以提供更强大和更灵活的功能，但代价是需要自己构建和维护更多。

要在AWS上运行代码并看起来与Heroku部署类似，您需要一些EC2实例 - 您需要在它们上安装一个负载均衡器/缓存层（例如Varnish），您需要运行类似Passenger和nginx的实例以提供您的代码，您需要部署和配置类似PostgreSQL之类的集群数据库实例。您需要使用像Capistrano这样的部署系统，并进行日志聚合。

这不是一个微不足道的工作量来设置和维护。在Heroku上，达到那种阶段所需的工作量可能只有几行应用程序代码和一个git push。

所以，您已经走了这么远，想要进一步扩展。很棒。您正在使用Puppet进行 EC2 部署，对吗？现在您可以配置 Capistrano 文件以根据需要启动/关闭实例；您可以重新设置 Puppet 配置，使 Varnish 意识到 web-worker 实例并自动在它们之间池化。或者您可以运用heroku scale web:+5。

希望这能让您了解两者之间的比较。现在让我们解决您的具体问题：

速度

目前，Heroku 只在 AWS 实例中运行 us-east 和 eu-west。对您来说，这听起来正是您想要的。但是对于其他人来说，这可能是更多考虑的问题。

安全性

我见过很多内部维护的生产服务器严重滞后于安全更新或整体上做得很差。使用 Heroku，则由其他人管理此类事宜，这是一种福音或诅咒，取决于您如何看待它！

当您部署时，实际上是将您的代码直接交给 Heroku。这可能对您造成问题。他们的Dyno Isolation文章详细介绍了他们的隔离技术（似乎多个 dyno 在独立的 EC2 实例上运行）。有几个同事表达了对这些技术和其隔离强度的问题；很遗憾，我没有足够的知识/经验来真正发表评论，但我的 Heroku 部署目前认为“足够好”。这可能对您造成问题，我不知道。

扩展性

我在上面的IaaS与PaaS比较中涉及了如何实现这个问题。大致来说，你的应用程序有一个Procfile，其中包含形式为dyno_type:command_to_run的行，例如（从Heroku 架构——进程模型借鉴）:

web:    bundle exec rails server
worker: bundle exec rake jobs:work

这个，再加上:

heroku scale web:2 worker:10

将导致你有两个web dynos和10个worker dynos在运行。很好，简单，容易。请注意，web是一种特殊的dyno类型，它具有访问外部世界的权限，并且位于他们出色的Web流量复用器（可能是某种Varnish / nginx组合）后面，它将相应地路由流量。您的工人可能与消息队列进行交互，以进行类似的路由，并从中获得位置（通过环境中的URL）。

成本效益

许多人对此有许多不同的意见。目前每小时的dyno费用为$0.05，而AWS微型实例每小时的费用为$0.025，AWS小型实例每小时的费用为$0.09。

Heroku的dyno文档说你有大约512MB的RAM，所以把dyno看作类似于EC2微型实例可能不太荒谬。它值得两倍的价格吗？你的时间值多少钱？在IaaS提供的基础上构建到这个标准所需的时间和精力绝对不是便宜的。我不能真正回答这个问题，但不要低估设置和维护的'隐藏成本'。

（这是一个小插曲，但如果我从这里连接到dyno（heroku run bash），粗略查看/proc/cpuinfo中显示4个内核和36GB RAM-这让我相信我在使用 "高内存双倍超大实例" 。 Heroku dyno文档说每个dyno收到512MB RAM，所以我可能会与最多71个其他dynos共享。（我没有足够的数据来了解Heroku的AWS实例的同质性，因此您的公里数可能有所不同））

他们与竞争对手相比如何？

对此，我恐怕无法帮助你。我真正看过的唯一竞争对手是Google App Engine - 当时我想部署Java应用程序，可用框架和技术的限制数量令人难以忍受。这不仅仅是“Java问题” -一般限制和必要考虑的数量（FAQ暗示着几个）似乎不太方便。相比之下，部署到Heroku一直是一个梦想。

结论

如果有空缺/其他区域需要解决，请发表评论。我觉得我应该提供自己的个人立场。我喜欢Heroku进行“快速部署”。当我开始一个应用程序，并且我想要一些廉价的主机（Heroku自由层非常棒-如果你只需要一个web dyno和5MB的PostgreSQL，那么免费托管应用程序），Heroku是我的首选。对于“严肃的生产部署”带有几个付费客户，具有服务级别协议，具有专用的操作时间等等，我无法完全将如此多的控制权交给Heroku，然后AWS或我们自己的服务器一直都是首选的托管平台。

最终，这取决于什么对于你来说最有效。你说自己是“初学者程序员” - 使用Heroku可能会让你专注于编写Ruby，而不必花费时间构建代码周围的所有其他基础架构。我肯定会试一试。

请注意，AWS实际上确实有一个PaaS提供，Elastic Beanstalk，支持Ruby，Node.js，PHP，Python，.NET和Java。我认为通常大多数人看到”AWS”时，会想到EC2和S3和EBS等明显的IaaS提供。