通過使用Elastic Beanstalk過度創建EC2實例併爲典型的Java Web應用程序設置tomcat服務器和部署等，我們獲得了哪些優勢？負載均衡，監控和自動縮放是唯一的優勢嗎？手動部署vs. Amazon Elastic Beanstalk
假設我的Web應用程序使用數據庫，我在EC2實例本身安裝了數據庫。當自動調整發生時，數據庫將在新創建的實例中創建，或者它將訪問我在主實例中創建的數據庫...如果在自動調整發生時僅創建副本，那麼實例之間會發生數據同步？
你提到的所有東西，如負載均衡，監控和自動縮放都是絕對有優勢的。
但是，您必須這樣思考：在真實的Platform as a Service（PAAS）中，目標是將應用程序與平臺分開。作爲開發人員，您只需擔心您的應用程序。該平臺「租用」給你。平臺「實例」會自動更新，管理，縮放，平衡等。你只需上傳你的WAR文件，它就可以工作（至少在理論上）。
EC2本身不是PAAS。它更像IAAS（Infrastructure as a Service）。您仍然需要照顧服務器實例，在其上安裝軟件，使其更新等。
Elastic Beanstalk是PAAS系統。 App Engine和Azure等等。
在真正的PAAS系統中，DBMS是獨立於Web應用程序服務器的組件。原因很明顯：DBMS不能安裝在用於應用程序服務器的實例上，因爲由於實例是基於流量創建和銷燬的，DBMS將會丟失！無論如何，將DBMS和應用程序服務器放在同一臺機器/實例中通常不是一個好主意。
在PAAS系統中，DBMS是一項單獨的服務。對於亞馬遜，它將是Amazon RDS。就像使用Elastic Beanstalk一樣，您不必擔心應用程序服務器，只需上傳WAR文件和RDS，就不必擔心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。 （無可否認，這個功能目前有點弱）。
無論如何，在我的概念中，我認爲他想了解我在豆桶中不喜歡的性能，在部署和災難情況下出現故障，並且使用LAMBDA的所有內容都可能相同或更好。很難，但它是高可用性的靈丹妙藥。 – 2016-09-26 21:04:57
只需添加到最後一點：您可以很好地將所有應用程序日誌發送到CloudWatch。 – sebaGra 2018-03-07 14:08:18
很好。只需添加一項：您可以指定一個自定義AMI作爲每個實例創建的基礎。 因此，您可以例如自定義所需的所有配置和應用程序的Apache映像，並將其用作基本AMI（在Beanstalk環境配置中有一個自定義AMI ID字段） 但是，運行時生成的數據確實會被刪除在每個實例終止（和負載平衡器將這樣做！）。 – 2012-04-02 05:24:40
有一件事引起了我的注意，Elastic Beanstalk爲每個部署的環境創建了一個負載平衡器。負載平衡器運行起來並不昂貴，但它們與微型實例的成本大致相同。 – 2012-10-07 01:52:36
@KenLiu，Load Balancer比微型實例更強大。 – BigSack 2013-08-21 14:20:00