可用性在公有云的范疇意味著公司必須確保自己的服務宕機時間最少。對于很多web規模的企業來說連接的丟失意味著客戶的丟失。要確保可用性，重要的是在故 障變成徹底斷電以前就要發現并想法減輕。使用AWS，開發人員可以采取三管齊下的方法來提高持續性，通過使用如Amazon Route 53，彈性負載均衡和自動擴展組這樣的工具。

直接請求過程，例如視頻回放的請求，不是由事件驅動的。基于這個原因，并行化在這里不像在其他后端進程那樣適用。對于那些需要立刻作出反應的直接請求，開 發人員必須提供高可用性的支持。如果用戶在嘗試播放視頻時得到一個“500錯誤，服務器不可用”的回應，該業務將有可能失去用戶。

企業可以很輕松地發布一整夜維護的聲明并期待客戶能夠接受這段時間內將不能訪問服務的日子已經過去了。如果一個業務想要提供99.999%的正常運行時間，那么一個月的停機時間大約只能有40分鐘。

為了實現這種AWS可用性，開發人員必須能預見到錯誤-而不只是避免錯誤。開發人員必須有一個適當的流程，可以從任何形式的破壞性狀況下恢復，他們必須能夠處理所有類型的網絡和區域問題。他們還需要有位于靠近國際客戶區域地點的服務器并能將客戶路由到正確的地理位置。

開發人員應該關注三個層面來實現全球AWS可用性。在最頂層是Amazon Route 53。在地區層面，開發者可以使用彈性負載均衡（ELB），然后在域層面，他們需要增加自動擴展組。

圖1：典型的AWS高可靠性架構

該架構保護資源避免幾個潛在的問題，包括地理問題，通過直接引導用戶到離其最近的網絡位置，用ELB解決單獨域的問題，使用自動擴展組解決單獨服務器的問題。開發人員可以配置自動擴展組來自動殺掉未響應ELB健康檢查的任何實例。

經受住區域性亞馬遜Web服務問題的考驗

然而所有這些都假定AWS不會有一整個區域的斷電。但并非總是如此，事實上，有很多記錄在案的事件表明，亞馬遜曾經有過某個具體服務的一整個區域斷電，包 括DynamoDB和彈性計算云。如果亞馬遜在一個地區出現問題，一個業務可能會失去那片地區的所有客戶并需要手動將流量重定向到另一個區域，除非你添加 了Route 53健康檢查。

支持地理路由和健康檢查很簡單，只要設置一個在故障發生時可以切換到其他端點的區域端點。例如，如果一個網站是example.com，它可以設置us- east.example.com，us-west.example.com和eu-west.example.com這三個端點。然后配置 Example.com使用在地理位置上最近的端點。但其中每個端點將被配置為使用這三個ELB之一，優先使用最近的并同時通過健康檢查來轉到其它端點 上。

圖2：在這張Route 53配置圖中，黑色代表最理想的選擇，藍色代表次要選擇，紅色是第三選擇。

圖2顯示了一個Route 53區，根據地理位置配置了三個獨立的端點。如果我們被導向美東端點，則***是美東負載平衡器。倘若負載平衡器不可用，它會嘗試使用美西的負載平衡器。如 果美西的ELB也宕了，則會轉到歐西地區。如果這三個地區都宕掉了，那么你的麻煩就很大了。在Route 53的層面適當配置健康檢查將有助于減少整個區域出故障時的宕機時間。

這就是所謂的增加持續性-預期到個別的區域會斷電，并有一個用于恢復服務的計劃。但驗證和支持每個區域的個體可用性很重要。例如，如果整個區域發生故障，其他區域仍然應該能夠不受任何影響的工作。這可以通過使用數據庫復制達到。

幸運的是，亞馬遜已經在DynamoDB上支持跨地區復制。很多其他的數據庫也支持主主復制方案，這樣可以在出現問題時轉到另一個域來支持區域隔離和持續性。

當開發者需要支持應用的高可用性訪問時，多層次的持續性是必須的。幸運的是，AWS提供了三種很好的服務可以結合起來使用，以解決地區，區域和實例層面的 問題。通過添加像NewRelic這樣的第三方服務來監控應用程序可以為你的業務提供各種警報并可以自動修復服務以減少停機時間。