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減少安全隱患。