我有一个Amazon ELB，后面有3个EC2实例分布在3个区域。
以下是每个实例上访问日志的摘录：
一审（A区）：
10.210.214.231 - - [17/Sep/2011:15:40:16 -0400] "GET /healthcheck.html HTTP/1.1" 200 194 "-" "ELB-HealthChecker/1.0" 10.223.33.43 - - [17/Sep/2011:15:40:16 -0400] "GET /healthcheck.html HTTP/1.1" 200 194 "-" "ELB-HealthChecker/1.0" 10.210.214.231 - - [17/Sep/2011:15:40:17 -0400] "GET /healthcheck.html HTTP/1.1" 200 194 "-" "ELB-HealthChecker/1.0" 10.223.33.43 - - [17/Sep/2011:15:40:17 -0400] "GET /healthcheck.html HTTP/1.1" 200 194 "-" "ELB-HealthChecker/1.0" 二区（C区）：
10.116.114.11 - - [17/Sep/2011:15:40:16 -0400] "GET /healthcheck.html HTTP/1.1" 200 194 "-" "ELB-HealthChecker/1.0" 10.116.114.11 - - [17/Sep/2011:15:40:16 -0400] "GET /healthcheck.html HTTP/1.1" 200 194 "-" "ELB-HealthChecker/1.0"
三区（D区）：
10.223.33.43 - - [17/Sep/2011:15:40:16 -0400] "GET /healthcheck.html HTTP/1.1" 200 194 "-" "ELB-HealthChecker/1.0" 10.223.33.43 - - [17/Sep/2011:15:40:16 -0400] "GET /healthcheck.html HTTP/1.1" 200 194 "-" "ELB-HealthChecker/1.0"
急于想知道在同一个ELB后面的实例上来自不同IP的stream量是如何来的。 10.223.33.43也出现在两个实例上。 为什么？
在实例启动的每个区域中是否存在LB？ 听起来很奇怪，但在访问日志中有单独的IP让我相信它..
为了保持可扩展性并防止单点故障，ELB似乎以与直觉相反的方式工作（至less乍一看）。
我认为ELB给人的第一印象是它是一个单一的常规实例设置，在你的应用程序实例之前有一些负载均衡软件，并分配stream量 – 我最近的阅读表明这与实际情况相去甚远。
看起来，每个可用性区域都有一个（或多个）负载均衡器来为您的实例提供服务。 您将设置一个CNAME指向ELB–一个虚拟实体 – AWS的内部DNS会将其映射到分配给您的负载均衡器之一。 然后负载均衡器将决定将客户端请求发送到哪里 – 无论是在同一个可用区中的实例还是到另一个可用区。 此外，为了扩展您的应用程序需求，还将增加更多的负载均衡器，而AWS则是在“预期”增加stream量的情况下做到这一点。
因此，假设在每个可用性区域有两个或多个负载平衡器，尽pipe只有一个ELB已经启动，如果他们有足够的stream量进入您的应用程序。
如果您浏览一下ELB开发人员指南 （第9页），您会发现可以将请求从一个负载均衡器传递到另一个负载均衡器。 （在给出的具体例子中，它指的是多个X-Forwarded-For头部，包括ELB的头部）。
如果在多个可用区中有后端应用程序实例，则X-Forwarded-For请求标头可以包含一个或多个负载平衡器IP地址。 由于Elastic Load Balancing为每个可用区使用不同的负载均衡器，因此可以在到达后端应用程序实例之前将客户端请求从一个负载均衡器传递到另一个负载均衡器。 例如，如果在可用区域US-east-1a和US-east-1b中有后端实例，则客户端请求最初可能由US-east-1a中的负载均衡器处理。 如果Elastic Load Balancing确定此请求应该路由到US-east-1b，则US-east-1a中的负载均衡器将请求路由到US-east-1b中的负载均衡器。
希望能够解决您具有多个负载均衡器地址的方式，以及同一地址如何显示在不同的可用区域中。
我build议看看“弹性负载平衡”中的“弹性”：ELB弹性和如何testing它作为ELB如何工作的一个很好的概述。