awe.sm從創立之初就采用了AWS平臺，過去3年我們體驗了AWS的優美和不足，并總結出一套最佳實踐。

不夸張的說，AWS徹底改變了科技創業公司的經濟運行模式。沒有人意識到有多少公司正在使用AWS的EC2，直到它發生宕機“真相”才浮出水面。每個人使用AWS都可以從根本上實現非常簡單的運行軟件的方式，并節省大量硬件投資。

圖：AWS的優勢和缺陷讓人既愛又恨EC2是一種運行軟件新的方式

首先，也是最重要的，EC2絕不僅僅是虛擬托管服務器?；蛘哒f，它就像雇傭了部分系統和網絡管理員：代替一名昂貴的管理員，實現自動管理，你只需要為每個虛擬機支付一點點費用而已，并將產生的問題匯總。供電、網絡拓撲、硬件成本、供應商選擇以及網絡存儲系統——在2004年以前這些你都需要考慮。而通過AWS和其它競爭對手的努力，你不用再考慮這些，至少不用考慮這么多。

毫無疑問，彈性是使用EC2最大的優勢和特色，我們只需要約5分鐘就能建立一個虛擬機，這將讓我們有更高的靈活性：

我們可以在新的硬件上進行大規模升級。當我們進行大規模升級時，可以完全建立全新的硬件以及設置和依賴關系，并把它們裝入負載均衡器，然后重新設置負載均衡器即可。當然最后要把之前運行的虛擬機關機。你需要2倍的硬件來進行升級切換，但只需要使用24小時，絕對的廉價和簡單。

對于一些非關鍵系統的備災計劃(這些非關鍵系統最長允許宕機1個小時)，我們只要監測到宕機的虛擬機，然后新啟動一個虛擬機然后做系統還原即可。

依照負載進行擴容絕對好過事先的判斷：當監控到負載很高時，你可以開啟額外的虛擬機，及時應對高負載。

我們根本不擔心對虛擬機數量進行計算：我們總有用不完的虛擬機可供啟動，如果我們出錯了，可以很容易的關閉或者啟動虛擬機。這樣的硬件迭代就是AWS最棒的功能。

EC2為初創企業帶來強大的財務支持

AWS的最明顯的成本優勢是硬件零安裝成本：你使用與亞馬遜相同的帳戶從互聯網上訂購，按一下按鈕，并啟動服務器，按小時支付。你只需支付正在運行的硬件，以及實際使用的存儲，這讓你的啟動成本達到最小。同時，這將鼓勵在硬件層面實驗：在現有的資源上增加10倍，運行負載測試，然后關閉這些增加的虛擬機，直到你真正需要它們。這不僅僅方便，而且是革命性的。

AWS能夠降低運營成本。截至到2012年，我們的公司已經運營了2年多，我們甚至沒有專業的運維人員。不過我們依然有一名的全職的運維人員負責管理數以百計的虛擬機，這是相當高的效率。我們根本不用考慮供電、網絡等等。

當然，AWS并非完美，他的價格超過競爭對手不少。但借助定期的降價，10月份的18%，今年3月的10%。最后，如果長期使用，你可以預先支付費用，并獲得最多50%的折扣。

但是EC2有一些問題

EC2有嚴重的性能和可靠性問題，重要的是要做到心中有數，并提前做出應對計劃。

首先，AWS那臭名昭著的“可用地區”模式，這些分布在不同地區的物理設備彼此分離，包括網絡、供電等。關于“可用地區”我們有幾條非常重要的經驗：

虛擬設備不可能像硬件設備那樣長久：根據我們在過去3年的觀察，虛擬機的平均生命周期約為200天。這之后的“退休”將經歷非常高的風險，AWS的“退休機制”根本不可控：有些時候提前10天通知你虛擬機將被關閉;有時候虛擬機已經關閉2小時后，才收到通知郵件。頻繁的硬件更迭并不是太大的問題，畢竟你可以很輕松的啟動新的虛擬機來替代，但重要的是你應該意識到，要盡早進行自動部署，以減少更換虛擬機所需的時間。

你需要是在一個以上的區域進行部署，并建立冗余。這一直是我們的經驗，你可能失去整個區域，而不是一個虛擬機。如果你的系統有單點故障，你不能從故障虛擬機中獲取備份或設置信息，如果整個區域不可用，你甚至連這個虛擬機都看不到，更別提恢復數據了。

多區域故障也可能發生，因此，如果你能負擔得起，也要部署多個區域。美國東部是故障頻發​的地區(因為歷史最長，價格最便宜)，2012年6月、2012年3月，以及最引人注目故障是在2011年。AWS的不穩定性似乎有相同的根本原因。

為了保持較高的正常運行時間 我們已經不再相信EBS

這就是我們的經驗和亞馬遜的市場建議最沖突的地方。AWS期望EBS是使用EC2的基礎：AWS希望你將所有的數據托管在EBS卷上，一旦實例故障，你能立刻將EBS卷遷移到新的硬件上，這一過程很輕松。AWS還希望你使用EBS快照來對數據庫備份并恢復。AWS同樣希望你在EBS卷上運行操作系統，即EBS備份實例。但根據我們的經驗，EBS有幾大挑戰：

EBS卷的I/O性能太差。虛擬化的硬件的I/O性能顯然不如純粹的硬件，但我們的經驗卻相反，EBS卷的性能遠不如本地存儲(AWS稱之為“短暫存儲”)。EBS卷本質上是網絡存儲，所以性能不會非常好。AWS試圖游說用戶使用定制IOPS，這是一種更高性能的EBS卷，但它的價格會拒你千里之外。

EBS基于地區的可用性?；谖覀兊慕涷?，EBS有兩個特性：所有的卷可用，或都不可用。在前文提到的3起地區性的EC2事故中，2起是由EBS故障從一個地區擴展到其它地區引起的。如果你的故障恢復計劃建立在EBS卷基礎上，當遇到EBS故障引起的宕機，你就要倒大霉了。悲催的是，這種情況我們已經遇到好幾次了。

基于Ubuntu的EBS故障十分嚴重，因為EBS卷實際上通過網絡驅動偽裝成塊設備，這與Linux系統不兼容。我們曾經遇到由此引發的嚴重事故，EBS卷故障導致整個虛擬機鎖定，無法遷移，甚至對任何磁盤需求都不予響應。

因此，大約半年前開始，我們完全放棄了EBS。我們付出了相當大的代價(主要是圍繞如何執行備份和恢復系統)。截至到目前看，這么做絕對值得。

請注意：其他AWS服務依賴于EBS

由于一些的AWS增值服務是建立在EBS中，當EBS故障時，他們也隨即失效，包括彈性負載均衡ELB、關系數據庫RDS、EB(Elastic Beanstalk)以及其它。在我們的經驗中，EBS總是位于故障的中心。所以，如果EBS發生故障，你需要迅速的將流量轉換到其它地區，但很遺憾，你根本無法完成切換，因為負載均衡就運行在EBS上。同時，你也不能啟動新的設備，因為AWS提供的控制臺服務也是運行在EBS上的。所以，我們愛EC2(以及真的真的愛S3)，但我們不用AWS提供的任何附加服務。這么做的好處是，我們可以相對簡單地切換到其他托管服務提供商，而不是密切的鎖定在AWS。

吸取的經驗教訓

如果我們明天再次啟動awe.sm，我會不加思索的繼續使用AWS。對于一個小團隊而言，你只有很少的預算，還需要迅速作出反應，AWS就像一部高性能的全自動相機。Joyent、Rackspace等IaaS提供商正加緊追趕，我們期待著與他們的合作。當我們從100多臺虛擬機增長到1000臺后，必須引入更多的供應商，或者使用Carpathia的與AWS兼容的混合云方式。