好!我观察到Heroku在萌芽和新生的开发人员中很有名，而AWS则是高级开发人员。DigitalOcean也是这一领域的主要参与者。Cloudways使得在DigitalOcean和AWS上点击创建Lamp堆栈变得非常容易。在点击中更新所有的服务和包比手动完成所有的事情要好得多。

您可以在这里查看完整的内容:如何在Amazon AWS EC2上托管PHP

在我们的业务中，从Heroku迁移到AWS的人员占很大比例。两者都有优势，但在Heroku上一段时间后就变得很混乱了……一旦你需要一定程度的复杂性不再容易维持与Heroku的限制。

也就是说，通过在AWS上使用优秀的框架/工具，有越来越多的选择可以获得Heroku的易用性和AWS的灵活性。

好!我观察到Heroku在萌芽和新生的开发人员中很有名，而AWS则是高级开发人员。DigitalOcean也是这一领域的主要参与者。Cloudways使得在DigitalOcean和AWS上点击创建Lamp堆栈变得非常容易。在点击中更新所有的服务和包比手动完成所有的事情要好得多。

您可以在这里查看完整的内容:如何在Amazon AWS EC2上托管PHP

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

有什么不同?大致说来，IaaS为您提供了所需的组件，以便在其之上构建内容;PaaS为您提供了一个环境，在这个环境中，您只需推送代码和一些基本配置，就可以得到一个运行的应用程序。IaaS可以为您提供更强大的功能和灵活性，但代价是必须自己构建和维护更多内容。

为了让你的代码在AWS上运行，看起来有点像Heroku部署，你需要一些EC2实例——你需要在它们上面安装一个负载均衡器/缓存层(例如Varnish)，你需要运行一些实例，比如Passenger和nginx来服务你的代码，你需要部署和配置一个集群数据库实例，比如PostgreSQL。您将需要一个带有类似Capistrano的部署系统，以及一些执行日志聚合的功能。

这不是一个微不足道的工作量来设置和维护。对于Heroku，达到这种阶段所需要的努力可能是几行应用程序代码和一个git推送。

到这里，你想要放大。太好了。您正在使用Puppet进行EC2部署，对吗?现在你可以配置你的Capistrano文件来根据需要旋转实例;你重新调整你的Puppet配置，这样Varnish就能意识到web-worker实例，并自动在它们之间进行池化。或者你heroku scale web:+5。

希望这能让你们对两者之间的比较有所了解。现在谈谈你的具体问题:

速度

目前Heroku只在美国东部和欧盟西部的AWS实例上运行。对你来说，这听起来就是你想要的。对其他人来说，这可能更多是一种考虑。

安全

我见过许多内部维护的生产服务器在安全更新方面远远落后，或者通常只是组装得不好。有了Heroku，你就有了另一个人来管理这类事情，这是福是祸取决于你怎么看!

When you deploy, you're effectively handing your code straight over to Heroku. This may be an issue for you. Their article on Dyno Isolation details their isolation technologies (it seems as though multiple dynos are run on individual EC2 instances). Several colleagues have expressed issues with these technologies and the strength of their isolation; I am alas not in a position of enough knowledge / experience to really comment, but my current Heroku deployments consider that "good enough". It may be an issue for you, I don't know.

扩展

我在上面的IaaS与PaaS的比较中提到了如何实现这一点。大约，你的应用程序有一个Procfile，它的行形式为dyno_type: command_to_run，例如(摘自Heroku Architecture - the Process Model):

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

这里，有一个:

heroku scale web:2 worker:10

将导致你有2个web dynos和10个worker dynos运行。很好，简单，简单。请注意，web是一种特殊的动态类型，它可以访问外部世界，并且在他们漂亮的web流量多路复用器(可能是某种Varnish / nginx组合)后面，将相应地路由流量。您的worker可能会与一个消息队列进行类似的路由交互，它们将通过环境中的URL从该消息队列获取位置。

成本效率

很多人对此有不同的看法。目前动态小时的价格为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个其他dyno共享。(我没有足够的数据关于Heroku的AWS实例的同质性，所以你的里程可能会有所不同))

他们在竞争对手面前表现如何?

这个，恐怕我帮不上什么忙。我曾经真正关注过的唯一竞争对手是谷歌应用引擎——当时我正在寻找部署Java应用程序，可用框架和技术的限制数量令人难以置信。这不仅仅是“Java的事情”——大量的一般限制和必要的考虑(常见问题解答中暗示了一些)似乎不太方便。相比之下，部署到赫鲁库一直是一个梦想。

结论

Please comment if there are gaps / other areas you'd like addressed. I feel I should offer my personal position. I love Heroku for "quick deployments". When I'm starting an application, and I want some cheap hosting (the Heroku free tier is awesome - essentially if you only need one web dyno and 5MB of PostgreSQL, it's free to host an application), Heroku is my go-to position. For "Serious Production Deployment" with several paying customers, with a service-level-agreement, with dedicated time to spend on ops, et cetera, I can't quite bring myself to offload that much control to Heroku, and then either AWS or our own servers have been the hosting platform of choice.

归根结底，这是关于什么最适合你。你说你是一个“程序员初学者”——可能只是使用Heroku可以让你专注于编写Ruby，而不必花时间构建代码周围的所有其他基础设施。我一定要试一试。

---

请注意，AWS实际上有一个PaaS产品Elastic Beanstalk，它支持Ruby、Node.js、PHP、Python、. net和Java。我认为一般来说，大多数人一看到“AWS”，就会跳到EC2、S3和EBS这样的东西上，这些肯定是IaaS产品

有趣的是，Heroku实际上在后端使用AWS。它消除了所有开销，并为您在EC2上进行体系结构管理。(在一次面试中从一家大公司的高级工程师那里得到的知识)

现有的答案大致准确:

Heroku非常易于使用和部署，可以很容易地配置为自动部署存储库(如GitHub)，有很多第三方插件，每个实例收费更高。 AWS拥有更广泛的价格具有竞争力的第一方服务，包括DNS、负载平衡、廉价的文件存储，并具有能够定义安全策略等企业功能。

对于tl;dr，跳到这篇文章的结尾。

AWS ElasticBeanstalk尝试提供一个类似heroku的自动伸缩和简单部署平台。由于它使用EC2实例(它自动创建)，EB服务器可以做任何其他EC2实例可以做的事情，而且运行成本很低。

EB的部署非常缓慢;每台服务器部署一次更新可能需要10-15分钟，部署到更大的集群可能需要将近一个小时——相比之下，在Heroku上部署一次更新只需几秒钟。EB上的部署也不是特别无缝地处理，这可能会对应用程序设计造成限制。

您可以使用ElasticBeanstalk在幕后使用的所有服务来构建自己的定制系统(使用CodeDeploy, Elastic Load Balancer, Auto Scaling Groups -以及CodeCommit, CodeBuild和CodePipeline，如果您想全部投入的话)，但您绝对可以花几个星期的时间来第一次设置它，因为它相当复杂，比仅在EC2中配置东西稍微复杂一些。

AWS Lightsail提供了一个价格具有竞争力的托管选项，但对部署或扩展没有帮助——它实际上只是他们EC2产品的包装(但成本更高)。它允许您在初始设置时自动运行bash脚本，这是一个不错的操作，但与仅设置EC2实例的成本相比(您也可以通过编程方式设置EC2实例)，它的成本较高。

关于比较的一些想法(试着回答问题，尽管是以一种迂回的方式):

Don't underestimate how much work system administration is, including keeping everything you have installed up to date with security patches (and occasional OS updates). Don't underestimate how much of a benefit automatic deployment, auto-scaling, and SSL provisioning and configuration are. Automatic deployment when you update your Git repository is effortless with Heroku. It is near instant, graceful so there are no outages for end users and can be set to update only if the tests / Continuous Integration passes so you don't break your site if you deploy broken code. You can also use ElasticBeanstalk for automatic deployment, but be prepared to spend a week setting that up the first time - you may have to change how you deploy and build assets (like CSS and JS) to work with how ElasticBeanstalk handles deployments or build logic into your app to handle deployments. Be aware in estimating costs that for seamless deployment with no outage on EB you need to run multiple instances - EB rolls out updates to each server individually so that your service is not degraded - where as Heroku spins up a new dyno for you and just deprecates the old service until all the requests to it are done being handled (then it deletes it). Interestingly, the hosting cost of running multiple servers with EB can be cheaper than a single Heroku instance, especially once you include the cost of add-ons.

其他一些问题没有被特别问到，但被其他答案提出:

Using a different provider for production and development is a bad idea. I am cringing that people are suggesting this. While ideally code should run just fine on any reasonable platform so it's as portable as possible, versions of software on each host will vary greatly and just because code runs in staging doesn't mean it will run in production (e.g. major Node.js/Ruby/Python/PHP/Perl versions can differ in ways that make code incompatible, often in silent ways that might not be caught even if you have decent test coverage). What is a good idea is to leverage something like Heroku for prototyping, smaller projects and microsites - so you can build and deploy things quickly without investing a lot of time in configuration and maintenance. Be sure to factor in the cost of running both production and pre-production instances when making that decision, not forgetting the cost of replicating the entire environment (including third party services such as data stores / add ons, installing and configuring SSL, etc). If using AWS, be wary of AWS pre-configured instances from vendors like Bitnami - they are a security nightmare. They can expose lots of notoriously vulnerable applications by default without mentioning it in the description. Consider instead just using a well supported mainstream distribution, such as Ubuntu or Debian (or CentOS if you need RPM support). Note: Amazon offer have their own distribution called Amazon Linux, which uses RPM, but it's EC2 specific and less well supported by third party/open source software. You could also setup an EC2 instance on AWS (or Lightsail) and configure with something like flynn or dokku on it - on which you could then deploy multiple sites easily, which can be worth it if you maintain a lot of services or want to be able to spin up new things easily. However getting it set up is not as automagic as just using Heroku and you can end up spending a lot of time configuring and maintaining it (to the point I've found deploying using Amazon clustering and Docker Swarm to be easier than setting them up; YMMV).

我同时使用AWS EC实例(单独和集群)、Elastic Beanstalk和Lightsail和Heroku，这取决于我正在从事的项目的需求。

我讨厌花时间配置服务，但如果我什么都用Heroku，而AWS只算其中的一小部分，我的Heroku账单每年将高达数千美元。

博士tl;

如果钱从来都不是问题，我会在几乎所有事情上都使用Heroku，因为它节省了大量时间——但我仍然想在更复杂的项目上使用AWS，在这些项目中，我需要Heroku无法提供的灵活性和更高级的服务。

对我来说，最理想的场景是ElasticBeanstalk的工作方式更像Heroku——也就是说，配置更简单，部署机制更快更好。

一个类似于此的例子是now.sh，它实际上在幕后使用AWS，但使部署和集群像在Heroku上一样简单(具有自动SSL、DNS、优雅部署、超级简单的集群设置和管理)。

我在Node.js应用程序和Docker镜像部署中都经常使用它，主要的警告是实例是共享的(这反映在它们的低成本上)，目前没有购买专用实例的选项。然而，他们的开源部署工具“现在”也可以用于部署到AWS以及谷歌Cloud和Azure上的专用实例。