AWSが存在するときになぜ人々はHerokuを使用するのですか？HerokuとAWSの違いは何ですか？[閉まっている]

私はHerokuを使用してアプリをデプロイすることを計画している初心者のRoRプログラマーです。他のアドバイザーの友人からの言葉によると、Herokuは本当に簡単で使いやすいとのことです。唯一の問題は、Herokuが何をしているのかまだ分からないことです...

私は彼らのWebサイトを見てきたが、簡単に言うと、Herokuはスケーリングを支援するのですが、なぜそれが重要なのでしょうか。Herokuはどのように役立ちますか？

1. 速度-私の調査では、米国/アジアを拠点とする対象者を対象としている場合、AWSを米国東海岸に展開するのが最も速いと示唆しています。

2. セキュリティ-それらはどのくらい安全ですか？

3. スケーリング-実際にはどのように機能しますか？

4. コスト効率-簡単にスケーリングできるdynoのようなものがあります。

5. 彼らはどのように競争相手に対抗していますか？たとえば、Engine Yardとbluebox？

説明に素人英語の用語を使用してください...私は初心者プログラマーです。

AWS / Herokuはどちらも（最初から）小さな趣味のプロジェクトには無料です。

アーキテクチャをあまりカスタマイズせずにすぐにアプリを起動する場合は、Herokuを選択します。

アーキテクチャに重点を置き、さまざまなウェブサーバーを使用できるようにする場合は、AWSを選択します。AWSは、選択したサービス/製品によってはさらに時間がかかりますが、それに見合う価値があります。AWSには、多くのプラグインサービスと製品も付属しています。

Heroku

• サービスとしてのプラットフォーム（PAAS）
• 良いドキュメント
• 組み込みのツールとアーキテクチャがあります。
• アプリの設計中のアーキテクチャの制限付き制御。
• デプロイは処理されます（GitHubを介して自動、また​​はgitコマンドまたはCLIを介して手動）。
• 時間はかかりません。

AWS

• サービスとしてのインフラストラクチャ（IAAS）
• 多用途-EC2、LAMBDA、EMRなどの多くの製品があります。
• 専用インスタンスを使用して、OS、ソフトウェアバージョンの選択など、アーキテクチャをより詳細に制御できます。複数のバックエンドレイヤーがあります。
• Elastic Beanstalkは、HerokuのPAASに似た機能です。
• 自動展開を使用するか、独自に展開できます。

まず最初に、AWSとHerokuは異なります。AWSはサービスとしてのインフラストラクチャ（IaaS）を提供し、Herokuはサービスとしてのプラットフォーム（PaaS）を提供します。

違いは何ですか？概して、IaaSは、その上に物事を構築するために必要なコンポーネントを提供します。PaaSは、コードといくつかの基本構成をプッシュし、実行中のアプリケーションを取得するだけの環境を提供します。IaaSを使用すると、より多くのパワーと柔軟性を得ることができますが、自分でより多くを構築して維持する必要があります。

AWSでコードを実行し、Herokuデプロイメントのように見えるようにするには、いくつかのEC2インスタンスが必要です。それらにロードバランサー/キャッシングレイヤーをインストールする必要があります（たとえばVarnish）。インスタンスは次のように実行する必要があります。Passengerとnginxがコードを提供するには、PostgreSQLなどのクラスター化データベースインスタンスをデプロイして構成する必要があります。Capistranoのようなものと、ログの集約を行うもののあるデプロイメントシステムが必要になります。

これは、設定して維持するのに取るに足らない量ではありません。Herokuでは、このような段階に到達するために必要な作業は、おそらく数行のアプリケーションコードとgit pushです。

だから、あなたはここまで来て、あなたはスケールアップしたいと思っています。すごい。EC2のデプロイメントにPuppetを使用していますか？したがって、必要に応じてインスタンスをスピンアップ/スピンダウンするようにCapistranoファイルを構成します。VarnishがWebワーカーインスタンスを認識し、それらの間で自動的にプールするように、Puppet構成を再ジグします。またはあなたheroku scale web:+5。

うまくいけば、2つの比較を理解できます。次に、特定のポイントに対処します。

速度

現在、Herokuは、us-eastおよびのAWSインスタンスでのみ実行されますeu-west。あなたにとって、これはとにかく欲しいもののように聞こえます。他の人にとっては、それは潜在的にもっと考慮すべきことです。

安全保障

私は、セキュリティ更新が遅れている、または一般的にうまく統合されていない、内部で保守されている多くの運用サーバーを見てきました。Herokuを使用すると、他の誰かがそのようなことを管理します。これは、それをどのように見るかによって祝福か呪いのどちらかです。

デプロイすると、効果的にコードがHerokuに直接渡されます。これはあなたにとって問題になるかもしれません。Dyno分離に関する彼らの記事は、それらの分離技術について詳述しています（複数のdynoが個々のEC2インスタンスで実行されているようです）。数人の同僚が、これらのテクノロジーとそれらの分離の強さに関する問題を表明しています。私は本当にコメントするのに十分な知識/経験の位置に残念ではありませんが、私の現在のHerokuデプロイメントはそれを「十分に良い」と考えています。それはあなたにとって問題かもしれません、私は知りません。

スケーリング

上記のIaaSとPaaSの比較でこれを実装する方法に触れました。おおよそ、アプリケーションにはProcfileの形式の行があるがあるdyno_type: command_to_runため、たとえば（http://devcenter.heroku.com/articles/process-modelから引用）：

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

これは、

heroku scale web:2 worker:10

2つのwebdynoと10のworkerdynoが実行されます。いい、シンプル、簡単。webは、外界にアクセスできる特別なdynoタイプであり、それに応じてトラフィックをルーティングする素敵なWebトラフィックマルチプレクサ（おそらく何らかの種類のVarnish / nginxの組み合わせ）の後ろにあることに注意してください。ワーカーはおそらく、同様のルーティングのためにメッセージキューを操作し、そこから環境内のURLを介して場所を取得します。

コスト効率

多くの人がこれについて多くの異なる意見を持っています。現在、1時間あたり0.05ドルですが、AWSマイクロインスタンスの場合は0.025ドル、AWS小規模インスタンスの場合は0.09ドルです。

Herokuのdynoのドキュメントには、約512MBのRAMがあると書かれているので、おそらくdynoをEC2マイクロインスタンスのように考えるのはそれほど不合理ではありません。価格の2倍の価値はありますか？あなたはあなたの時間をどれくらい大切にしていますか？この標準に到達するためにIaaSオファリングの上に構築するのに必要な時間と労力は、決して安くはありません。この質問にはお答えできませんが、セットアップとメンテナンスの「隠れたコスト」を過小評価しないでください。

（少し余談ですが、ここからdyno に接続すると（heroku run bash）、ざっと見たところ、4コアのイン/proc/cpuinfoメモリと36 GBのRAMが表示されます。これにより、「ハイメモリダブルエクストララージインスタンス"。Herokuののダイナモのドキュメントでは、私は潜在的に71他のdynosまでと共有していますので、各ダイノは、512MBのRAMを受けると言います。（あなたの走行距離は変更になる場合がありますので、私は、HerokuののAWSインスタンスの同性についての十分なデータを持っていません））

彼らはどのように競争相手に対抗していますか？

これは、私は本当にあなたを助けることができないと思います。私が今まで見た中で唯一の競争相手はGoogle App Engineでした-当時Javaアプリケーションをデプロイしようとしていましたが、使用可能なフレームワークとテクノロジーに対する制限の量は信じられないほど不快でした。これは「単なるJavaのこと」以上のものです。一般的な制限と必要な考慮事項（いくつかのFAQのヒント）の量は、あまり便利ではないように見えました。対照的に、Herokuへの展開は夢でした。

結論

これがあなたの質問に答えてくれることを願っています（ギャップやその他の対応したい領域がある場合はコメントしてください）。私は自分の立場を申し出るべきだと思います。Herokuは「迅速な展開」が大好きです。アプリケーションを開始していて、安価なホスティングが必要な場合（Herokuの無料枠は素晴らしいです-基本的に1つのWeb dynoと5MBのPostgreSQLだけが必要な場合、アプリケーションをホストするのは無料です）、Herokuが私の頼りになるポジションです。いくつかの有料顧客がいて、サービスレベル契約があり、運用などに費やす時間を費やしている「深刻な本番環境での展開」の場合、Herokuにそれだけの制御をオフロードして、AWSまたは私たちのサーバーは、ホスティングプラットフォームとして最適です。

結局のところ、それはあなたにとって最も効果的なものです。あなたは「初心者プログラマー」だと言っています。Herokuを使用すると、Rubyの作成に集中できるので、コードに関連する他のすべてのインフラストラクチャを構築するために時間を費やす必要がない場合もあります。ぜひやってみます。

AWSには、Ruby、Node.js、PHP、Python、.NET、JavaをサポートするPaaSオファリングであるElastic Beanstalkが実際にあります。ほとんどの人は、「AWS」が表示されたら、間違いなくIaaSサービスであるEC2、S3、EBSなどに移動すると思います。

Kristian Glassが言ったように、IaaS（AWS）とPaaS（Heroku、EngineYard）の間に比較はありません。

PaaSは基本的に、開発者がアプリの開発をスピードアップするのに役立ちます。それにより、構成をセットアップしてサーバーやデータベースなどを管理する代わりに、お金を節約し、アプリケーションとビジネスを革新することが最も重要です。PaaSを使用するために購入するその他の機能は、俊敏性、高可用性、モニタリング、スケール/デスケール、専門知識の必要性の制限、容易なデプロイメント、およびコストと開発時間の削減などのアプリケーションデプロイメントプロセスです。

しかし、それでもPaaSの導入に障害をもたらすPaaSには暗い側面があります。

• サーバーとデータベースに対する制御の低下
• 適切に管理されないと、コストが非常に高くなります
• 現在の日付と年齢では時期尚早で疑わしい

上記とは別に、IaaSを管理するのに十分なスキルが必要です。

• ハードウェアの取得
• オペレーティング・システム
• サーバーソフトウェア
• サーバー側スクリプト環境
• ウェブサーバー
• データベース管理システム（Mysql、Redisなど）
• 本番サーバーを構成する
• テストと展開のためのツール
• 監視アプリ
• 高可用性
• 負荷分散/ HTTPルーティング
• サービスバックアップポリシー
• チームコラボレーション
• 生産を再構築

小規模ビジネスの場合、PaaSが最適なオプションです。

• 使った分だけ
• 低い立ち上げコスト
• 配管は専門家にお任せください
• PaaSは自動スケーリング/デスケーリング、負荷分散、災害復旧を処理します
• PaaSはすべてのセキュリティ要件を管理します
• PaaSは信頼性、高可用性を管理します
• Paasは多くのサードパーティのアドオンを管理します

要件に基づいた完全に個別の選択になります。私のPPT ホスティングRailsアプリの詳細を知ることができます。

開発、IT、およびビジネスの目的からこの決定を検討するにはさまざまな方法があるので、それが圧倒的であるように見えても、気分を悪くしないでください。ただし、スケーラビリティについて考えすぎないでください。

要件について考えます。

私は、1日800万を超えるユニークサービスを提供し、巨大な$ MM IT労働者がいない25万ドルの資本ハードウェアからインフラストラクチャ上に構築された1週間あたり数テラバイトのビデオを配信するWebサイトを設計しました。

しかし、私はまた、年間$ 10〜$ 2万を生成するように設計され、トラフィック、データベース、または処理の要件があまりない小規模なWebサイトを所有しており、妥協することなくそれらを$ 10 /月の汎用ホスティングアカウントから実行しました。

将来的には、展開はAWSよりもHerokuに近くなります。自動化が進んでいないインターネットインフラストラクチャのスケーリングのITノブターンにはゼロの価値があり、提供している製品やサービスの価値とは何の関係もありません。

また、商用ウェブサイトにも注意してください。スケーラビリティは、私たちがよく「良い問題」と呼んでいるものです。FacebookやTwitterなどのサイトのスケーラビリティの問題は非常に注目されていますが、成功にマイナスの影響はありませんでした。ニュースさらに多くのサインアップに貢献したかもしれません（すべてのプレスは良いプレスです）。

1日に10万以上の一意を生成するサービスがあり、スケーリングの問題がある場合、実行している言語、データベース、プラットフォーム、インフラストラクチャに関係なく、私はあなたの手からそれを取り除くことができてうれしいです！

スケーラビリティは修正可能な実装の問題です-顧客がいないことは実存的な問題です。

実際には両方を使用できます。Amazonサーバーec2を使用してアプリを開発できます。次に、（gitを使用して）しばらくの間、無料でherokuにプッシュし（herokuの無料枠を使用して一般に提供します）、そのようにテストします。サーバーをレンタルするよりも費用対効果が非常に高くなりますが、もっと制限のあるheroku apiと話し合う必要があります。出典：この方法は、私のオンラインクラスの1つである「Balaji S. SrinivasanとVijay S. PandeによるCoursera / Stanfordのスタートアップエンジニアリング」に採用されました。

まあ、人々は通常、この質問をします：何かをデプロイし始めるときにHerokuまたはAWS。

HerokuとAWSの両方を使用する私の実験、これが私の簡単なレビューと比較です：

Heroku

• プロジェクトタイプをデプロイするための1つのコマンド：Ruby on Rails、Nodejs
• ワンクリックでプラグインやサードパーティを統合できるので、何かを始めるのはとても簡単です。
• 自動スケーリングはありません。つまり、手動でスケールアップ/スケールダウンする必要があります
• 特にシステムがより多くのリソースを必要とする場合、コストは高くつきます
• 利用可能な無料インスタンス
• 空きインスタンスは、非アクティブの場合、スリープ状態になります。
• データセンター：米国とEUのみ
• Heroku run bash（おかげで、アドバイスのためにMJafar Mashを使用して）マシンレベルに飛び込む/アクセスすることができますが、それは一種の制限です！完全なアクセス権がありません！
• DevOpsについて多くを知る必要はありません

AWS-EC2

• これは、OSが事前に設定されている（またはそうでない）マシンと同じなので、Webサイト/サービスをオンラインにするには、ソフトウェア、ライブラリをインストールする必要があります。
• プラグインとライブラリは手動で統合する必要があります、または自動化スクリプト（公開スクリプト＆ユーザーが作成）
• 自動スケーリングとロードバランサーはサポートされているサービスです。システムを構成してシステムに統合する方法を学ぶだけです
• コストは非常に安く、どのサービスとそれを使用する時間数に依存します
• T2.microインスタンスには数時間の無料時間がありますが、通常、毎月数ドルを支払うことになります（まだT2.microを使用している場合）。
• 24時間365日利用できる無料のインスタンスはスリープ状態になりません（料金を支払う必要があるためです:)）
• データセンター：世界中。最適な地域を選択してください。
• 機械レベルに飛び込みます。だからあなたはそれを楽しむことができます
• DevOpsに関するある程度の知識がありますが、それでも問題ありません。Stackoverflowが役立ちます。

AWS Elastic BeanstalkはHerokuの代替ですが、より安価です

• Elastic Beanstalkは2010年からパブリックベータとして発表されました。これにより、展開の作業が容易になります。詳細はこちらへ

• Beanstalkは無料です。支払う費用は、使用するサービスと使用時間数に対するものです。

• 私はElastic Beanstalkを長い間使用していますが、Herokuの代替品になり、安価になると思います。

概要

• Heroku：最初は簡単、無料のインスタンスですが、後で高価になります
• AWS：簡単ではない、利用可能な無料の時間、少し安い、Beanstalkを使用することを心配する必要がある

現在のシステムでは、ステージングにHerokuを使用し、本番にBeanstalkを使用しています！

既存の答えは広く正確です：

• Herokuは非常に使いやすく、デプロイも簡単で、リポジトリ（GitHubなど）の自動デプロイ用に簡単に設定でき、多くのサードパーティアドオンがあり、インスタンスごとにより多くの料金がかかります。

• AWSには、DNS、ロードバランシング、安価なファイルストレージなど、競争力のある価格のファーストパーティサービスが幅広くあり、セキュリティポリシーを定義できるなどのエンタープライズ機能があります。

tl; drについては、この投稿の最後までスキップしてください。

AWS ElasticBeanstalkは、Herokuのような自動スケーリングと簡単なデプロイプラットフォームを提供する試みです。（自動的に作成される）EC2インスタンスを使用するため、EBサーバーは他のEC2インスタンスが実行できるすべてのことを実行でき、実行するのが安価です。

EBでの展開は非常に遅いです。更新の展開にはサーバーごとに10〜15分かかり、Herokuに更新を展開するのに数秒かかるのと比較して、大規模なクラスターに展開すると1時間の大部分がかかります。EBへのデプロイも特にシームレスに処理されないため、アプリケーションの設計に制約が課される場合があります。

ElasticBeanstalkが舞台裏で使用するすべてのサービスを使用して独自のビスポークシステムを構築できます（CodeDeploy、Elastic Load Balancer、Auto Scalingグループ、およびすべてに行きたい場合はCodeCommit、CodeBuild、CodePipelineを使用）。 EC2で単に構成するよりもかなり複雑で少しトリッキーなので、最初のセットアップで数週間かかります。

AWS Lightsailは、リーズナブルな価格のホスティングオプションを提供しますが、デプロイやスケーリングには役立ちません。これは、実際にはEC2オファリングのラッパーにすぎません（ただし、コストはさらに高くなります）。初期設定でbashスクリプトを自動的に実行できるので便利ですが、EC2インスタンスをセットアップするだけのコスト（プログラムで実行することもできます）に比べると非常に高価です。

比較についてのいくつかの考え（遠回りの方法ではありますが、質問に答える）：

1. セキュリティパッチ（およびときどきOSの更新）を使用して、インストールしたすべてを最新の状態に保つことを含め、作業システムの管理の量を過小評価しないでください。

2. 自動展開、自動スケーリング、SSLのプロビジョニングと構成がもたらすメリットを過小評価しないでください。

   Gitリポジトリを更新するときの自動デプロイメントは、Herokuを使用すれば簡単です。これはほぼ瞬時に正常に行われるため、エンドユーザーの停止はなく、テスト/継続的インテグレーションに合格した場合にのみ更新するように設定できるため、壊れたコードをデプロイしてもサイトが壊れることはありません。

   ElasticBeanstalkを使用して自動デプロイすることもできますが、最初の1週間の設定に費やす準備をしてください。ElasticBeanstalkがデプロイやロジックを処理する方法を操作するには、アセット（CSSやJSなど）のデプロイとビルドの方法を変更する必要がある場合があります。アプリにデプロイして処理を処理します。

   EBを停止せずにシームレスにデプロイするには、複数のインスタンスを実行する必要があるコストを見積もる際に注意してください。EBは、サービスが低下しないように、各サーバーに更新を個別にロールアウトします。Herokuが新しいdynoを起動して廃止するためですそれへのすべての要求が処理されるまで（そしてそれを削除するまで）、古いサービス。

   興味深いことに、EBで複数のサーバーを実行するホスティングコストは、特にアドオンのコストを含めると、単一のHerokuインスタンスよりも安価になる可能性があります。

特に尋ねられていないが、他の回答によって引き起こされた他のいくつかの問題：

1. 生産と開発に別のプロバイダーを使用することは悪い考えです。

   私は人々がこれを提案していることをしびれさせています。理想的には、コードは適切なプラットフォームで問題なく実行できるため、可能な限り移植可能ですが、各ホストのソフトウェアのバージョンは大きく異なります。 Ruby / Python / PHP / Perlのバージョンは、コードを非互換にする方法が異なる場合があり、多くの場合、適切なテストカバレッジがあっても検出されないサイレントな方法です。

   Herokuのようなものをプロトタイピング、小規模なプロジェクト、マイクロサイトに活用することをお勧めします。これにより、構成とメンテナンスに多くの時間を費やすことなく、物事をすばやく構築して展開できます。

   環境全体を複製するコスト（データストア/アドオン、SSLのインストールと構成などのサードパーティサービスを含む）を忘れずに、その決定を行うときは、実稼働インスタンスと実稼働前インスタンスの両方を実行するコストを考慮に入れてください。 。

2. AWSを使用する場合は、BitnamiなどのベンダーからのAWSの事前設定済みインスタンスに注意してください。これらはセキュリティの悪夢です。説明では言及せずに、デフォルトで多くの悪名高い脆弱なアプリケーションを公開することができます。

   代わりに、UbuntuやDebian（またはRPMサポートが必要な場合はCentOS）など、よくサポートされているメインストリームディストリビューションを使用することを検討してください。

   注：Amazonオファーには、RPMを使用するAmazon Linuxと呼ばれる独自のディストリビューションがありますが、これはEC2固有であり、サードパーティ/オープンソースソフトウェアによるサポートが不十分です。

3. あなた可能性のようなものでもセットアップAWS（またはライトセイル1号）のEC2インスタンスとのconfigure フリンまたはdokkuそれに-あなたは、簡単に複数のサイトを展開可能性がある上、あなたはサービスの多くを維持するかになりたい場合は価値がある、それをすることができ新しいものを簡単にスピンアップできます。ただし、セットアップはHerokuを使用するほど自動化されていないため、多くの時間を費やして構成と保守を行うことができます（AmazonのクラスタリングとDocker Swarmを使用してデプロイする方が、セットアップよりも簡単であることがわかりました。 YMMV）。

作業中のプロジェクトのニーズに応じて、AWS ECインスタンス（単独およびクラスター内）、Elastic Beanstalk、Lightsail、Herokuを同時に使用しました。

サービスの構成に時間を費やすのは嫌いですが、Herokuの請求書をすべてに使用し、AWSがわずかなコストで解決した場合、年間数千ドルになります。

tl; dr

お金が問題にならないのであれば、時間を大幅に節約できるため、ほとんどすべてにHerokuを使用しますが、Herokuが提供しない柔軟性と高度なサービスが必要な、より複雑なプロジェクトにはAWSを使用したいと思います。

私にとっての理想的なシナリオは、ElasticBeanstalkがHerokuのように機能する場合、つまり構成が簡単で、迅速かつ優れたデプロイメントメカニズムである場合です。

これとほぼ同じサービスの例はnow.shです。これは実際には舞台裏でAWSを使用しますが、デプロイメントとクラスタリングをHerokuと同じように簡単にします（自動SSL、DNS、適切なデプロイメント、非常に簡単なクラスターセットアップと管理）。

私はNode.jsアプリとDockerイメージの両方のデプロイメントでかなり使用しました。主な注意点は、インスタンスが共有され（低コストに反映されている）、現在、専用インスタンスを購入するオプションがないことです。ただし、彼らのオープンソース導入ツール「今」を使用して、AWSだけでなくGoogle CloudやAzureの専用インスタンスに導入することもできます。

これは、HerokuからAWSに人々を移行するビジネスのかなりの割合を占めています。両方に利点がありますが、Herokuを使用するとしばらくすると厄介になります。特定のレベルの複雑さが必要になると、Herokuの制限で維持するのが容易ではなくなります。

とはいえ、優れたフレームワーク/ツールを備えたAWSに参加することで、Herokuの使いやすさとAWSの柔軟性を実現するオプションが増えています。

面白いことに、Herokuは実際にはバックエンドでAWSを使用しています。すべてのオーバーヘッドを取り除き、EC2のアーキテクチャ管理を行います。（インタビュー中に大企業の上級エンジニアからその知識を得ました）

上手！AWSには高度な開発者のペルソナがある一方で、Herokuは新進の開発者や新興開発者で有名です。DigitalOceanもこの分野の主要なプレーヤーです。Cloudwaysにより、DigitalOceanとAWSをクリックするだけでランプスタックを簡単に作成できるようになりました。すべてのサービスとパッケージをワンクリックで更新する方が、すべてを手動で行うよりもはるかに優れています。

ここで完全にチェックアウトできます：https : //www.cloudways.com/blog/host-php-on-aws-cloud/

HerokuはAWSをバックグラウンドで使用しています。それはすべて、必要なソリューションのタイプによって異なります。あなたがコアLinuxであり、devオプションを使用している場合は、amiを選択してpalcementオプションを選択するなど、最初からvmを作成することについて心配していなければ、AWSを使用できます。これらのネティグリティを持たずに地表レベルで物事をやりたい場合は、herokuを使用できます。

アマゾンウェブサービス（AWS）は、IaaSからPaaSまでの多くのサービスを提供し、99.9999999％の耐久性とデータとインフラストラクチャの可用性を保証します。AWSは、開発者がアプリケーション展開プロセスをパイプライン処理するためのいくつかのツールとともに、インフラストラクチャの自動化を提供します。

一方、Herokuは、クラウド上でプラットフォームを管理するサービスを提供する単なるPaaSです。それがインフラストラクチャであろうとセキュリティであろうと、それはAWSに勝るものはありません。

AWSをHerokuと比較する理由がよくわかりません。AWSはIAAS（サービスとしてのインフラストラクチャ）であり、システムがいかに堅牢で計算的であるかを明確に示しています。一方、Herokuは単なるSAASであり、基本的にはAWSサービスのほんの一部です。では、Herokuを使用して最初の製品をプライムに出荷できるときにAWSのセットアップに苦労するのはなぜでしょうか。

Herokuは無料で、シンプルで、ほとんどすべてのタイプのスタックをWebに簡単にデプロイできます。Herokuは、アプリケーションを稼働中のサーバーに短時間で発送するという面倒な作業をすべて回避するように特別に構築されています。

それでも、両当事者のチュートリアルのいずれかを使用してアプリケーションをデプロイし、比較することができます

AWSドキュメントとHeroku Docs

AWSとHerokuはどちらもクラウドプラットフォームですが、AWSはIaaSであり、HerokuはPaaSであるため、両者は異なります

HerokuはAWSのサブセットのようなものです。AWSは、あらゆるものとして、あらゆるレベルで実装できますが、これは単なるサービスとしてのプラットフォームです。

実装は、ビジネス要件によって異なります。どちらにも当てはまる場合は、適宜使用してください。