AWS在每個Region都有多個AZ（Availability Zone)多個AZ之間物理隔離,供電也是獨立的，這樣部署業務時，可以充分利用多AZ實現高可用方案，避免亞馬遜底層機房事故導致業務中斷。

（1）前端ELB層，可以將ELB設定成跨多個AZ，即將需要的子網（Available Subnet)新增進ELB就行，（點選Available Subnet前面的綠色加號按鈕），這個時候，每個AZ至少選擇一個Subnet，ELB就可以將流量分發到不同AZ上的例項。有一點需要注意的是，ELB是將流量均分到不同AZ中的，而不會考慮哪個AZ中例項多哪個少，因此部署的時候儘量在不同AZ均勻分佈計算資源。實質上，ELB服務包含多AZ後，會在不同AZ建立不同LB例項，其私網IP是不同的，access日誌中能看到，只不過這些LB會使用一個統一的url(endpoint)。因此可以在Route53中將域名CNAME或者Alias到ELB的endpoint上。

（2）web server服務層，新增到ELB中的例項，也可以均分到不同的AZ，這是一個高可用方案的基本措施。如果例項已經執行在同一個AZ中了，可以通過將線上服做成AMI(注意勾選No reboot），然後基於此AMI再在別的AZ中建立同樣的例項，並加入到ELB例項組中。你可以隨時將例項退出或加入ELB例項組。

（3）快取層，ElasticCache服務不管是Memcached還是Redis,目前都不支援Node節點跨AZ，因此需要在不同AZ中建立單獨的ElasticCache例項和節點，同事需要程式程式碼上做點改動。允許配置多個快取例項，例如redis-master,redis-slave。相信不久AWS就會推出自動跨AZ的ElasticCache(即統一的endpoint,可以在不同AZ建立node)。

（4）DB層，讀寫分離是一個比較好的方案，一寫多讀，多個讀例項用內網ELB做負載均衡。但是寫還是單點的，建議在不同AZ建立一個熱備，作為DB slave(EC2做DB的方案）；如果使用RDS服務的話，就更方便一些，你可以使用跨AZ的replica(建立RDS例項的時候可以選擇Multi-AZ），好像最近有添加了跨Region的“Multi-AZ”，還可以使用RDS的讀寫分離功能，建立多個讀例項，然後這些讀例項可以加入到一個內網的ELB中實現負載均衡。

（5）周邊，Route53服務提供4個nameserver，基本不用擔心單個nameserver宕機導致域名解析故障（前提是你把域名解析遷移到AWS Route53上）；S3據說提供12個9的高可用，資料和日誌等放在上面不同擔心丟失問題，唯一需要擔心的是資料安全（控制好訪問許可權）；CDN（CloudFront + S3)可靠性也比較高。ELB後端的例項，如果只允許通過ELB訪問的話，EIP完全是可以不要的，解除安裝EIP減少安全隱患。