请注意，这个问题是关于ELB本身，而不是ELB背后的EC2实例
情况
我们最近经历了以下ELB问题：
我们的假设是ELB运行的EC2实例存在连接问题。 临时修复是创build新的ELB（在我们的EC2实例的同一组前面）并更改DNSlogging。
问题
Route 53运行状况检查特别支持ELB实例运行状况监视和故障转移。
启用后，Route 53会自动configuration和pipe理单个 ELB节点的运行状况检查。
路由53 DNS故障转移能够评估负载均衡器的运行状况以及运行在其后面的EC2实例上的应用程序的运行状况。 换句话说，如果堆栈的任何部分出现故障，路由53将检测到故障并将stream量从故障端点发送出去。
https://aws.amazon.com/blogs/aws/amazon-route-53-elb-integration-dns-failover/
基本上，这个解决了个别ELB节点没有固定IP的问题，而事实上很难判断你的应用程序或ELB本身是否失败。
您应该可以使用它来故障转移到在同一地区的单独的ELB，或者到一个完全不同的地区。 您可以将Route53监video率设置为每10秒一次，并且Route 53别名logging上的TTL通常为60秒，这应该可以让您了解如何快速进行故障转移。
Amazon ELB是一个SaaS产品，因此在不知道底层技术的情况下提出build议是非常困难的，所以您应该真正使用Amazon支持渠道来获得这些问题的答案，
不过，我想就您实施ELB提出如下build议：
将您的后端实例分布在多个可用区域中，并且不要在没有至less一个实例的情况下保留一个AZ。 理想情况下，使用AZ平衡自动缩放。
如果您configuration了两个AZ， 并且禁用了交叉AZ平衡， 并且一个AZ的健康实例为零，则您的stream量中的50％将转到ELB实例，而没有后端。
这是因为ELB端点工作的方式（我相信）是循环的DNS。 ELB针对与ELB相关联的每个AZ具有公共IP。
通过closures交叉AZ平衡选项，您可以将ELB的每个“支路”视为特定于AZ的HAproxy实例，仅平衡与自己的AZ池的连接。 启用跨域可用性后，每个ELB实例将平衡后端池中的所有节点。
设置您的Web服务器以提供包含为请求提供服务的实例ID的X-Served-By标头。
这可以帮助诊断具有间歇性问题的潜在故障实例，并使您能够快速validationELB是否确实与所有节点平衡。
阅读有关最佳实践的Amazon文档，并考虑使用第三方监视工具（技术上针对ServerFault指南，但我build议使用StackDriver和NewRelic ）。
通过深入研究Amazon文档以及CloudWatch指标，您可以学到很多东西。 亚马逊的后者界面可能令人沮丧，所以第三方工具可以提供帮助，并且还可以通过实例代理为您提供指标。