1.要解決的問題
爲了應對大流量，通常會需要一個高配置的Web服務器。這種使用更高配置的設備來提高處理性能的方法稱爲“縱向擴展”。
然而這種方法有一些問題。一般來說，高性能服務器的配置越高，每個單元的處理成本就越高。而且大家都知道服務器的規格是有限制的——它的性能不可能無限制地提高。
2.雲模式的說明
這種用多個相同規格的服務器並行處理高流量的方法稱爲“橫向擴展”。
你可以創建多個虛擬服務器並使用負載均衡器來給每一個虛擬服務器分配負荷。根據不同的系統，流量可能會在幾周、幾天甚至幾小時內劇增。AWS雲可以使你很輕鬆地動態更改虛擬服務器數量，從而能夠配合流量的巨大變化。
3.實施
你可以結合使用這三種服務：負載均衡服務（ELB）、監控工具（CloudWatch）以及自動橫向擴展服務（Auto Scaling），來輕鬆地構建一個可以根據負荷量實現自動縱向擴展的系統。
（步驟）
建立多個在ELB控制下的並行EC2實例（作爲Web/AP服務器）。
創建一個用於啓動新的EC2實例的AMI。
給定一個用於觸發增減EC2實例個數的條件（指標）。通常會採用EC2實例的CPU平均利用率、網絡流量值、會話數目、EBS延遲時間這一類的指標。
使用CloudWatch來監測這些指標，並將其設置爲一旦系統滿足特定條件就發出警告。
將Auto Scaling設置爲當收到警告則增加或減少EC2實例數量。
當完成以上設置，你就能實現自動擴展。例如，當CPU平均利用率持續5分鐘超過70%，系統利用之前準備好的AMI啓動2個新的EC2實例。當然，你還能根據環境減少EC2實例的數量。
4.配置
5.好處
保證了服務的連續性，因爲EC2實例的數量會根據流量的增加而自動增加。
減少了開支，因爲在流量較低時可以減少EC2實例數量。
對於管理員來說，降低了工作量，因爲EC2實例的數量能根據流量的變化自動增減。
與縱向擴展相比，處理能力的極限變得非常大，因爲可以在ELB的控制下並行地提供所需數量的EC2實例。
6.注意事項
它不能應對劇烈的或快速的流量變化，例如幾分鐘內流量翻倍或增至三倍。事實上，這是因爲在確定需要增加EC2實例數量後還需要一些時間才能完成實際數目的增加。在這種情況下，你需要制定一個EC2實例在特定時間增加的計劃。先保證有足夠多的額外EC2實例來提前應對負荷，然後再刪除不需要的EC2實例。
考慮是否要離開對ELB的如HTTP會話管理、SSL過程等，或者是否需要在控制服務器中進行處理。
由於ELB沒有提供根據規格來改變負載分配量的機制，所以被控制的EC2實例類型最好都相同。
爲了增加容錯性能，你可以跨多個AZ來實現橫向擴展。參見多數據中心模式。這時，爲了讓每一個AZ能有一樣的分配，實例增加的數量應該是AZ數目的倍數。
當第一次給新啓動的EC2實例進行SSH連接時，在某些情況下，爲了在登錄時驗證主機會交互式地執行指紋驗證，這時，像這種從外部使用SSH自動處理的功能將被禁用。
當EC2實例需要更新時，你同樣需要更新Auto Scaling中用於啓動實例的AMI。
7.其他
- 關於執行縱向擴展時的文件共享問題，請參見克隆服務器模式、NFS共享模式和NFS複製模式。
- 關於會話管理請參見狀態共享模式。
- 參見預定橫向擴展模式。