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减少安全隐患。