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

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

当人们开始部署某个东西时，通常会问这个问题:Heroku或AWS。

我使用Heroku和AWS的实验，这里是我的快速回顾和比较:

希罗库

One command to deploy whatever your project types: Ruby on Rails, Nodejs So many 1-click to integrate plugins & third parties: It is super easy to start with something. Don't have auto-scaling; that means you need to scale up/down manually Cost is expensive, especially, when system needs more resources Free instance available The free instance goes to sleep if it is inactive. Data center: US & EU only CAN dive into/access to machine level by using Heroku run bash (Thanks, MJafar Mash for the advice) but it is kind of limited! You don't have full access! Don't need to know too much about DevOps

AWS - EC2

This just like a machine with pre-config OS (or not), so you need to install software, library to make your website/service go online. Plugin & Library need to be integrated manually, or automation script (public script & written by you) Auto scaling & load balancer are the supported services, just learn how to config & integrate to your system Cost is quite cheap, depends on which services and number of hours you use it There are several free hours for T2.micro instances, but usually, you will pay few dollars every month (if still using T2.micro) Your free instance won't go to sleep, available 24/7 (because you may pay for it :) ) Data center: around the world. Pick the region which is the best fit for you. Dive into machine level. So you can enjoy it Some knowledge about DevOps, but it is okay, Stackoverflow is helpful there!

AWS Elastic Beanstalk是Heroku的替代品，但更便宜

《Elastic Beanstalk》是在2010年发布的公测版本;它帮助我们更容易地进行部署。详情请点击这里 Beanstalk是免费的，您将支付的费用将用于您使用的服务和使用小时数。 我用了很长一段时间的弹性豆茎，我觉得它可以代替Heroku，而且更便宜!

总结

Heroku:开始很简单，免费实例，但之后很贵 AWS:不容易，免费小时可用，有点便宜，豆茎应该关注使用

所以在我目前的系统中，我使用Heroku进行分期，使用Beanstalk进行生产!

正如Kristian Glass所说，IaaS(AWS)和PaaS(Heroku, EngineYard)之间没有可比性。

PaaS基本上帮助开发人员加快应用程序的开发，从而节省资金，最重要的是创新他们的应用程序和业务，而不是设置配置和管理服务器和数据库之类的东西。使用PaaS的其他特性是应用程序部署过程，如敏捷性、高可用性、监视、扩展/去规模化、对专业知识的需求有限、易于部署以及减少成本和开发时间。

但PaaS仍有其黑暗的一面，这阻碍了PaaS的采用:

减少对服务器和数据库的控制 如果管理不当，成本将非常高 在当今时代，不成熟的，可疑的

除此之外，你应该有足够的技能来管理你的IaaS:

硬件采购 操作系统 服务器软件 服务器端脚本环境 Web服务器 数据库管理系统(Mysql, Redis等) 配置生产服务器 用于测试和部署的工具 监控应用程序 高可用性 负载均衡/ Http路由 业务备份策略 团队协作 重新生产

如果您的业务规模较小，PaaS将是您的最佳选择:

现付现付 启动成本低 把管道问题留给专家 PaaS处理自动缩放/除垢、负载平衡、灾难恢复 PaaS管理所有安全需求 PaaS管理可靠性、高可用性 Paas为您管理许多第三方附加组件

这完全是基于个人需求的选择。您可以在我的PPT托管Rails应用程序上获得详细信息。

有时候，我想知道为什么人们把AWS比作Heroku。AWS是一个IAAS(基础设施即服务)，它清楚地说明了系统的健壮性和计算性。另一方面，Heroku只是一个SAAS，它基本上只是AWS服务的一部分。所以，当你可以使用Heroku将第一款产品发布到prime时，为什么还要费劲建立AWS呢?

Heroku是免费的，简单的，容易部署几乎所有类型的堆栈到web。Heroku是专门构建的，可以在短时间内绕过将应用程序传输到活动服务器的所有麻烦。

不过，您可能希望使用双方提供的任何教程来部署应用程序并进行比较

AWS DOCS和Heroku DOCS

现有的答案大致准确:

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上的专用实例。

Actually you can use both - you can develop an app with amazon servers ec2. Then push it (with git) to heroku for free for awhile (use heroku free tier to serve it to the public) and test it like so. It is very cost effective in comparison to rent a server, but you will have to talk with a more restrictive heroku api which is something you should think about. Source: this method was adopted for one of my online classes "Startup engineering from Coursera/Stanford by Balaji S. Srinivasan and Vijay S. Pande