手動デプロイとAmazon Elastic Beanstalk
Elastic Beanstalkを使用してEC2インスタンスを手動で作成し、Tomcatサーバーをセットアップし、一般的なJava Webアプリケーション用にデプロイするなど）で得られる利点は何ですか。負荷分散、監視、自動スケーリングのみが利点ですか？
データベースを使用するWebアプリケーションで、データベースをEC2インスタンス自体にインストールしたとします。自動スケーリングが行われると、データベースは新しく作成されたインスタンスで作成されますか、マスターインスタンスで作成したデータベースにアクセスします。自動スケーリングが発生したときにレプリカのみを作成すると、インスタンス間でデータ同期が行われますか？
負荷分散、監視、自動スケーリングなど、あなたが言及したすべてのことは間違いなく利点です。
ただし、次のように考える必要があります。本当の サービスとしてのプラットフォーム （PAAS）では、目標はアプリケーションをプラットフォームから分離することです。開発者は、アプリケーションについてのみ心配します。プラットフォームは「レンタル」されています。プラットフォームの「インスタンス」は、自動的に更新、管理、スケーリング、バランス調整などが行われます。 WARファイルをアップロードするだけで機能します（少なくとも理論的には）。
EC2自体はPAASではありません。 IAASに似ています（ サービスとしてのインフラストラクチャ ）。サーバーインスタンスの管理、ソフトウェアのインストール、更新の維持などを引き続き行う必要があります。
Elastic BeanstalkはPAASシステムです。 App Engine および Azure もあります。
真のPAASシステムでは、DBMSはWebアプリケーションサーバーとは別のコンポーネントです。理由は明らかです。インスタンスがトラフィックに基づいて作成および破棄されると、DBMSが失われるため、アプリケーションサーバーに使用されているインスタンスにDBMSをインストールできない可能性があります。とにかく、同じマシン/インスタンスにDBMSとアプリケーションサーバーを配置することは、一般に良い考えではありません。
PAASシステムでは、DBMSは独立したサービスです。 Amazonの場合、 Amazon RDS になります。 Elastic Beanstalkのように、アプリケーションサーバーを心配する必要がなく、RDSを使用してWARファイルをアップロードするだけで、DBMSを心配する必要はなく、データベースをデプロイするだけです。
Elastic BeanstalkとRDSは、特にレイテンシが非常に低い同じアベイラビリティゾーンにデプロイされている場合、非常にうまく機能します。
最後に、Elastic Beanstalkを使用しても、デプロイされたリソース（EC2インスタンスとロードバランサー）以外の費用はかかりません。ただし、RDSは安価ではなく、アプリケーションサーバーとDBMSの両方に単一のEC2インスタンスを使用するよりも間違いなく高価です。
Elastic Beanstalkは、ロードバランシング、モニタリング、自動スケーリングだけではありません。
1）アプリケーションの異なるバージョンを保存および管理することにより、アプリケーションのバージョンを管理します。これにより、アプリケーションの異なるバージョン間を簡単に切り替えることができます。
2）アプリケーションごとに「環境」の概念があり、各環境にアプリケーションの異なるバージョンをデプロイできます。これは、たとえば、個別のQA環境とDEV環境をセットアップする場合に便利です。最初にビルドをDEVに簡単にデプロイし、QAチームが次のビルドの準備ができたときに同じバージョンのアプリケーションをQAにデプロイします。
3）重要なコンテナ設定プロパティ（Tomcatメモリ設定など）をElastic BeanstalkコンソールおよびAPIに外部化します。このため、設定を簡単に保存し、環境間でコピーできます。
4）コンソールを介してアプリケーションログファイルを表示し、ログファイルをS3に自動的にロールおよびアーカイブします。 （確かに、この機能は現在少し弱いです。）
EC2専用（Nginx＆Gunicorn）とBeanstalk Environment（CentOS＆Apache2）の両方にアプリをデプロイしました。
私の観察：
BeanStalkはPaasです。 EC2インスタンス（IAAS）を手動で作成することは、すべてをゼロから行うことに似ていますが、確実に制御できます。
BeanStalkには、デフォルトでCentOSとApache（Httpd）が付属しています。専用インスタンスのOSを選択できます。
私にとって重要なこれらのこと、
- Beanstalk環境に表示される504エラーが多数ありました。
- BeanStalkサーバーがクラッシュしたときにデバッグすることは困難でした。ログも表示されず、マシンにsshできなかったからです。これはとても重要です。
- Celery、Redis（別のポートを実行する必要がある）などのツールのインストール/設定。専用インスタンスでは、はるかに簡単です。
私の場合、いくつかのパッケージ（pandocなど）のインストールを実行するために（Beanstalk）サーバーをスケールアップする必要がありました。これらは、Ubuntuの方が簡単です。
BeanStalkでは、スケーリングがはるかに簡単です。 BeanStalkでは、サーバーのクローン作成は簡単です。
私は両方のケースでマイクロを服用していました（専用＆Beanstalk）。専用のマイクロインスタンスの方が優れていると感じました。
Beanstalkでの自動展開。同じことを自動化するスクリプトを書かなければなりませんでした。