Answers:
据我了解，它们只是进行轮询，将连接平均分配到它们后面的服务器。
有点，但我认为不是很准确 -不幸的是，Amazon ELB路由文档尚不存在，因此需要整理一些内容以得出结论。下面是从唯一的片段弹性负载平衡开发者指南我所知道的，见会话粘贴在弹性负载均衡的概述：
默认情况下，负载均衡器将每个请求独立地路由到负载最小的应用程序实例。但是，您可以使用粘性会话功能（也称为会话关联），该功能使负载均衡器可以将用户的会话绑定到特定的应用程序实例。这样可以确保会话期间来自用户的所有请求都将发送到同一应用程序实例。[强调我的]
现在最小的负载到底是什么意思？同样，我知道的唯一解释是2009年以来AWS团队对ELB策略的反应有些模糊：
ELB松散地跟踪每个实例中有多少个请求（或TCP连接）。 它不监视每个实例的资源使用情况（例如CPU或内存）。ELB当前将在它认为有最少未完成请求的那些实例中进行循环。[强调我的]
这对于他们的系统体系结构和已解决的用例很有用，但显然不能提供高级HA场景可能需要的透明性和/或路由控制。
请注意，根据解释，这可能会或可能不会抵触一点由最近的AWS团队应对弹性负载平衡-负载分配政策：
循环确实起作用，但是客户端会话并不总是支持TTL或DNS缓存，因此您可能会得到歪斜的结果和不均匀的请求分布。ELB不会有效执行迄今在那里的流量路由决策中接收到的流量/请求实例。 [强调我的]
当然，以上内容已通过正确记录的，透明且可控制的运行状况检查进行了修改，如前所述，AWS团队对ELB的回应总结说，这使您有一定的优势（可能是暂时地）从路由中删除实例。策略：
负载均衡器监视在负载均衡器中注册的实例的运行状况。当负载均衡器检测到实例问题时，它将停止向其分配流量。当实例再次正常运行时，负载均衡器将重新开始向其分配流量。此过程使您的应用程序可以自动对失败的实例做出反应，而无需您进行其他操作，而无需配置运行状况检查。
虽然当然很不正常，但我不明白为什么ELB也不能与其他Amazon EC2实例类型的池一起使用-我自己也没有尝试过，因此建议同时使用CloudWatch监视负载均衡器和监视您的各个EC2实例并关联结果，以便最终获得对此类设置的各自见解和信心。