基于AWS用戶的反饋，我們列出了亞馬遜EC2（亞馬遜彈性計算云，云計算服務的核心及基礎，提供非常彈性的實例管理）的五項問題，它們不僅不好解決而且還會迫使用戶另尋它物。
共享EBS卷
EBS（Elastic Block Store，彈性塊存儲）為亞馬遜EC2提供永久存儲。由于去除了對速度緩慢的亞馬遜S3（另一個云計算產品）的依賴，它在2009年一經推出就得到了高度評價。
許多工程師只要加載一個Amazon EC2實例，就會馬上附加一個EBS卷，并將長期需要的數據移動過去。然而四年過去了， EBS需求最旺盛的功能－將同一個EBS卷附加到多個EC2 實例上還尚未實現。 AWS鼓勵在一個load balancer（負載平衡器）后臺運行多個亞馬遜EC2實例來獲得最佳的性能。然而僅在一個EC2實例上運行應用不是個好主意。大多數內容管理系統和媒體驅動的應用程序依賴于共享的存儲。當這些系統都遷移到AWS并放在一個 ELB（Elastic Load Balancing，彈性負載均衡）之后，沒有簡單的策略使得在運行相同應用程序的EC2實例之間來共享內容。
舉例來說，一個終端用戶上傳一個新圖片到由負載平衡器隨機選取的一個內容服務器上。目前而言，復制這一圖片到所有正在運行的服務器是留給開發人員做的。AWS建議使用亞馬遜S3存儲靜態內容，而許多流行的CMS框架期望可以在本地文件系統實現存儲。為了確保所有的服務器共享最新的內容，需要強制實現類似Gluster或NFS式的分布式文件系統。這需要前沿技術，其中涉及啟動一個專用的虛擬機來運行該文件服務器。這也使得配置很不穩定：文件服務器很容易成為單點故障。
如果亞馬遜支持多個EC2實例共享同一個EBS卷，這就能避免對專用文件服務器的需求和對每個服務器進行額外的配置。這其實也不復雜：谷歌計算引擎（Google ComputeEngine）支持在多個實例上同時安裝永久磁盤。雖然只有一個實例有對文件系統的讀寫許可，但是所有的實例將能立即訪問該內容。雖然還只是在技術測試階段，谷歌計算引擎已經在性能和特性方面把目標瞄準了跨越式發展的亞馬遜EC2。早期指標顯示GCE將是亞馬遜EC2的一個可行替代方案。
可配置的ELB流量
ELB（ElasticLoad Balancing，亞馬遜彈性負載均衡，是在EC2基礎上實現的負載均衡服務）提供了一種能將流量均勻地分布在多個亞馬遜EC2實例上的服務。亞馬遜把ELB這種服務定位為近乎神奇，它能提供長久的穩定運行和高可擴展性。根據ELB的官方描述，“它能使你在你的應用程序中獲得更大的容錯能力，無縫地提供用來響應傳入應用流量所需的負載平衡能力。”
對負載均衡容量可以無縫增加的承諾肯定帶有誤導性，因為ELB旨在隨著流的線性增加而逐漸擴展。這對于像電子商務門戶網站或機票銷售那類開始流量較少，隨著時間不斷增長的模式是可行的，但是如果是在那種建于ELB之上的網站，當它流量飆升，ELB性能就會顯著下降。這種模式通常見于發布考試成績或者發布重大新聞的門戶網站。為了使ELB能夠隨時準備處理這種突發狀況， 亞馬遜期待AWS用戶每月支付最低49美元，以支持服務使ELB能提前“熱身”。雖然這一問題有足夠多的指導資料來解決，但它們仍然被湮沒在AWS的浩瀚文檔之中。就像EBS中置備的IOPS功能，亞馬遜應當使ELB流量可自定義化，這樣客戶可以事先選擇流量模式以確保可擴展性。
每分鐘計費模式
亞馬遜EC2用戶需按小時支付他們的實例運行。也就是說即使該實例僅運行幾分鐘，亞馬遜還是會按一整個小時收費。當AWS于2008年推出EC2，它被認為是在自助服務和按需供應計算資源方面取得了突破性創新。然而快進到2013年，這就被詬病成了虛擬機定價不合理。如果亞馬遜能轉換到按分鐘計費，那么許多客戶就會好好利用這一成本結構帶來的好處。但是由于還有許多競爭對手比如Windows Azure以及谷歌Compute Engine (計算引擎)也在用分鐘計費法，用戶都在觀望亞馬遜的計費模式將怎樣變化。
可改進的CloudWatch度量
亞馬遜的CloudWatch（亞馬遜云服務監控，有針對性的監控并有警報響應）提供與許多AWS服務有關的度量，包括亞馬遜EC2、亞馬遜RDS和亞馬遜DynamoDB。雖然它支持一系列的服務，亞馬遜EC2的度量卻仍有很多值得改進的方面。雖然對有關CPU、磁盤和網絡有關的基本度量是在監控級別進行的追蹤，它仍不盡人意。盡管客戶為亞馬遜CloudWatch付費，他們仍然需要依靠外部服務如Pingdom來跟蹤基本度量，例如網站可用性。為了監測基于網絡服務器或數據庫服務器的高級服務，客戶不得不建立一個基于代理的架構比如Nagios或zabbix。雖然CloudWatch 支持自定義度量， 但需要相當可觀的工作量，并且沒有對于高級度量的現成支持。
WindowsAzure中最近新增了終端監測，它提供了基本的網站穩定運行時間監控。 Rackspace公司獲得了Cloudkick，并將其與眾所周知的具有穩定監控功能的Rackspace云
服務器進行了整合。亞馬遜可以將一個代理輕松嵌入每個EC2實例來跟蹤并報告那些粒狀的和精確的度量。 事實上，依附于AWS豆莖（beanstalk）的Amazon EC2實例已經使用代理驅動的監控引擎來跟蹤服務器的運行狀況。亞馬遜應該將該代理從AWS豆莖擴展到所有亞馬遜EC2實例，來跟蹤和報告有意義的度量。
動態虛擬機大小
如果你認為微軟總是用多種不同版本的Windows來迷惑客戶，那是因為你還沒有見過亞馬遜EC2實例類型的數量。
Amazon EC2實例共計6大類，若細分則有18種。每一實例類型都有一特定負載量。 如果你在看過這些實例類型的詳細介紹后還沒有迷惑，那么接下來你就要開始選擇與你的應用程序相匹配的實例類型了。一般你需要選高 CPU 、高內存、高容量、集群計算等等。等這些都有了，用戶就一定會得到他們想要的了嗎？還不一定。因為通常情況下，本地物理服務器和Amazon EC2實例之間的映射還不完全匹配。在一些情況下是由于存儲器，在其他情況下是CPU不合格。無論如何，實際性能永遠不能匹配實例類型的能力。那么實例類型的能力是不是很難達到呢？也不是，因為最近加入IaaS競爭的公司 ProfitBricks提供了對虛擬服務器的動態配置。 ProfitBricks還聲稱它使用InfiniBand互聯與SSD存儲，因而能提供更佳性能。現在是亞馬遜轉向動態實例類型的時候了，在這里客戶可以拖動滑塊以選擇內存、核心數量、CPU和磁盤容量。這將簡化對Amazon EC2的配置，并且客戶能夠獲得服務器配置的控制權。他們可以停止、調整配置，并重新啟動亞馬遜EC2實例，直到性能令人滿意。
京公網安備 11010502049343號